Method and system for replicated and consistent modifications in a server cluster

• US 6,163,855 A
• Filed: 04/17/1998
• Issued: 12/19/2000
• Est. Priority Date: 04/17/1998
• Status: Expired due to Term

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Shrivastava, Sunita, Vert, John D., Gamache, Rod
• Primary Examiner(s): Iqbal, Nadeem
• Application Number:
  US09/062,359
• Time in Patent Office: 977 Days
• Field of Search: 714/4, 714/2, 714/3, 714/7, 714/8, 714/9, 714/10, 714/12, 714/13, 714/16, 714/18, 714/25, 714/31, 714/39, 714/43, 395/575, 395/325, 395/600, 395/800, 395/200.68
• US Class Current: 714/4.4
• CPC Class Codes: G06F 11/1443 Transmit or communication errors
• CPC Class Codes: G06F 2201/82 Solving problems relating to consistency

Abstract

A method and system for communicating modification information to servers in a server cluster. Local changes, such as modifications to a resource requested at one node, are associated into a single transaction. A master node, such as the node that owns the set of resources corresponding to the modifications in the transaction requests permission from a locker node to replicate the transaction. When permission to replicate the transaction is received from the locker node, the master node replicates the transaction by requesting each node in the cluster, one node at a time, to commit the transaction. Any node that does not commit the transaction is removed from the cluster, ensuring consistency of the cluster. Failure conditions of any node or nodes are also handled in a manner that ensures consistency.

Claims

1. A method of communicating modification information to servers in a server cluster, comprising associating a plurality of local changes at one node into a transaction, requesting permission from a locker node to replicate the transaction, receiving permission from the locker node to replicate the transaction, and replicating the transaction by requesting each node in the cluster to commit the transaction, wherein any node that does not commit the transaction is excluded from the cluster.

2. The method of claim 1 wherein the step of replicating the transaction includes the steps of replicating the transaction to each of the nodes one node at a time.

3. The method of claim 2 wherein the transaction is replicated to each of the nodes in a predetermined replication order.

4. The method of claim 1 further comprising the steps of detecting a failure of the locker node, and selecting another node in the cluster as a new locker node.

5. The method of claim 1 further comprising the steps of determining a master node corresponding to the changes, requesting the master node to replicate the transaction, detecting a failure of the master node, and selecting another node in the cluster to replicate the changes.

6. The method of claim 5 wherein the step of selecting another node in the cluster comprises the step of selecting the locker node.

16. The method of claim 1 further comprising, queuing the permission request at the locker node until one or more prior transactions have completed replication, and upon completion of the replication of the one or more prior transactions, sending permission to replicate the transaction.

7. In a server cluster of at least two nodes linked together for communication by a communication mechanism, a system for communicating modification information to each of the nodes of the cluster, comprising, a locker node for receiving requests to broadcast global updates and for granting permission to broadcast global updates, a master node, the master node associated with a transaction including information of at least one modification, the master node requesting and receiving permission from the locker node to replicate the transaction, the master node communicating the transaction via the communication mechanism to each other node of the cluster, and each node of the cluster committing the transaction or leaving the cluster.

8. The system of claim 7 wherein the locker node and the master node are the same node of the cluster.

9. The system of claim 7 wherein the locker node and the master node are separate nodes of the cluster communicating via the communication mechanism.

10. The system of claim 9 wherein only the locker node and the master node are in the cluster.

11. The system of claim 7 wherein the master node includes means for communicating the transaction to each other node in a sequence.

12. The system of claim 7 further comprising means for detecting a failure of the locker node, and means for selecting another node in the cluster as a new locker node.

13. The system of claim 7 further comprising means for detecting a failure of the master node, and means for selecting another node in the cluster to communicate the transaction to each other node.

14. The system of claim 7 wherein each node includes a local database for committing the transaction thereto.

17. The system of claim 7 wherein the transaction includes information of at least two modifications.

18. The system of claim 17, further comprising, queuing the request for permission at the locker node until one or more prior transactions have completed replication, and upon completion of the replication of the one or more prior transactions, sending permission to replicate the transaction.

15. In a server cluster of at least two nodes linked together for communication by a communication mechanism, a method of communicating modification information to each of the nodes of the cluster, comprising:

sending a request to replicate a transaction from a requester node to a locker node, the transaction including a plurality of local changes, performing the transaction at the locker node, receiving control at the requestor node from the locker node, performing the transaction at the requester node, replicating the transaction consistently in the cluster by requesting each other node in the cluster to perform the transaction and excluding from the cluster each other node that fails to commit the transaction, and informing the locker node that the operation is complete.

19. The method of claim 15 further comprising, queuing the request at the locker node until one or more prior transactions have completed replication, and upon completion of the replication of the one or more prior transactions, sending control to replicate the transaction.