System and method for managing software upgrades in a distributed computing system

• US 6,966,058 B2
• Filed: 06/12/2002
• Issued: 11/15/2005
• Est. Priority Date: 06/12/2002
• Status: Expired due to Fees

• Current Assignee: Agami Systems, Inc.
• Original Assignee: Agami Systems, Inc.
• Inventors: Ekambaram, Dhanabal, Hahn, Terry G., Earl, William J.
• Primary Examiner(s): Nguyen-Ba, Antony
• Application Number:
  US10/170,881
• Publication Number:
  US 20030233648A1
• Time in Patent Office: 1,252 Days
• Field of Search: 717168-178, 707/200, 707/203, 714/47, 714/1, 709/223
• US Class Current: 717/171
• CPC Class Codes: G06F 8/65 Updates security arrangements therefor G06F21/57

Abstract

A system and method for managing software upgrades in a distributed computing system. The distributed computing system may include a plurality of nodes which provide one or more fault-tolerant services. The system and method perform software upgrades in a sequential or “rolling” manner (e.g., node by node). The rolling upgrade process allows all services and data of the distributed computing system to remain operable and available throughout the upgrade process.

Claims

1. A system for managing a software upgrade in a distributed computing system having a plurality of nodes that provides a plurality of fault-tolerant services, wherein a first set of nodes providing a first fault-tolerant service can differ from, yet can also overlap with, a second set of nodes providing a second service, and wherein making an upgrade current on a given node can take an amount of time sufficient to be considered a fault if not otherwise masked by fault-tolerance, the system comprising:

at least one node which is communicatively connected to the plurality of nodes and which is configured to receive a software release, and to upgrade each of the plurality of nodes with the software release in a sequential manner, accounting for the possibility of different versions of software running on different nodes of the system, whereby the plurality of fault-tolerant services remain available while the software upgrade is in progress

a service which is configured to notify the at least one node when a first copy of fault-tolerant service becomes unavailable; and

wherein the at least one node is configured to assign a protected status to a node including any portion of a surviving copy of the fault-tolerant service, the protected status being effective to prevent the node from being upgraded.

2. The system of claim 1 wherein service is further configured to notify the at least one node when the first copy of the fault-tolerant service is restored, and wherein the at least one node is configured to remove the protected status of the affected nodes once fault-tolerant status is restored.

3. The system of claim 1 wherein the at least one node is further configured to determine whether the software release is compatible with the current software running on the plurality of nodes and to upgrade the plurality of nodes only if the software release is compatible with the current software.

4. The system of claim 3 further comprising:

a configuration database which is communicatively coupled to the at least one node and which stores information regarding the plurality of nodes.

5. The system of claim 4 wherein the at least one node compares compatibility information contained in the software release to information identifying the current software running on the plurality of nodes, which is stored in the configuration database, to determine whether the software release is compatible with the current software running on the plurality of nodes.

6. The system of claim 3 wherein the at least one node is further configured to detect when a first upgrade to a compatible software is in progress, and to upgrade the plurality of nodes to the software release once the first upgrade is complete.

7. The system of claim 1 wherein the at least one node is configured to upgrade a node by loading the software upgrade onto the node and rebooting the node.

8. The system of claim 1 wherein the at least one node which upgrades the nodes in the system includes a first node and at least one second node, wherein the first node has primary responsibility for performing upgrades and wherein the at least one second node acts as a backup.

9. The system of claim 1 further comprising a plurality of agents which are respectively disposed on the plurality of nodes and which are configured to assist in upgrading the nodes with the software upgrade under remote control of the at least one node.

10. The system of claim 1 further comprising an interface which is communicatively connected to the at least one node, and which is configured to allow a user to enter an upgrade request, effective to cause the at least one node to initiate an upgrade to the software release.

11. The system of claim 10 wherein the interface is further configured to allow a user to enter a downgrade request, effective to cause the at least one node to downgrade the software currently running on the plurality of nodes in a sequential manner, whereby none of the fault-tolerant services becomes unavailable while the downgrade is in progress.

12. A method for managing a software upgrade in a distributed computing system having a plurality of nodes that provide a plurality of fault-tolerant services, wherein a first set of nodes providing a first fault-tolerant service can differ from, yet can also overlap with, a second set of nodes providing a second service, and wherein making an upgrade current on a given node can take an amount of time sufficient to be considered a fault if not otherwise masked by fault-tolerance, the method comprising the steps of:

receiving a new software release;

upgrading each of the plurality of nodes with the new software release in a sequential manner, accounting for the possibility of different versions of software running on different nodes of the system, whereby the plurality of fault-tolerant services remains available while the software upgrade is in progress determining whether a first copy of a fault-tolerant service has become unavailable; and

preventing any node having a surviving copy of the fault-tolerant service from being upgraded while the first copy of the fault-tolerant service is unavailable.

13. The method of claim 12 further comprising the steps of:

detecting that a previously unavailable copy of a fault-tolerant service has recovered; and

upgrading any node having the surviving copy of the fault-tolerant service.

14. The method of claim 12 further comprising the step of:

determining whether the new software release is compatible with a current software release that is being run on the distributed computing system; and

performing the software upgrade only if the new software release is compatible with the current software release that is being run on the distributed computing system.

15. The method of claim 14 further comprising the step of:

determining whether a first software upgrade to a compatible new software release is in progress;

waiting for the first software upgrade to be completed; and

performing a second software upgrade to another software release.

16. The method of claim 12 wherein the step of upgrading a node includes loading the new software release onto the node and rebooting the node.

17. The method of claim 12 wherein the new software release comprises a patch release.

18. A method for managing a software upgrade in a distributed file system having a plurality of nodes, which provide a plurality of fault-tolerant services, wherein a first set of nodes providing a first fault-tolerant service can differ from, yet can also overlap with, a second set of nodes providing a second service, and wherein making an upgrade current on a given node can take an amount of time sufficient to be considered a fault if not otherwise masked by fault-tolerance, comprising:

receiving a new software release;

determining whether the new software release is compatible with a current release running on the distributed file system;

initiating a rolling upgrade process if the new software release is compatible;

performing the rolling upgrade process by sequentially loading and rebooting each of the plurality of nodes with the new software release;

accounting for the possibility of different versions of software running on different nodes of the system; and

ensuring that the plurality of fault-tolerant services remains available throughout the rolling upgeade process services remains available throughout the rolling upgrade process includes the steps of;

determining whether a first copy of a fault-tolerant service has become unavailable; and

preventing any node having a surviving copy of the fault-tolerant service from being upgraded while the first copy of the fault-tolerant service is unavailable.

19. The method of claim 18 wherein the plurality of fault-tolerant services includes services selected from the group consisting of bit file storage services, metadata services and gateway services.