JP5307223B2 - Disaster recovery architecture - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method and system for failure recovery in a packet-based network. <P>SOLUTION: A network (50) includes a production site (52) and a recovery site (54) coupled together by a packet-based network (56). Mirroring software (68) on the production site (52) keeps the recovery site (54) up to date to the last transaction occurring on the production site. A recovery control server (84) polls the production site in order to detect a failure condition or other fault. Upon detection of a problem at the production site (52), the recovery control server (84) reconfigures the network (56) so that attempts to access the production site (52) are routed to the recovery site (54). <P>COPYRIGHT: (C)2012,JPO&amp;INPIT

Description

  The present invention relates generally to communication networks, and more particularly to failure recovery techniques used in communication networks.

  Due to the popularity and convenience of networked computer systems, database data sharing among users has become popular in many business environments. For centralized access to information through a database, database maintenance and management must be carefully considered. In addition, recovery techniques are essential to ensure database consistency after hardware / device failures or application logic failures.

  In general, recovery techniques provide a way to reset a system or data stored in the system after being damaged to an operational state and to rebuild the database by restoring a backup copy.

There are two points of interest in any data recovery system.
First is the target recovery point (RPO), which defines the maximum planned difference between the original data and the backup copy.
Second is the target recovery time (RTO), which defines the maximum time for service restart.

  One of the simplest forms of system backup is to physically transport a copy of data made on magnetic tape to a remote archiving site. In general, this requires the user to stop all database activity while making a backup tape. Next, this failure recovery requires that the database be recovered using a backup tape.

  A more recent form of system backup uses network interconnections to perform periodic backups of production sites. The time for such backup is controlled by the network administrator. A method for restoring an application server includes installing a new system, including hardware having similar characteristics as the old system, and restoring a backed up image of the system from the recovery site.

  Another prior art system supplied by Veritas (as of the filing date of this patent application, available for download from the Internet at URL: http://www.veritas.com/Products/www?c=product&refId=140) Discusses the architecture of the software module for controlling the various stages necessary for the correct execution of the backup procedure and the subsequent stages of restoring the client. In particular, the Veritas solution includes a server for control and management of backup operations, a server for control of the client restore phase, a server that provides the client with the necessary programs and settings for restore, and finally a remote Various servers are used for each individual functional aspect, including servers for booting management.

  Another prior art solution is the article titled “Cisco Network Boot Installation and Configuration Guide, Release 3.1” (URL: http://www.cisco.com/en/US/products as of the filing date of this patent application). /hw/ps4159/ps2160/products_installation_and_configuration_guide_book09186a00801a45bO.html (available for download from the Internet) and a copy of the entire system image, including the operating system, applications and data on the server create. Backups are performed mutually by the network administrator. The Cisco solution gives the possibility to perform the boot procedure remotely over the network, provided that it has the same hardware characteristics as the replicated primary server. Thus, the recovery server can restore a remote copy of the system image from the network and re-provide services previously guaranteed by the primary server.

  US Patent Publication US 2004/0153698 A1 provides a system and method for preparing and repairing failures for services of damaged or destroyed communication network elements. A computer-implemented method for performing fault backup for network elements includes obtaining connectivity with a plurality of network elements. To invoke a computer routine that generates a plurality of computer readable service continuity data in the local memory of the network element, the host computer can send one or more commands to the network element. An automated system of computer-executable components for network element failure recovery includes a computer-executable controller component configured to select a plurality of network elements designated for a failure backup operation . A computer-executable engine component is configured to obtain connectivity to the plurality of network elements and network one or more commands to replicate service continuity data for each of the network elements. Configured to send to the element.

In US Patent Publication US2004 / 0078397A1, file system failure recovery techniques provide automatic monitoring, failure detection and multi-stage failover from a first designated target to one of a second designated target in a designated group. The second designated target may be prioritized so that failovers occur in a predetermined order. By duplicating information between the first designated target and the second designated target, failover can be performed to maximize the continuity of the operation. In addition, user specific operations can be initiated shortly after failure detection and / or failover and / or failback operations.
US Patent Publication US2004 / 0153698A1 US Patent Publication US2004 / 0078397A1

Object and Summary of the Invention When an applicant restores a system after a failure, the client preferably needs to manually change settings to access the recovery server at the recovery site while maintaining good RPO and RTO values However, it has been found that there is a problem of ensuring that the client can access the service independently of the restoration of the network element.

  Applicants have found that this problem can be solved by the method of claim 1 which performs fault recovery.

  In particular, Applicants have found that this problem can be solved by providing an automatic rerouting mechanism that routes the client to the recovery server. In addition, we have found that this problem can be solved by providing an automatic control and management mechanism for the data replication stage through a mirroring procedure that can always match the server data and settings to the last transaction.

  Another aspect of the invention relates to a system according to claim 12 for performing fault recovery.

  Another aspect of the present invention relates to a computer program product that can be loaded into the memory of at least one computer and includes software code portions for performing the steps of the method of the present invention when executed on the computer. . As used herein, such a computer program product is equivalent to a computer readable medium containing instructions for controlling the computer system to coordinate the execution of the method of the present invention. . “At least one computer” clearly emphasizes the possibility of implementing the present invention in a distributed / modular manner.

  Further preferred embodiments of the invention are described in the independent claims and in the following specification.

  For a better understanding of the present invention, preferred embodiments that are merely examples and should not be construed as limiting are described below with reference to the accompanying drawings.

FIG. 2 is a system diagram for performing fault recovery in accordance with the present invention. It is a detailed system diagram of the production site of FIG. It is a detailed view of a wide area network. It is a detailed view of a recovery control server. Fig. 4 shows a flow of network traffic during a period of normal operation. The flow of network traffic in the situation of failure recovery is shown. The flow of network traffic in a failback situation is shown. 3 is a flowchart of a method for implementing the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION FIG. 1 is a diagram of a system 50 that includes a production site 52, a recovery site 54, a network 56 connected between the production site and the recovery site, and an extranet client 58. The production site can include a storage 60 connected to one or more application servers 62. One or more intranet clients 64 are used to access application server 62 via network 66, which may include, for example, an Ethernet switch and an IP router. Box 66 also shows a security device that may include an intrusion detection system that blocks access to an authentication system, firewall, or application server. A mirroring software module 68 is used to perform synchronous replication of the local image of the application server on the remote storage volume. Such synchronous duplication ensures that the data placed on the storage 60 matches the copy held on the recovery site 54 until the last transaction. Also, if the last transaction caused damage to the server configuration, the system image mirroring software module corresponding to the stable operating condition of the system so that it can revert to the previously saved stable image It is also desirable to save.

  The recovery site 54 may include one or more recovery servers 78, a network security device 80, a storage area network (SAN) device 82, and a recovery control server 84. The recovery server 78 is configured to mimic the application server 62 in the event of a failure. It is desirable to provide a pool of recovery servers with various hardware features so that one of the pools most closely associated with the application server 62 can be used in the event of a failure. The SAN device 82 stores mirror data provided from the mirroring software module 68. Network security device 80 performs the same functions for recovery site 54 as network security device 66 at the production site. The recovery control server 84 executes a periodic request (keep alive) to each application server 62 managed to monitor their accessibility. In this way, the recovery control server 84 can monitor whether there is a problem in the production site 52. In addition, the recovery control server 84 may monitor the storage flow from one or more application servers 62 to the SAN storage 82 at the recovery site 54 via the mirroring software 68. Many techniques can be used to monitor the production site 52 from the recovery control server 84, such as by polling. As described further below, the recovery control server 84 also controls automatic switching from the production site 52 to the recovery site 54 if a problem is detected at the production site. In doing so, it may be necessary to select one of the recovery servers 78 from the pool of available servers that are most closely associated with the application server 62 where the problem was detected. In addition, the recovery control server 84 automatically reconfigures the necessary networks 56, 66 so that the extranet client 58 and intranet client 64 can automatically and seamlessly access the recovery server 78. Finally, the recovery control server 84 can automatically manage failback conditions when the application server 62 is restored and data from the SAN device 82 needs to be copied back to the production site 52.

  FIG. 2 shows a more detailed example of a potential production site 52. The application server 62 includes a system image 100. The system image 100 includes an operating system 102, a set of applications 104, and data 106 operated by the operating system and applications. Mass storage 60 includes a local storage device where data 106 is saved. A storage initiator 110 is also present on the application server 62. The storage initiator 110 is a software module that enables data to be transferred to a remote storage volume that can be accessed via a network infrastructure (eg, LAN, WAN, etc.). The software mirror 68 is a software module that executes synchronous replication of a local image in the application server 62. The local image is then stored at the recovery site 54 via the storage initiator module 110. The software mirror module 68 can also take snapshots of the system image to hold multiple system images at different time intervals. Thus, in addition to having the last transaction, it is possible to have a stable copy of the system at different time intervals. This allows the system to return to a known stable state because the system can have one or more stable copies taken at different times. Since a remote copy of the system image is performed using software mirror 68, the architecture is freed from proprietary solutions belonging to a particular manufacturer. The above-mentioned type of software mirror module can be downloaded from the Internet URL: http://www.veritas.com/Products/www?c=product&refId=3 (as of the filing date of this patent application).

  Intranet client 64 can access application server 62 via network device 112 (shown here as Level 2 and Level 3 devices). Thus, the network device 112 is a device used for a production site packet-based network and is intended to connect to a third party packet-based network for access at the metropolitan, national, or international level. to enable. The network device 112 may be a LAN / MAN technology, an IP router, or the like. Security device 114 provides security against unauthorized access from extranet clients. For example, a firewall, an intrusion detection system, etc. can be mentioned as a security device. The security device can be monitored and configured via any desired standard (eg, SNMP) or command line interface.

  FIG. 3 shows the WAN 56 in more detail. WAN 56 allows interconnection between extranet 58, production site 52, and recovery site 54. Various protocols can be used. For example, a multi-protocol label switching (MPLS) protocol can be used to enable virtual private network (VPN) services to interconnect two sites. WAN 56 includes a plurality of network switching devices, indicated generally at 120. Specifically, customer edge devices (eg, network devices such as routers and switches used to connect the network to client computers) 122, 124 are located at the production site 52 and the recovery site 54, respectively, and are also provider With provider edge (PE) network devices 126, 128 (e.g., routers that are part of the service provider's network that allow connection with customer edge devices) located at a point of presence (PoP) Enable. Other provider network devices 130 (shown simply as P) allow communication between provider edges 126, 128 and extranet 58. To add a new site to an existing VPN, the provider can provide the correct settings to the CE and PE devices, for example using a provisioning platform (provisioning platform). MPLS VPN allows IP level connections to be provided to sites belonging to the same VPN. More innovative solutions (such as virtual private LAN services) make it possible to install Ethernet connections between sites belonging to the same VPN. Just like the MPLS VPN solution, it only works with provider CE and PE devices to add new sites to VPLS. The main difference between these two solutions is that in the case of VPLS services, the provider does not manage the routing done by the customer.

  As described further below, the recovery control server 84 at the recovery site has the ability to reroute the network device 120 so that the extranet 58 and intranet client 64 can access the recovery site 54 in the event of a failure. . The recovery control server 84 autonomously sets operation rules for systems belonging to the operation domain (production site and recovery site) and, if necessary, other control systems generally executed by a third party such as a network operator. By interfacing, you can interact with the system outside its direct control.

FIG. 4 shows further details of the recovery control server 84. For purposes of explanation, the WAN is used in conjunction with the MPLS functionality, but other packet-based networks that allow for the configuration of private virtual network solutions as described above can also be used. The customer information manager module 150 (CIMM) is a software module that handles the metadata inside the repository module 152 and also shows the characteristics of the application server 62 of the production site 52. The information stored in the repository module 150 can include the following:
• Application server routing plan.
Application server access rules for intranet / extranet clients.
Information about the network topology of the production site and the interconnection between the production site and the recovery site.
-Hardware features of the application server.
-Image features related to operating system, installed software packages, etc.
• An agreed service level agreement for the service.
• Availability of recovery site servers that have features compatible with production site application servers.

  The application server control module (ASCM) 154 is a software module that checks the accessibility of the application server at the production site 52. This check is performed by polling the server's IP address or by confirming that the application installed in the server 62 is active. An additional level of control is enabled by software that allows a synchronous mirroring process between local and remote storage. If the application server 62 cannot be accessed for a period that exceeds a configurable threshold (eg, 30 seconds, but this time may vary depending on the particular application), the ASCM module 154 initiates a disaster recovery procedure. Make a request to

The storage gateway control module (SGCM) 156 can request the storage gateway management system to perform the following functions.
Access to the storage device at the recovery site 54 by the application server 62. Storage access is managed through access control list (ACL) settings, which specify which servers have permission to access a given storage device.
A request to release or allocate resources. This feature makes it possible to make a request to release pre-allocated resources, for example because it has been decided to stop the disaster recovery service for a given application server, or vice versa. Allows new storage resources to be allocated. This feature updates information about the SLA signed by the customer and is maintained in the repository 152.
Management of replication process in failback conditions. After the disaster recovery procedure, this function allows a copy of the data used locally by the recovery server 78 at the recovery site 54 to be executed on the storage volume at the production site 52. After the data has been restored in a consistent manner at the production site, it is possible to return to the initial operating conditions, where the services accessed by the intranet and extranet clients are accessed by the application server at the production site. Published.
• Check usage status of allocated resources. With this function, it is possible to obtain statistics on the effective use of storage devices and to evaluate in advance the acquisition of new devices (processing and storage resources for the recovery site pool).

  The provisioning platform control module (PPCM) 158 is a software module that handles requests for the provisioning platform. The network device supplier provides a provisioning platform that allows requests received in the programming metalanguage to be translated into settings provided to the network device. The PPCM 158 performs these requests based on the topology of the network that interconnects the production site 52 and the recovery site 54. Provisioning systems automatically generate configuration commands to be given to devices based on a topological description of the network infrastructure they handle and a description of the desired final state of the network. These requests can be made in the following modes, for example.

  Static mode: Information required to make a request to the provisioning system is pre-assigned inside the customer repository. In the event of a failure, information is extracted from the database, prepared according to a scheme, and sent to the provisioning system.

  Dynamic mode: The information required to make a request to the provisioning system is obtained dynamically through the interaction between the provisioning system and the control module. In this case, it is not always necessary to preconfigure information in the database.

The failure recovery control module (DRCM) 160 is a software module that handles automating the failure recovery process in response to the occurrence of a failure informed by the application server control module 154. This module can launch the following procedure according to the information contained in the customer repository 152.
Interaction with the customer information manager module 150 for the purpose of collecting information regarding the network topology of the production site 52 and the interconnection between the production site 52 and the recovery site 54.
Send a message to the provisioning platform control module 158 to move the routing plan set at the production site 52 to the recovery site 54. This stage includes changes to the CE device settings present at the customer site and the provider site, and the corresponding PE device settings.
Interaction with the storage gateway control module 156 for the purpose of identifying recent system images saved on the SAN device 82 in the recovery site 54.
Setting of the DHCP (Dynamic Host Configuration Protocol) server at the recovery site so that the designated recovery server in the server pool at the recovery site 54 receives the same IP address as the application server 62 at the production site 52 at the time of diskless startup.
Interaction with the customer information manager module 150 to identify the hardware systems belonging to the resource pool of the recovery site 54 that have characteristics compatible with the application server 62.
Enable the diskless boot procedure on the recovery server 72. For example, the types of URLs available for download from the URL: http://www.cisco.com/en/US/products/hw/ps4159/ps2160/products_installation_and_configuration_guide_book09186a00801a45b0.html (as of the filing date of this patent application) A diskless boot procedure can be used.

  Modules 150, 154, 156, 158 and 160 are executed by the CPU 172 in the recovery control server 84. In addition, these modules interact with the interface module 162 for communication. The interface module 162 includes various adapters, including a keep alive module 164, a storage gateway adapter 166, a provisioning platform adapter 168, and a storage platform adapter 170.

  When the application server 62 is restored at the production site 52, a failback procedure can be started manually or automatically to return the network settings to the state before the failure and release the allocated resources. The failback procedure follows a logic similar to the recovery procedure because it has obvious symmetry with respect to the recovery mode.

To initially set up the system, a software mirror 68 is installed on the application server 62 to perform synchronous or asynchronous mirroring or periodic replication. The recovery control server 84 performs several setting operations. For example, the SGCM 156 executes setting for associating the storage 60 of the production site 52 with the IP address of the application server 62. The PPCM 158 makes a request to the provisioning system for network settings to be loaded inside the repository module 152. The information loaded can include the following:
CE-PE network device ID used to secure the connection between the production site 52 and the recovery site 54. CE-PE network device ID used to ensure accessibility to the recovery site from all sites involved in disaster recovery. A routing plan used at the production site to move to the recovery site in case of disaster recovery. An access control list set on the CE device at the production site that defines service access rules is made available to the application server via an extranet connection.

  The CIMM 150 in the recovery control server 84 adds information about the application server 62 and the production site to the repository module 152. Such information includes server hardware characteristics (eg, system image size, number of network interfaces, etc.), application server software characteristics, and information emitted from the PPCM 158.

  Finally, the ASCM 154 activates periodic polling to check server availability. If the server does not respond, it initiates a disaster recovery procedure.

  FIG. 5 shows the system under normal operating conditions. ASCM 154 checks that the application server is active as indicated by arrow 180. It is also desirable for the system administrator of the application server to notify the administrator of the failure recovery service of hardware changes made on the application server platform. Its purpose is to keep the information held in the repository 152 up to date and to be able to select the correct recovery server when a disaster recovery procedure is activated. As indicated by arrow 182, during normal operation, extranet client 58 accesses application server 62 at production site 52. Since the information has been updated on server 62, software mirror 68 ensures that the information is also stored at recovery site 54 as indicated by arrow 180.

If the ASCM 154 does not receive an ACK message from the application server 62 for a time interval that exceeds a configurable threshold, a failure recovery procedure is invoked. Using the DRCM 160, the recovery control server 84 can start the following procedure.
1) Interact with CIMM 150 for the purpose of collecting information regarding the network topology of the production site and the interconnection between the production site and the recovery site.
2) Send a message (Migrate Network) to the PPCM to move the routing plan configured at the production site to the recovery site. This stage involves changes to the CE-PE device settings at the customer site and provider site.
3) Interact with the SGCM for the purpose of identifying the latest system image saved on the storage system in the recovery site (can match the latest if a replication mechanism is used).
4) Set the recovery site DHCP server to enable the recovery server and receive the same IP address as the production site application server when activated (diskless activation).
5) Interact with the CIMM to identify the hardware system belonging to the resource pool at the recovery site that has features compatible with the application server.
6) Enable diskless boot procedure: At this stage, the GUI informs the human operator that he can start the selected recovery server from the waiting hardware resource pool.

  The recovery server, which may not have internal storage (diskless), has the IP address and information associated with accessing the storage system containing the application server's system image (IP address, volume name, LUN, etc.) To get it, make a request to the DHCP server. Once this information is received, the recovery server can perform a diskless boot on the network. When invoking the finish, the recovery server matches the original application server until the last transaction. Any intranet, extranet or Internet client can access the restored service of the recovery server via TCP / IP using the connection established in the disaster recovery procedure.

  FIG. 6 shows the data flow after the failure recovery procedure is started. As indicated by arrow 188, when an extranet client attempts to access production site 52, the request is automatically rerouted to recovery site 54. This is transparent to the extranet user, and the extranet user does not need to type a different network address for the recovery site. Thus, from the extranet client's point of view, the production site is still accessed even though it is actually being accessed.

  FIG. 7 shows failback conditions. The failback procedure makes it possible to return to the initial state after the disaster recovery procedure. Even after the application server 62 at the production site 52 is restored, there is still a period during which all services are provided by the recovery site.

The failback procedure can include the following steps to return to the normal operating conditions described above.
1) SGCM 156 activates a reverse replication procedure to perform a consistent copy of the data at the recovery site on the production site as indicated by arrow 190.
2) In order to move the routing plan configured at the recovery site to the production site, the DRCM sends a message (Migrate Network) to the PPCM. This stage involves changes to the CE-PE device settings at the customer site and provider site.
3) The service at the production site is resumed, and the client accesses the original application server 62.
4) The hardware resources used by the recovery server 78 are released at the recovery site 54 (returned to the free resource pool).
5) The synchronous / asynchronous mirroring (or replication) procedure is restarted.

  FIG. 8 shows a flowchart of a method for carrying out the present invention. In process block 210, the recovery site detects a problem at the production site by polling. At process block 212, the recovery site automatically performs a network reconfiguration so that attempts to access the production site are routed to the recovery site. Such a request may be derived from an extranet or intranet request.

  The advantages of the present invention are clear from the above description.

  In particular, one advantage is that RPO and RTO parameters are optimized by replication performed by the mirroring process.

  Another advantage is that the present invention does not rely on software / hardware solutions employed at production or recovery sites.

  Yet another advantage is automatic rerouting that routes clients to the recovery server.

  Finally, it will be apparent that many changes and modifications can be made to the invention, but all fall within the scope of the invention.

  For example, the solution can be extended and modified to work on individual components that achieve it, or existing components can be integrated into a control architecture in the art.

  In particular, at the production site, the components that provide the synchronous / asynchronous mirroring software are not limited to a specific technology. They can be realized by host-based, network-based or array-based virtualization mechanisms and software modules or specific hardware components.

  Further, the “failure” described here means that the production site is not functioning for any reason. This does not mean that an actual obstacle had to occur.

  Furthermore, in the interconnect network between the production site and the recovery site, the protocol used for the mirror / replication flow to the remote site replays the same writes that occur at the production site in the recovery site storage. As long as the function to perform is performed, it can be a standard or proprietary protocol (eg, SCSI).

  In addition, at the recovery site, a mechanism for starting up on the network is a transport protocol that is different from the protocol used to access data at the production site or in the interconnection between the two sites ( For example, Fiber Channel or iSCSI) can be used locally at the recovery site. In addition, the recovery control server can be built in a distributed manner that builds everything together in the same device, or takes advantage of other device features or functionality to achieve the required basic functionality. The control logic for these functions can be implemented in an independent system or integrated as an additional function in one of the devices. In particular, the network rerouting of services provided after restarting the application server at the recovery site is partly or fully controlled by another system and integrated into the intelligence module of the on-hand system to provide an extranet / It can be left to dynamic management of intranet VPN sites. This rerouting mechanism can use various alternatives (such as MPLS VPN or stackable VLAN / dotlq) based on the specific connectivity used between the two sites and between the client and production sites. Similarly, the components of the storage gateway inside the recovery control server can be realized by integrating a base module already present in a commercial product such as a gateway or storage switch.

  In order to further optimize the restoration of the primary site to normal conditions (failback), the recovery and restore mechanism of this solution can be a dynamic or non-dynamic specific QoS mechanism, To speed up the operation during the recovery and restore phase, the restore activity time window is reduced to provide an interconnect between the two sites that has a wider transmission bandwidth than is available under normal operating conditions.

  As expected, the hardware features of the application server protected by this solution are optimized to optimize the processing hardware resources created by the recovery server at the recovery site, especially on the individual recovery server. The physical resources can be virtualized by installing specific software modules so that they can be separated from those of the system constituting the system.

  This makes it easier to make such a recovery server compatible with the hardware of the primary server at the production site and to ensure more efficient resource allocation. In this way, thanks to the ability to virtualize the physical drivers of the system (1: 1 virtualization), different hardware can be emulated on the same physical settings, a state-of-the-art disaster recovery service Can be freed from adopting a server with the same hardware settings as that of the application server at the production site. In addition, virtualization software can be used to simultaneously utilize the same hardware resources for more than one application server image (n: 1 virtualization).

50 System 52 of the Present Invention Production Site 54 Recovery Site 56 Network 58 Connected Between Production Site and Recovery Site 58 Extranet Client

Claims (8)

A mirroring module (68) provided in the application server (62) of each production site (52) for mirroring at least a part of the production site (52) to the recovery site (54), the recovery site (54) ) Is intended to serve as a plurality of different production sites (52) and is adapted to couple to the plurality of different production sites (52) via a packet-based network (56). 68)
Provided at the recovery site (54) to detect a problem at the production site (52) and in response to detecting the problem at the production site (52), an attempt to access the production site (52) A disaster recovery system (50) including a recovery control server (84) that automatically reconfigures the packet-based network (56) to be routed to a site (54);
The recovery control server (84) is further adapted to select a recovery server (78) at the recovery site (54) from a pool of recovery servers, and selecting the application server (62) at the production site (52) includes a obtaining a hardware features associated, and to match the features as possible to the hardware features of the recovery server in the pool (78) and,
A computer sending a request destined for the production site (52) is connected to the packet-based network (56), the packet-based network (56) including a device for routing the request, the device , The request from the computer destined for the production site (52) is set to reach the production site (52), and reconfiguring the packet-based network (56) (52) the request from the computer directed to the viewing contains that resetting the device to reach the recovery site (54),
The recovery control server (84) is configured to store information about the network topology of the production site (52) and the interconnection between the production site (52) and the recovery site (54), and the production site Reconfiguring the device so that the request from the computer destined for (52) reaches the recovery site (54) means that the recovery control server (84) Collecting the information about the topology of the network and the interconnection between the production site (52) and the recovery site (54), and the routing plan set at the production site (52) to the recovery site (54) including disaster recovery systems to move (50).   The disaster recovery system (50) further comprises a database (152) stored at the recovery site (54) and adapted to store information about the application server (62) at the production site. The fault recovery system according to claim 1 (50). The information about the application server (62) is:
Application server routing plan,
Application server access rules for intranet and extranet clients,
Hardware features of the application server (62);
The fault recovery system (50) of claim 2, comprising one or more of image features.   Reconfiguring the packet-based network (56) comprises rerouting a request having the network address of the production site (52) to the recovery site (54). The fault recovery system (50) according to one aspect.   The recovery control server (84) uses the network address of the application server (62) of the production site (52) to select the recovery server selected from the intranet (64) and extranet (58) computers. The fault recovery system (50) of claim 4, further adapted to allow access to 78). Detecting problems at the production site (52)
Checking the accessibility of the application server (62) at the production site (52);
6. Initiating a disaster recovery procedure if the application server (62) is inaccessible for a period of time beyond a configurable threshold, according to any one of the preceding claims. Disaster recovery system (50). Detecting problems at the production site (52)
Polling the application server (62) of the production site (52);
Waiting for a response from the application server (62) for a predetermined period;
The fault recovery system (50) according to any one of the preceding claims, comprising starting a fault recovery procedure when the predetermined period ends. The recovery control server (84)
Upon detecting the solution of the problem at the production site (52), the production site (52) is automatically restored by copying (190) recovery data from the recovery site (54) to the production site (52). And
The system further adapted to automatically reconfigure the packet-based network (56) to allow access to the production site (52) after restoring the production site (52). The fault recovery system (50) according to any one of 1 to 7.

Images