Method for upgrading running software processes without compromising fault-tolerance

• US 6,684,396 B1
• Filed: 08/25/2000
• Issued: 01/27/2004
• Est. Priority Date: 02/16/2000
• Status: Expired due to Term

• Current Assignee: Metaswitch Networks Limited (Microsoft Corporation)
• Original Assignee: Data Connection Ltd.
• Inventors: Weeds, Nicolas Peter Everard, Brittain, Paul John
• Primary Examiner(s): Dam, Tuan
• Assistant Examiner(s): Kiss, Eric B.
• Application Number:
  US09/645,537
• Time in Patent Office: 1,250 Days
• Field of Search: 717/168-171, 717/174-176, 714/1-13, 707/204
• US Class Current: 717/168
• CPC Class Codes: G06F 11/1433 during software upgrading
• CPC Class Codes: G06F 8/656 while running
• CPC Class Codes: Y10S 707/99953 Recoverability
• CPC Class Codes: Y10S 707/99955 Archiving or backup

Abstract

When updating a running program in a system that uses a one-to-one backup program, fault-tolerance is lost while the backup program is itself being updated. To overcome this temporary loss of an available backup program, the number of backup copies of a software process is temporarily and dynamically increased during the software upgrade. The extra backup software processes may run on an unused processing unit or may run as an extra software process on a processing unit which is already performing a task. The technique may be applied to communication line cards.

Claims

1. A method for upgrading a software process, running in a fault-tolerant computer system that comprises of at least one processing unit, with a replacement version of said software process without compromising the fault-tolerance coverage provided for said software process during the upgrade operation, said method comprising

a. a first step of synchronizing the internal state of primary copy and a plurality of backup copies of said software process, each of which may be running on any of a subset of said processing units in said computer system

b. a second step of storing at least the current version and said replacement version of said software process in at least one storage medium in said computer system

c. a third step of controlling the version of said software process that is loaded when starting a copy of said software process and the processing unit on which said copy is to be started

d. a fourth step of starting an additional backup copy of said software process in order to ensure that fault-tolerance coverage at least as good as that currently provided for said software process continues to be provided during said upgrade, said additional backup copy being started using said replacement version of said software process

e. a fifth step of detecting when said additional backup copy of said software process has synchronized with the current primary copy of said software process

f. a sixth step of forcing a change of state to make said additional backup copy the new primary copy of said software process

g. a seventh step of upgrading each running backup copy of said software process with said replacement version thereof.

2. The method as set forth in claim 1, wherein said first step is achieved for a software process that does not require ongoing synchronization of internal state by passing identical configuration information to said primary and said backup copies when each copy is started.

3. The method as set forth in claim 1, wherein said first step is achieved by using an eighth step of replicating changes to said internal state from said primary copy to said backup copies, incorporating provision for conversion between version of said internal state if said primary copy and said backup copies are running different versions of said software process.

4. The method as set forth in claim 3, wherein said eighth step is achieved by explicitly replicating state from said primary copy to said backup copies via a message-based interface.

5. The method as set forth in claim 3, wherein said eighth step is achieved by replicating state from said primary copy to said backup copies via a shared storage medium.

6. The method as set forth in claim 1, wherein said second step is achieved by storing each version of said software process under a different name or location in said storage medium.

7. The method as set forth in claim 1, wherein said third step is achieved by specifying the name or location within said storage medium of said version of said software process to be loaded when a new copy of said software process is started, said name or location being specified independently for each request to start a copy of said software process.

8. The method as set forth in claim 1, wherein said fourth step is achieved by use of a specific software process, known as the version manager, which controls said upgrade operation and uses a ninth step for determining whether said additional backup copy should be started for said upgrade operation and on which processing unit said additional backup copy should be started, said additional copy being started by said version manager using said third step.

9. The method as set forth in claim 8, wherein said ninth step is achieved by said version manager monitoring the load currently presented to the system to identify the processing units that have capacity to run said additional backup copy.

10. The method as set forth in claim 8, wherein said ninth step is achieved by provision of static or dynamic configuration information accessible to said version manager that enables said version manager to determine the processing units on which said software process may run and how many copies of said software process may run concurrently on each processing unit on which said software process may run.

11. The method as set forth in claim 8, wherein said ninth step is achieved by said version manager choosing to start said additional backup copy on the processing unit that will minimize traffic on the system bus during said upgrade operation.

12. The method as set forth in claim 8, wherein said fifth step is achieved by said version manager using a message-based interface to said primary copy of said software process that enables said version manager to monitor the state of the synchronization between said primary copy and said backup copies, including said additional backup copy.

13. The method as set forth in claim 12, wherein said sixth step is achieved by said version manager killing said current primary copy and instructing said additional backup copy to become said new primary copy by means of a message-based interface between said version manager and said additional backup copy.

14. The method as set forth in claim 12, wherein said sixth step is achieved by said version manager instructing said current primary copy to become a backup copy of said software process and instructing said additional backup copy to become said new primary copy, said instructions being carried between version manager and the copies of said software process via a message-based interface.

15. The method as set forth in claim 13, wherein said seventh step is achieved by said version manager using a tenth step to select the next said running backup copy to upgrade and the processing unit on which to start a further copy of said replacement version of said software process, starting said further copy on said processing unit and allowing said further copy to synchronize said interal with said new primary copy then killing said running backup copy, except for the last running backup copy of said old version, which need only be stopped without starting said further copy in order to return the level of fault-tolerance coverage to that which existed before said upgrade began.

16. The method as set forth in claim 15, where in said tenth step is achieved by said version manager randomly selecting said running backup copy of said software process that said version manager will next upgrade to said replacement version and starting said further copy on the same processing unit as said running backup copy is running on.

17. The method as set forth in claim 15, wherein said tenth step is achieved by said version manager selecting said running backup copy of said software process that said version manager will next upgrade and the processing unit on which said further copy will be started using static or dynamic configuration information and knowledge of the current load on each processing unit to minimize the performance impact due to the processing load on the system for conversion of said internal state during said synchronization between said primary and said backup copies.

18. The method as set forth in claim 14, wherein said seventh step is achieved by said version manager using an eleventh step to select the next said running backup copy to upgrade and the processing unit on which to start a further copy of said replacement version of said software process, then stopping said running backup copy and starting said further copy and allowing said further copy to synchronize said internal state with said new primary copy before selecting the next said running backup copy to upgrade, except for the last running backup copy of said old version, which need only be stopped without starting said further copy in order to return the level of fault-tolerance coverage to that which existed before said upgrade began.

19. The method as set forth in claim 18, where in said eleventh step is achieved by said version manager randomly selecting said running backup copy of said software process that said version manager will next upgrade to said replacement version and starting said further copy in the same processing unit as said running backup copy is running on.

20. The method as set forth in claim 18, wherein said eleventh step is achieved by said version manager selecting said running backup copy that said version manager will next upgrade and the processing unit on which to start said further copy of said software process using static or dynamic configuration information and knowledge of the current load on each processing unit to minimize the performance impact due to the processing load on the system for conversion of said internal state during said synchronization between said primary and said backup copies.