Patent Document

CROSS-REFERENCE TO RELATED APPLICATIONS 
     This is a continuation of application Ser. No. 10/277,431, filed 22 Oct. 2002, which is incorporated herein by reference and to which priority is claimed. 
    
    
     BACKGROUND 
     The invention relates generally to computer network data management facilities and, more particularly, to disaster recovery techniques for use therein. 
     Many large organizations manage the storage and access of their data through the use of multiple file servers. For example, a corporation may utilize one or more servers to store/manage the data and/or applications for each of its operating units or divisions. As a result, each operating unit (e.g., engineering, sales, marketing) has ready access to their data and applications. However, the use of multiple servers also increases the difficulty individual users have in locating the data they want or need. For example, if an individual assigned to the engineering division needs to review product marketing or sales information they must know what server and the location on that server where the desired information is stored. It will be appreciated that the difficulty of locating information in this manner increases as the size of the organization grows—that is, as the number of servers increases. 
     Partly in response to this problem, Distributed File System (DFS) technology has been developed that allows a user (typically a network administrator) to logically associate a single directory structure whose contents can span a number of file servers and file shares (e.g., directories), making it easy to browse the network to find the data and files needed. As would be known to one of ordinary skill in the art, DFS allows an administrator to map logical names (e.g., “Marketing”) with one or more shared resources such as, for example, the marketing material for each product or division within a business regardless of where that data may be physically stored. 
     While DFS technology has simplified the task of managing network resources (e.g., hardware devices and files), it does not provide any means to identify and recover from the failure of a network resource while providing near continuous access to the underlying data. Accordingly, it would be beneficial to provide a mechanism to detect and recover from the failure of shared network resources. 
     SUMMARY 
     In one embodiment the invention provides a disaster recovery method. The method includes monitoring one or more designated resources, detecting when one of the designated resources fails, identifying a designated alternate resource associated with the failed resource and swapping the designated alternate resource for the failed resource. In some embodiments, multiple alternate resources may be designated for a given (primary) resource such that one of the alternate resources is selected in accordance with a priority scheme when the primary resource fails. Methods in accordance with the invention may be embodied in computer executable instructions and stored in a suitable storage medium. 
     In another embodiment, the invention provides a disaster recovery system. Such a system typically includes a plurality of logical resources, each logical resource associated with a physical resource, a logical namespace means for routing requests directed to a designated logical resource to an associated physical resource, a monitor means for actively monitoring one or more of the physical resources and a recovery means for receiving notification from the monitor means that a physical resource has failed and causing the logical namespace means to substitute a designated alternate physical resource for the failed physical resource. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows, in flowchart form, a disaster recovery process in accordance with one embodiment of the invention. 
         FIG. 2  shows, in block diagram form, a computer network monitored in accordance with one embodiment of the invention. 
         FIG. 3  shows, in block diagram form, a functional view of a disaster recovery process in accordance with one embodiment of the invention. 
     
    
    
     DETAILED DESCRIPTION 
     The invention relates generally to computer network data management facilities and, more particularly but not by way of limitation, to methods and devices for responding to, and recovering from, the failure of shared network resources. The following embodiments of the invention, described in terms of an application program executing in a Microsoft® Windows® network environment using Distributed File System (DFS) technology, are illustrative only and are not to be considered limiting in any respect. 
     Referring to  FIG. 1 , disaster recovery (DR) process  100  in accordance with one embodiment of the invention begins when a user (typically a network administrator) designates resources/targets as members of one or more DR groups (block  102 ). Group designation may, for example, be effected through a graphical interactive user interface, a batch input file, or a series of command line inputs. To enable DR process  100  to provide automatic failover (see discussion below regarding block  110 ) and, possibly, failback (see discussion below regarding block  114 ) capability, it will be recognized that each DR group resource (hereinafter referred to as a “primary resource”) must be associated with at least one alternate resource (hereinafter referred to as a “secondary resources”). During failover operations, one of the designated secondary resources may be “substituted” for the failed primary resource. In accordance with one embodiment of the invention, alternate resources may be designated through the DFS “link replica” feature. Typically, primary resources are on high-performance devices such as high speed magnetic storage units to provide the best response to run-time users. Secondary resources, however, may use lower performance (and therefore lower cost) devices as they are only accessed by users in the event of a failure. 
     Once defined, each DR group is configured for run-time operation (block  104 ). By way of example, a user may use a graphical user interface to configure the following operational features for each DR group resource: 
     Monitor Interval: The time between successive determinations of a target&#39;s health. For example, primary resources may be checked every ten (10) minutes while secondary resources may be checked every twenty (20) minutes to determine if they have failed. It is noted, these time are illustrative only and, in one embodiment, may be set from one (1) minute to once per day. It is further noted that secondary resources do not need to be checked until, or unless, the associated primary resource fails. 
     Replication: In some embodiments, it may be beneficial for DR process  100  to periodically replicate the data associated with a primary resource into one or more of the primary resource&#39;s associated secondary targets. If replication is provided by DR process  100 , the user may additionally designate the time interval between successive replications or synchronizations. In some embodiments, DR process  100  ensures that the content of the secondary resource is identical to that of the primary resource - within the designated replication interval. In other embodiments, DR process  100  only ensures that the primary resource&#39;s data is contained within the secondary resource, allowing the secondary resource to have additional data contents. It is noted that replication via DR process  100  is not required. For example, a primary resource could be one disk in a hardware mirrored disk system while the secondary resource could be another disk in the hardware mirrored disk system. In such a system, DR process  100  would not have to perform replication to ensure continued user access to the underlying data in the event of a failure. In still other embodiments, the user may not care if a primary resource&#39;s data is replicated—being content to simply allow access to a secondary resource should the primary resource go off-line. 
     Failover Sequence: If a primary resource has more than one associated secondary resource, the user may designate in which order the secondary resources are made accessible in the event of a failure. For example, if three (3) secondary resources (SR 1 , SR 2  and SR 3 ) are associated with a primary resource, the user may designate that SR 1  be used if the primary resource fails, that SR 3  should be used if SR 1  fails, and that SR 2  should be used if SR 3  fails. In this manner, DR process  100  provides and accommodates chained failures. In some embodiments, the failover sequence may be “locked” as described above. In other embodiments, if replication is provided via DR process  100 , the failover sequence may be to the “most recently replicated” secondary target. 
     Referring again to  FIG. 1 , once configured DR process  100  may be started so that each designated resource/target is monitored in accordance with the user-specified schedule (block  106 ). In one embodiment, DR process  100  issues a “ping” command to each machine on which a monitored target/resource exists to determine if the resource&#39;s associated computer is operational. In another embodiment, DR process  100  issues a directory request to each monitored target/resource. If a proper response is returned by the targeted resource, the resource is deemed to be operational (invoking the ‘no’ prong of diamond  108 ). If a proper response is not returned, the targeted resource is deemed to have failed (invoking the ‘yes’ prong of diamond  108 ). For example, in one embodiment a Microsoft® Windows® API (Application Program Interface) directory listing call is made to the target directory (physical resource) and the returned response is analyzed. 
     On failure detection, DR process  100  causes the computer network&#39;s DFS tables to be updated so that further accesses directed to the failed resource/target are directed instead to one of the failed resource&#39;s associated secondary targets—that is, failover to a secondary resource is effected (block  110 ). DFS table updates may be performed, for example, using standard DFS application programming interface (API) defined instructions. As indicated above, in some embodiments the sequence of secondary resources to fail to may be designated by the user—e.g., secondary resource  1 , followed by secondary resource  2 . In other embodiments, the failover sequence may include failing over to the most recently replicated secondary resource. In one embodiment, the mechanics of updating the computer network&#39;s DFS tables is as follows: (1) update the DFS tables to indicate the link to the failed resource is “off-line;” and (2) update the DFS tables to indicate the link to the selected secondary resource is “on-line.” Those of ordinary skill in the art will recognize that an off-line link is a link that is not used to resolve access requests by DFS while an on-line link is used to resolve access requests by DFS. In still other embodiments, DR process  100  may invoke user-specified routines immediately before and/or immediately after effecting the failover operation (i.e., DFS table update operation). One function such user-specified routines may perform is to generate failure email messages to designated staff. Another function user-specified routines may perform is to generate network monitor log entries indicating the failure. Such log events may include date and time stamps as well as the identification of the failed resource. Typically user-specified routines are effected through executable scripts and may, accordingly, perform any task that is possible through such means. Identification and selection of these routines may be made during DR group configuration (block  104 ). 
     In some embodiments, DR process  100  may be further adapted to determine if the detected failure can be corrected and, if so, perform the correction (block  112 ) and then return the repaired resource to operation (block  114 ). For example, if the failure was due to a parity error, DR process  100  may correct the error or invoke another application or process to correct the error. Alternatively, if the failure is due to hardware and/or is repaired by an outside agency (process or person), DR process  100  may be notified when the target&#39;s device is ready to return to service. However the failure is addressed, once corrected the primary resource may be synchronized with the on-line secondary resource (to capture any data modifications made while the primary resource was off-line) and returned to service through DFS table updates analogous to those described above in block  110 . 
     Referring to  FIG. 2 , computer network  200  in accordance with one embodiment of the invention comprises DFS Nameserver  202 , Monitor Server  204 , Server- 1   206 , Server- 2   208  and Server- 3   210 . As shown, DFS Name  212  identifies Primary Target/Resource  214  via Primary Link  216 . Associated with DFS Name  212  are two secondary targets (“link replicas” in DFS terminology): Secondary Target  218  (identified via Secondary Link  220 ) and Secondary Target  222  (identified via Secondary Link  222 ). Monitor Server  204  periodically monitors Primary Target  214  and, possibly, one or more of the Secondary Targets  218  and  222  in accordance with a user specified configuration (see discussion above). If Monitor Server  204  determines that Primary Target  214  has failed (i.e., is non-responsive to a query from Monitor Server  204  via Communication Path  226 ), Monitor Server  204  may effect the failover operations of block  110  (see  FIG. 1 ) by way of standard DFS API instructions and DFS Path  228 . Alternatively, DR process  100  may include a DR module (not shown in  FIG. 2 ) that executes on DFS Nameserver  202 . In this embodiment, Monitor Server  204  indicates to the DR module that Primary Target  214  has failed and it is the DR module that effects failover operations (block  110  of  FIG. 1 ), failback operations (block  114  of  FIG. 1 ) and, possibly, the DFS actions associated with recovery operations (block  112  of  FIG. 1 ) by direct communication with DFS Nameserver  202  through, typically, DFS API instructions. 
     One consequence of a method and system in accordance with the invention is that a client (not shown in  FIG. 2 ) using DFS Nameserver  202  to communicate or access data on a server (e.g., Primary Target  214  on Server- 1   206 ) is not blocked when the primary target fails as the inventive method and system can automatically failover to a designated secondary target (e.g., Secondary Target  218  on Server- 2   208 ). That is, the client may never know of the failure because a secondary link (e.g., Secondary Link  220 ) is automatically and transparently substituted for the link to the failed primary target (e.g., Primary Target  214 ). Accordingly, disaster recover in accordance with the invention provides clients (users and/or applications) near continuous access to data through an automatic and transparent failover process. Similarly, when a failed resource is recovered (or replaced), methods and systems in accordance with the invention provide continued access to the data through link substitution techniques. 
     Referring to  FIG. 3 , a functional block diagram of DR process  100  in accordance with one embodiment of the invention comprises Monitor Module  300  and DFS Module  302 . DFS Module  300  communicates with one or more DFS Nameservers  304  and with Monitor Module  302 . Similarly, Monitor Module communicates with Monitored Targets  306  and with DFS Module  300 . In some embodiments, DFS Module  300  and Monitor Module  302  execute on the same processor (e.g., computer system processor). In other embodiments, DFS Module  300  executes on the same platform as does DFS Nameserver  304 . In most embodiments, Monitor Module  302  and DFS Nameserver  304  are executed on different platforms for fault tolerance reasons. 
     One benefit of disaster recovery processes in accordance with the invention is that an automated means for monitoring the status of a logical namespace (e.g., DFS) and the automated failover to alternate target resources on failure detection is provided. Another benefit in accordance with the invention is that a plurality of alternate targets may be designated as failover resources, thereby providing a means to accommodate a series of resource failures in the namespace. Yet another benefit of the invention is that if multiple failover targets are identified, a user-specified priority scheme may be used to direct the failover operation. Still another benefit of the invention is that data replication may be associated with one or more alternate targets to provide data redundancy within the namespace itself. Another benefit of the invention is that target/resource monitoring may be effected by a direct query to the resource itself (e.g., a directory request). This approach to monitoring status has the benefit of determining if a precise resource if functional (e.g., a directory structure in a file system) rather than relying on the health of a hardware device (e.g., a network interface card, NIC) and inferring that the file system accessible through that NIC is operational. 
     Various changes in the details of the illustrated operational method are possible without departing from the scope of the following claims. For instance, the act of failed target recovery (block  112  of  FIG. 1 ) need not be implemented, or even possible, in all embodiments. For example, when hardware (e.g., a magnetic storage disk, central processor unit, or network router) fails, automated recovery is generally not an option. In these cases manual repair/replacement of the failed device is needed to effect recovery. Similarly, the act of automated failback operations (block  114  of  FIG. 1 ) may not be implemented in all embodiments. In addition, the automated monitoring, failover and failback operations described herein with respect to a DFS embodiment are equally applicable to any network system that provides, or can be made to provide, a logical namespace construct. By way of example, the inventive techniques are applicable in a Unix environment wherein the logical namespace is provided through a combination of the Network Information System (NIS), Network File System (NFS) and the Unix automount feature. (NIS and NFS were developed by Sun Microsystems, Inc. of Mountain View, Calif.) 
     It will also be recognized by those of ordinary skill in the art of computer programming that the method of  FIG. 1  and the functional modules of  FIG. 3  may be embodied as a series of instructions organized into one or more computer programs which are executable by a programmable control device. A programmable control device may be a single computer processor, a plurality of computer processors coupled by a communications link, or a custom designed state machine. Custom designed state machines may be embodied in a hardware device such as a printed circuit board comprising discrete logic, specially designed application specific integrated circuits (ASICs), or integrated circuits such as field programmable gate arrays (FPGAs). Storage devices suitable for tangibly embodying computer programs include all forms of non-volatile memory including, but not limited to: semiconductor memory devices such as electrically programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), and flash devices; magnetic disks (fixed, floppy, and removable); other magnetic media such as tape; and optical media such as CD-ROM disks. 
     While the invention has been disclosed with respect to a limited number of embodiments, numerous modifications and variations will be appreciated by those skilled in the art. It is intended, therefore, that the following claims cover all such modifications and variations that may fall within the true sprit and scope of the invention.

Technology Category: 3