Transparent high availability for stateful services

• US 10,025,634 B2
• Filed: 04/28/2016
• Issued: 07/17/2018
• Est. Priority Date: 01/23/2012
• Status: Active Grant

• Current Assignee: Avago Technologies International Sales Pte Limited (Broadcom, Inc.)
• Original Assignee: Brocade Communications Systems, LLC (Broadcom, Inc.)
• Inventors: Goyal, Girish K., Vobbilisetty, Suresh
• Primary Examiner(s): Do, Chat
• Assistant Examiner(s): Wood, William C
• Application Number:
  US15/141,617
• Publication Number:
  US 20160246650A1
• Time in Patent Office: 810 Days
• Field of Search: None
• CPC Class Codes: G06F 11/1484 involving virtual machines
• CPC Class Codes: G06F 11/202 where processing functionality is redundant redundant communication control functionality G06F11/2005, redundant storage control functionality G06F11/2089
• CPC Class Codes: G06F 11/302 where the computing system component is a software system
• CPC Class Codes: G06F 11/3055 Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available error or fault processing without redundancy G06F11/0703; error detection or correction by redundancy in data representation G06F11/08; error detection or correction by redundancy in operation G06F11/14; error detection or correction by redundancy in hardware G06F11/16
• CPC Class Codes: G06F 11/3079 the data filtering being achieved by reporting only the changes of the monitored data
• CPC Class Codes: G06F 2009/4557 Distribution of virtual machine instances; Migration and load balancing
• CPC Class Codes: G06F 2201/865 Monitoring of software
• CPC Class Codes: G06F 9/45558 Hypervisor-specific management and integration aspects
• CPC Class Codes: G06F 9/46 Multiprogramming arrangements
• CPC Class Codes: G06F 9/5016 the resource being the memory

Abstract

One embodiment of the present invention provides a system. The system includes a high availability module and a data transformation module. During operation, the high availability module identifies a modified object belonging to an application in a second system. A modification to the modified object is associated with a transaction identifier. The high availability module also identifies a local object corresponding to the modified object associated with a standby application corresponding to the application in the second system. The data transformation module automatically transforms the value of the modified object to a value assignable to the local object, including pointer conversion to point to equivalent object of the second system. The high availability module updates the current value of the local object with the transformed value.

Claims

1. A computer system for providing high availability, comprising:

a processor; and

a storage device coupled to the processor and storing instructions that when executed by the processor cause the processor to perform a method, the method comprising;

in response to detecting a failure associated with an object, identifying, by a first high availability module, a pending update which indicates a modified state for a snapshot object, wherein the modified state is different from a state for a corresponding standby object, wherein the snapshot object is a snapshot of the object, and wherein the standby object a standby for the object and is registered with the first high availability module;

in response to determining that the standby object is a dynamic object, allocating memory for the standby object from a local memory pool based on a type of the standby object;

in response to determining that the standby object is not a dynamic object, pairing the standby object with a local object that corresponds to the standby object;

determining whether the pending update is committed in the snapshot object;

in response to the pending update being committed in the snapshot object, processing the pending update for the standby object; and

in response to the pending update being uncommitted in the snapshot object, refraining from processing the pending update for the standby object.

2. The computer system of claim 1, wherein the method further comprises:

de-serializing the second standby object; and

determining whether the second object is a dynamic object.

3. The computer system of claim 1, wherein in response to the pending update being uncommitted in the snapshot object, and in response to identifying no other pending updates that are uncommitted, the method further comprises:

generating a notification message for local applications of the system; and

initiating operation as an active system.

4. The computer system of claim 1, wherein in response to the pending update being uncommitted in the snapshot object, the method further comprises:

rolling back the uncommitted update.

5. The computer system of claim 1, wherein the first-snapshot object corresponds to a third object that is registered with a second high availability module in a second system.

6. The computer system of claim 5, wherein the second standby object and the third object have a same transaction identifier, wherein the identifier is unique in a standby application associated with the second standby object and a working application associated with the third object.

7. The computer system of claim 6, wherein the method further comprises:

determining an intent associated with the same transaction identifier, wherein the intent specifies an operation to be performed by an application in the second system;

storing the intent;

wherein in response to the pending update being committed in the snapshot object, the method further involves discarding the intent; and

wherein in response to the pending update being uncommitted in the snapshot object, the method further involves preserving the intent.

8. A computer-implemented method, comprising

in response to detecting a failure associated with an object, identifying, by a first high availability module, a pending update which indicates a modified state for a snapshot object, wherein the modified state that is different from a state for a corresponding standby object, wherein the snapshot object is a snapshot of the object, and wherein the standby object is a standby for the object and registered with the first high availability module;

in response to determining that the standby object is a dynamic object, allocating memory for the standby object from a local memory pool based on a type of the standby object;

in response to determining that the standby object is not a dynamic object, pairing the standby object with a local object that corresponds to the standby object;

determining whether the pending update is committed in the snapshot object;

in response to the pending update being committed in the snapshot object, processing the pending update for the standby object; and

in response to the pending update being uncommitted in the snapshot object, refraining from processing the pending update for the standby object.

9. The method of claim 8, further comprising:

de-serializing the second standby object; and

determining whether the second object is a dynamic object.

10. The method of claim 8, wherein in response to the pending update being uncommitted in the snapshot object, and in response to identifying no other pending updates that are uncommitted, the method further comprises:

generating a notification message for local applications of the system; and

initiating operation as an active system.

11. The method of claim 8, wherein in response to the pending update being uncommitted in the snapshot object, the method further comprises:

rolling back the uncommitted update.

12. The method of claim 8, wherein the snapshot object corresponds to a third object that is registered with a second high availability module in a second system.

13. The method of claim 12, wherein the standby object and the third object have a same transaction identifier, wherein the identifier is unique in a standby application associated with the second standby object and a working application associated with the third object.

14. The method of claim 13, further comprising:

determining an intent associated with the same transaction identifier, wherein the intent specifies an operation to be performed by an application in the second system;

storing the intent;

wherein in response to the pending update being committed in the snapshot object, the method further involves discarding the intent; and

wherein in response to the pending update being uncommitted in the snapshot object, the method further involves preserving the intent.

15. A non-transitory computer-readable storage medium storing instructions that when executed by a computer cause the computer to perform a method, the method comprising:

in response to detecting a failure associated with an object, identifying, by a first high availability module of a system, a pending update which indicates a modified state for a snapshot object, wherein the modified state that is different from a state for a corresponding standby object, wherein the snapshot object is a snapshot of the object, and wherein the standby object is a standby for the object and registered with the first high availability module;

in response to determining that the standby object is a dynamic object, allocating memory for the standby object from a local memory pool based on a type of the standby object;

in response to determining that the standby object is not a dynamic object, pairing the standby object with a local object that corresponds to the standby object;

determining whether the pending update is committed in the snapshot object;

in response to the pending update being committed in the snapshot object, processing the pending update for the standby object; and

in response to the pending update being uncommitted in the snapshot object, refraining from processing the pending update for the standby object.

16. The storage medium of claim 15, wherein the method further comprises:

de-serializing the second standby object.