Reducing recovery time for business organizations in case of disasters

• US 8,112,659 B2
• Filed: 06/19/2009
• Issued: 02/07/2012
• Est. Priority Date: 06/19/2009
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Agneeswaran, Vijay Srinivas, Venkataraja, Hariprasad Nellitheertha
• Primary Examiner(s): CHU, GABRIEL L
• Application Number:
  US12/487,818
• Publication Number:
  US 20100325473A1
• Time in Patent Office: 963 Days
• Field of Search: None
• US Class Current: 714/4.11
• CPC Class Codes: G06F 11/2025 using centralised failover control functionality
• CPC Class Codes: G06F 11/2041 with more than one idle spare processing component

Abstract

An aspect of the present invention reduces the recovery time for business organizations in case of disasters. In one embodiment, a disaster recovery system containing a primary site and a backup site (implemented as a cluster) is maintained. Application instances are executed in both the primary site and the backup site, with the number of instances executed on the backup site being fewer than that executed on the primary site. During normal operation, user requests received are processed using only the instances executing in the primary site, while the instances executing in the backup site are used in a standby state. On identifying that a disaster has occurred, the user requests received immediately after identification of the disaster are processed using only the instances executing in the backup site. The cluster at the backup site is then scaled out to add application instances until a desired level/percentage is achieved.

Claims

1. A disaster recovery system for processing user requests received from client systems, said disaster recovery system comprising:

a primary site containing a first set of nodes to process user requests during a normal operation of said disaster recovery system;

a backup site implemented as a cluster containing a second set of nodes, which are designed to be used in a standby state during said normal operation of said disaster recovery system,

wherein said first set of nodes execute a first plurality of application instances and said second set of nodes execute a second plurality of application instances during said normal operation of said business organization, wherein a first set of user requests received during said normal operation are processed using only said first plurality of instances, wherein said second plurality of instances are used in a standby state during said normal operation, wherein said second plurality of application instances is fewer than said first plurality of application instances,

upon identification of a disaster, said second set of nodes to process user requests using said second plurality of application instances instead of said first set of nodes, and to thereafter scale out said cluster to add a third set of nodes, wherein said second set of nodes and said third set of nodes together process user requests in a duration of said disaster.

2. The disaster recovery system of claim 1, wherein said backup site further contains a first scheduler designed to receive a first set of user requests and to distribute said first set of user requests among said second set of nodes immediately upon identification of said disaster,

said first scheduler further designed to scale-out said cluster thereafter,

said first scheduler designed to receive a second set of user requests and to distribute said second said user requests among said second set of nodes and said third set of nodes after said scale-out in said duration.

3. The disaster recovery system of claim 2, wherein said primary site is also implemented as another cluster containing a second scheduler, wherein said second scheduler is designed to receive a third set of user requests during said normal operation and to distribute said third set of user requests among said first set of nodes, said disaster recovery system further comprising:

a request forwarder to receive all user requests and forward each request to said second scheduler during said normal operation and to said first scheduler after identification of said disaster.

4. The disaster recovery system of claim 3, wherein said identification comprises determining that said second scheduler is not reachable based on a communication protocol implemented between said request forwarder and said second scheduler,

wherein said request forwarder is designed to forward requests to said first scheduler upon said determining that said second scheduler is not reachable.

5. The disaster recovery system of claim 1, wherein said first set of nodes in said primary site executes application instances of a plurality of application types during said normal operation,

wherein at least one application instance of each of said plurality of application types is also executed in said second set of nodes in said backup site during said normal operation.

6. The disaster recovery system of claim 5, wherein application instances are executed in the context of virtual machines at both said primary site and said backup site.

7. A method of reducing recovery time for a business organization in case of disasters, said method comprising:

maintaining a primary site and a backup site, said primary site containing a first set of nodes and said backup site containing a second set of nodes, wherein said second set of nodes in said backup site are implemented as a cluster;

executing a first plurality of application instances on said first set of nodes and a second plurality of application instances on said second set of nodes during a normal operation of said business organization, wherein said second plurality of application instances is fewer than said first plurality of application instances;

processing a first set of user requests received during said normal operation using only said first plurality of application instances, wherein said second plurality of application instances are used in a standby state during said normal operation;

identifying that a disaster has occurred associated with said primary site;

processing a second set of user requests received immediately after identification of said disaster using only said second plurality of application instances.

8. The method of claim 7, wherein recovery time for said business organization is reduced due to said executing said second plurality of application instances in said standby state during said normal operation and then processing said second set of user requests using said second plurality of application instances immediately after said identification of said disaster.

9. The method of claim 8, further comprising:

scaling out said cluster to add a third set of nodes executing a third plurality of application instances; and

processing a third set of user requests received after said scaling out, using said second plurality of application instances and said third plurality of application instances.

10. The method of claim 9, wherein said scaling out is performed a plurality of times in a phased manner until the total number of application instances executing in said backup site equals a desired percentage of the number of application instances that were executing in said primary site before said disaster.

11. The method of claim 10, wherein said desired percentage equals 100, whereby the execution state of said primary site is recreated in said backup site.

12. The method of claim 9, wherein said first set of nodes in said primary site is implemented as another cluster, said method further comprising:

using a first scheduler in said another cluster at said primary site to perform said executing said first plurality of application instances, said processing said first set of user requests; and

using a second scheduler in said cluster at said backup site to perform said executing said second plurality of application instances, said processing said second set of user requests, said scaling out and said processing said third set of user requests.

13. The method of claim 12, wherein said identifying is performed in a request forwarder provided external to said primary site and said backup site.

14. The method of claim 9, wherein said first set of nodes in said primary site executes application instances of a plurality of application types during said normal operation,

wherein at least one application instance of each of said plurality of application types is also executed in said second set of nodes in said backup site during said normal operation.

15. The method of claim 14, wherein said application instances are executed in the context of virtual machines at both said primary site and said backup site.

16. A non-transitory machine readable medium storing one or more sequences of instructions for causing a scheduler system to reduce recovery time for a business organization in case of disasters, said scheduler system being provided in a backup site corresponding to a primary site, said primary site being used during normal operation of said business organization, wherein execution of said one or more sequences of instructions by one or more processors contained in said scheduler system causes said scheduler system to perform the actions of:

executing a second plurality of application instances on a first set of nodes at said backup site, wherein said second plurality of application instances are used in a standby state during said normal operation, wherein said second plurality of application instances is fewer than the number of application instances executing at said primary site during said normal operation; and

processing a second set of user requests received immediately after identification of occurrence of a disaster using said second plurality of application instances,

whereby recovery time for said business organization is reduced due to said executing said second plurality of application instances in a standby state during said normal operation and then processing said second set of user requests using said second plurality of application instances immediately after identification of said disaster.

17. The non-transitory machine readable medium of claim 16, further comprising:

adding a third set of nodes executing a third plurality of application instances at said backup site; and

processing a third set of user requests received after said adding, using said second plurality of application instances and said third plurality of application instances.

18. The non-transitory machine readable medium of claim 17, wherein said backup site is implemented as a cluster, wherein said adding comprises scaling out said cluster.

19. The non-transitory machine readable medium of claim 18, wherein said scaling out is performed a plurality of times in a phased manner until the total number of application instances executing in said backup site equals a desired percentage of the number of application instances that were executing in said primary site before said disaster.

20. The non-transitory machine readable medium of claim 19, wherein said desired percentage equals 100, whereby the execution state of said primary site is recreated in said backup site.