Method and system for installing program in multiple system

It is an object of the present invention to allow easy upgrading of the version of the OS in a failover cluster system. When the user mounts a storage medium 4 on the node 1, and gives instructions to install a program, the installation program 12 requests the failover program 11 for the stopping of heartbeat communications. The node 1 voluntarily stops heartbeat communications in a state in which the system of this node is operating normally. When the failover program 21 of the node 2 detects the stopping of heartbeat communications, this program starts failover, and takes over the business service of the node 1. During the execution of failover by the node 2, the program stored in the storage medium 4 is installed in the node 1. When this installation is completed, the node 1 transmits a failback request to the node 2, and restarts the business service.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application relates to and claims priority from Japanese Patent Application No. 2003-382627 filed on Nov. 12, 2003, the entire disclosure of which is incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method and system for installing program in a multiple system.

2. Description of the Related Art

The term “cluster system” refers to a system in which a plurality of computers (also called nodes) are roughly joined to form a single system. For example, cluster systems include load dispersion type systems, failover type systems and the like. The term “failover cluster system” refers to a system which is endowed with redundancy by means of a plurality of computers. In a failover system, when one computer stops, business is taken over by other computers, so that the continuity of business application services is guaranteed to client computers. This first computer and other computers are connected via a communications line (interconnect) such as an LAN or the like, and the stopping of the companion computers is monitored by performing heartbeat communications between the computers.

The term “heartbeat communications” refers to a technique in which signals used to indicate that the functioning of a computer has not stopped are exchanged between a plurality of computers in a failover relationship, so that stopping of the functioning of the computers is mutually monitored. While heartbeat communications are being performed, it is judged by the monitoring computer that the companion computer in question is operating normally, and failover (takeover of business) is not performed. Conversely, when heartbeat communications are interrupted, it is judged that the system of the companion computer is down, and the business application that was provided by the companion computer is taken over by the monitoring computer. From the client computers utilizing the business application, the failover cluster as a whole is viewed as though this cluster were a single computer. Accordingly, even when processing is switched from a computer currently in use to a waiting computer, the client computers are not aware of the identity of the computer from which the business application service is being provided. Here, if failover is executed without any consideration being given to the operating state of the abovementioned monitoring computer, the computer that executes this failover is itself subjected to an excessive burden, so that there is a possibility of a drop in the response characteristics or the like. Japanese Patent Application Laid-Open No. 11-353292 discloses a technique in which the priority of the business application is altered in accordance with the operating state of the computer that takes over the abovementioned business.

As a result of conspicuous advances made in software techniques and the like, there is a need for suitable improvement in the software environment of computers that form the abovementioned cluster. For example, the OS (operating systems) of the computers are appropriately updated in order to improve security and improve file sharing services or the like. Furthermore, software such as application programs other than the OS, as well as device drivers, firmware and the like, are also appropriately altered in accordance with changes in the environment.

When such updating or upgrading of the version of the OS or the like is performed, the manager installs the new OS manually with the computer in a state of planned stoppage, and restarts the computer after the installation is completed.

SUMMARY OF THE INVENTION

When the version of the OS or the like of a computer that configures a part of a failover cluster system is upgraded (or downgraded), there may be cases in which restarting is necessary (depending on the program). Since the restarting of a computer involves stopping of the computer, the service providing a business application is temporarily interrupted. Since heartbeat communications are cut off when the computer is stopped, failover is executed by the other computers in the system. However, a specified time lag occurs between the interruption of heartbeat communications and the execution of failover.

Accordingly, in the case of version upgrading that involves restarting of the computer, the manager first (by means of a manual operation) causes failover to be executed by the failover destination computer. As a result, the service that provides the business application is taken over by the failover destination computer. Then, the computer that originated the failover stops the service providing the business application. The manager then installs new software in the computer that originated the failover.

Thus, when new software is installed in a computer, and especially when installation work that involves restarting of the computer is performed, the manager must actuate failover by a manual operation. Accordingly, the following problem arises: namely, if the manager is not familiar with the failover cluster system, the manager cannot install new software, so that the convenience of the system for use is poor. Specifically, while the new software can be automatically installed by an installer, preparations on the computer side require (for example) a manual operation by an experienced manager.

It is one object of the present invention to provide a failover cluster system and a program installation method using this failover cluster system which are devised so that program installation work can be simply performed. Furthermore, it is another object of the present invention to provide a failover cluster system and a program installation method using this failover cluster system which are devised so that program installation work can be automated by means of a relatively simple construction. Other objects of the present invention will be clear from the description of embodiments below.

A failover cluster system according to an embodiment of the present invention comprises a first computer and second computer that are mutual objects of failover, wherein the second computer transmits an installation permission signal to the first computer when a state of a stopped process in the first computer is detected, and the first computer installs a specified program when an installation permission signal is received from the second computer.

For example, by causing heartbeat communications to be performed between the first computer and second computer, it is possible to detect a state of a stopped process in the companion computer when the heartbeat communications are cut off for a specified time or longer. When the second computer detects a state of a stopped process in the first computer, the second computer executes failover. Furthermore, when the second computer detects a state of a stopped process in the first computer, the second computer transmits an installation permission signal to the first computer. This installation permission signal is a signal which indicates that a state of a stopped process in the first computer has been detected by the second computer, and is associated with the execution of failover by the second computer. Accordingly, if the first computer generates a state of a stopped process voluntarily and in a feigned manner prior to the installation of the specified program, the specified program can be installed after failover is actuated by the second computer. The term “voluntary and feigned state of a stopped process” refers to a state in which the first computer shows a state of a stopped process to the second computer in spite of the fact that the first computer is operating normally. In concrete terms, for example, a feigned state of a stopped process can be generated by voluntarily stopping the abovementioned dead-or-alive confirmation signals.

Then, when the installation of the specified program is completed, the first computer can request failback from the second computer. As a result, the first computer restarts the provision of service to the client computers. Furthermore, since the failover cluster system as a whole is seen as a single computer from the client computers, the client computers are not aware of which computer is actually providing the service.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Embodiments of the present invention will be described below with reference toFIGS. 1 through 10.

The failover cluster system of the present invention is a failover cluster system which comprises a first computer and second computer that are mutual objects of failover, and in which failover is executed on the basis of the state of heartbeat signal communications performed between the first computer and second computer. The first computer comprises a first failover program which causes failover to be actuated by the second computer by voluntarily stopping heartbeat signal communications on the basis of a heartbeat communications stop request that is issued from an installation program that performs preparations for the installation of an OS construction altering program (with this request being issued prior to the installation of this construction altering program), and an installation control program which starts an installer program and installs the construction altering program by restarting the OS when a restart signal based on the stopping of the heartbeat signals is received from the second computer. Furthermore, the first failover program requests the second computer for failback when the installation of the construction altering program is completed. Moreover, the second computer comprises a second failover program which executes failover when heartbeat signal communications with the first computer are stopped, and a restart request program which transmits a restart signal to the first computer when heartbeat signal communications with the first computer are stopped. Furthermore, the second failover program stops the execution of failover when failback is requested by the first computer.

For example, the first computer and second computer (nodes) provide a business application such as a file sharing service or the like to client computers. For instance, the first computer and second computer are connected via a communications network such as an LAN (local area network) or the like so that two-way communications are possible. For example, the first computer and second computer respectively comprise storage devices (memory storage resources) such as disk storage devices, semiconductor memory storage devices or the like. For example, the respective computers and storage devices are connected via a communications network such as an SAN (storage area network) or the like.

The first and second computers are mutual objects of failover. Specifically, when the first computer stops, the second computer takes over the business of the first computer. Conversely, when the second computer stops, the first computer takes over the business of the second computer. When the service is thus transferred between the first and second computers, the data that is to be taken over is stored (for example) on a shared disk. The first and second computers can execute failover as a result of sharing this shared disk. Furthermore, the system may also be constructed so that the service is taken over by synchronizing (mirroring) the content of the storage device of the first computer and the content of the storage device of the second computer.

Whether or not the companion computer has stopped is detected according to the heartbeat signal communications state. For example, when heartbeat communications are interrupted for a specified period of time or longer, it is judged that the companion computer has stopped, and failover is executed by the first failover program or second failover program.

When the version of the OS of the first computer is upgraded (updated), the installation program sends a heartbeat communications stop request to the first failover program prior to the installation work. The first failover program that receives this request voluntarily stops heartbeat communications. Here, the “voluntary stopping of heartbeat communications” differs from ordinary cases in which heartbeat communications are stopped as a result of the system going down; this term refers to a deliberate stopping of heartbeat communications under conditions in which the computer is operating normally. As a result, in the second computer, it is judged that the first computer has stopped functioning. Furthermore, this can also be applied to cases in which the version of the OS of the first computer is downgraded (cases in which the OS is returned to a previous construction).

When the first computer voluntarily stops heartbeat communications, the second failover program executes failover, so that the second computer takes over the service that was previously provided by the first computer. Furthermore, when the first computer voluntarily stops heartbeat communications, the restart request program of the second computer transmits a restart signal to the first computer. This restart signal is transmitted when the second computer detects the stopping of heartbeat communications. The stopping of heartbeat communications prompts the execution of failover by the second computer. Accordingly, the restart signal indicates the execution of failover or planned execution of failover by the second computer. When the installation control program of the first computer receives a restart signal from the second computer, this program starts the installer program and installs the construction altering program. Likewise, when restarting is required in upgrading of the version of the OS or the like, failover is executed by the second computer; accordingly, the service provided to the client computers is continued. Alternatively, the service is provided by the second computer after a relatively short period of time during which the service is stopped.

When the upgrading of the version of the OS of the first computer is completed, the first failover program requests the second computer for failback. After receiving this failback request, the second failover programs stops the failover. As a result, the service provided to the client computers is again provided from the first computer.

Here, for example, the OS construction altering program, installation program and installer program can be respectively stored in the same storage medium. Furthermore, for example, the installation program read out from the storage medium can be copied into the memory of the first computer and executed by the first computer.

A first embodiment of the present invention will be described with reference toFIGS. 1 through 8.FIG. 1is a functional block diagram which shows an overall outline of the failover cluster system of the present invention. As will be described later, the failover cluster system is divided into the following main parts: namely, a plurality of nodes1and2, and a shared disk3which is shared by the respective nodes1and2.

The node1that constitutes the “first computer” is constructed as a computer system comprising (for example) a CPU (central processing unit) and various memories, input-output circuits, communications interfaces and the like. In concrete terms, this node1is constructed as a server machine. The node1is connected to a plurality of client computers (not shown in the figures) via communications networks CN1and CN2used for service provision. The node1is connected to the node2via a communications network CN3. For example, the communications networks CN1through CN3are respectively constructed as communications networks such as LAN or the like. CN1and CN2may also be called external LAN, and CN3may also be called an internal LAN. Furthermore, the node1is connected to the common disk3via a communications network CN4. For example, the communications network CN4is constructed from a communications network such as an SAN or the like.

The node1comprises a failover program11, an installation program12, a BIOS13, a communications memory14, and OS15, an IOP (input output processor)16and a business application program (abbreviated to “business application”)17. Furthermore, the node1comprises a medium interface (not shown in the figures) that is used to read out computer programs (hereafter abbreviated to “programs”) and the like from the storage medium4. As will be described later, the node1upgrades the version of the OS15by means of a program stored in the storage medium4. Furthermore, various types of disk type storage media such as a hard disk, CD-ROM, CD-R, DVD-ROM, DVD-RAM, optical-magnetic disk or the like, or storage media such as a semiconductor memory or the like, can be used as the storage medium4. Furthermore, the storage medium used is not limited to a shaped storage medium; the version of the OS15of the node1can also be upgraded using a communications medium.

The node1and node2perform heartbeat communications via the communications network CN3. Heartbeat communications constitute a method of monitoring the dead-or-alive status of the server; such communications may be performed by a number of different methods. The first method is a method in which heartbeat signals are periodically transmitted in one direction from the node1to the node2. The second method is a method in which the node1sends back a response to inquiry signals from the node2. In either case, when heartbeat signals from the node1are interrupted for a specified period of time or longer, the node2judges that a stopping of function (e.g., shutting down of the server due to a power supply abnormality, memory problem, OS panic or the like) has occurred in the node1, and the node2therefore executes failover. As a result, the business application service that was previously provided by the node1is taken over by the node2. It is possible to execute failover immediately when heartbeat communications are cut off; in ordinary cases, however, the temporary transmission delay of the heartbeat signals caused by the heavy burden on the node1and the like are taken into consideration, and a delay is built into the time that elapses until a judgment that trouble has occurred is made. In the present embodiment, the second heartbeat communications method, i.e., a method in which the node1sends back a response when called by the node2, is shown as an example. Furthermore, dead-or-alive monitoring by means of heartbeat communications can also be accomplished using a simple signal such as a “ping”. In addition, for example, heartbeat communications can also be performed while exchanging computer status information (resource consumption state of the CPU, memory or the like, number of file access requests and the like) between the two nodes1and2.

Like the node1, the node2that constitutes the “second computer” is constructed as a computer system. The node2is connected to a plurality of client computers via the communications networks CN1and CN2. The node2is connected to the node1via the communications network CN3, and is connected to the shared disk3via a communications networks CN5. Like the node1, the node2comprises a failover program21, an installation program22, a BIS23, a communications memory24, an OS25, and IOP26, a business application27, an input-output circuit (not shown in the figures) and the like. As seen from the business application service (hereafter abbreviated to “business service”) provided by the node1, the node2constitutes backup (i.e., a waiting server) for the node1. Conversely, as seen from the business service provided by the node2, the node1constitutes backup for the node2. Specifically, the respective nodes1and2can separately provide the business service, and are mutual objects of failover.

The shared disk3is a logical storage region (logical unit) that is set in a physical storage region. The shared disk3is shared by the respective nodes1and2. Node1service information D1and node2service information D2are stored on the shared disk3. These types of service information D1and D2are used to execute failover. Specifically, information that is required for the taking over of the business service of the node1by the node2is contained in the node1service information D1, and information that is required for the taking over of the business service of the node2by the node1is contained in the node2service information D2. In more concrete terms, when the node2takes over the business service of the node1, the file system that has the node1service information D1is unmounted from the node1and mounted in the node2. Various types of business services such as customer management, product management, financial management, video distribution and the like may be cited as examples of business services.

Next, the functional construction of the node1will be described with reference toFIG. 2. Furthermore, inFIGS. 2 and 3, the business applications17and27are omitted for convenience of description.

The failover program11that corresponds to the “failover control part” comprises a heartbeat transmitting and receiving function111, a heartbeat transmission stop receiving function112, a failover function113, a failback function114, and a service stop function115. The heartbeat transmitting and receiving function111is a program module which is used to perform heartbeat communications with the node2via the communications network CN3from an LAN interface (not shown in the figures) in the node1. The heartbeat transmission stop receiving function is a program module which is used to receive heartbeat transmission stop requests that are issued by the installation program12, and to stop the heartbeat communications intentionally and voluntarily.

The failover function113is a program module which is started when the heartbeat communications are interrupted for a specified period of time or longer, and which is used to take over and perform the business service provided by the node2that constitutes the failover source. The failover function113takes over the data (file system) D2, IP addresses and the like used in the provision of the business service, and provides this business service to the client computers. The failback function114is a program module which is used to return the business service of the node1that has been taken over and performed by the node2to the node1. The failback function114is started when the upgrading of the version of the OS15is completed; this function requests the stopping of failover with respect to the failover function213of the node2. As a result, the file system (node1service information D1) that was being used by the node2is unmounted from the node2and again mounted in the node1. The service stop function115is a program module which is used to stop the business service provided by the node1.

The installation program12that corresponds to the “installation preparation program” or “installation preparation part” comprises a starting method write function121and a heartbeat transmission stop request function122. The starting method write function121is a program module which is used to write the starting method of the node1into the communications memory14. The starting method write function121writes a starting method indicator flag into the communications memory14. The heartbeat transmission stop request function122is a program module which is used to request the stopping of heartbeat transmission from the failover program11. Here, the installation program12can be stored beforehand in a storage device (local disk, ROM or the like) in the node1. Alternatively, the installation program12can be stored in the storage medium4, and used after being copied into the node1from the storage medium4.

The BIOS (basic input/output system)13comprises a starting destination altering function131. The starting destination altering function is a program module which is used to alter the starting destination of the OS15on the basis of the starting method indicator flag that is written into the communications memory14. Together with the IOP16, the BIOS13constitutes the “installation control part”. Furthermore, the “installation control part” may also be viewed as being constructed by the BIOS13, communications memory14and IOP16.

The communications memory14is a memory that is used form communications between the IOP16and OS15. For example, this communications memory14is constructed as a nonvolatile memory such as a flash memory, FeRAM (ferroelectric random access memory), MRAM (magnetoresistive random access memory), phase-change memory (ovonic unified memory) or the like. In the present embodiment, the starting method indictor flag141and a diagnosis indicator flag142are written into the communications memory14. The starting method indicator flag141constitutes information that is set by the starting method write function121of the installation program12prior to the upgrading of the version of the OS15. It is indicated in the starting method indicator flag141whether the OS is started from the storage medium4or started from the ordinary system disk. The diagnosis indicator flag142constitutes information that is set by a diagnostic program43stored in the storage medium4. In the diagnosis indicator flag, it is indicated whether or not the diagnostic program43is to be executed following version upgrading.

The OS15comprises a diagnostic program execution function151and a stop receiving function152as constructions relating to the present embodiment. The diagnostic program execution function is used to execute the diagnostic program43that is stored in the storage medium4. The stop receiving function152is used to stop the operation of the OS15on the basis of requests from the IOP16.

The IOP16is a program that is used to control input and output. The IOP16has an other-node restart request function161and a restart receiving function162. The other-node restart request function is a program module which is used to request restarting from the companion node that is the object of failover (i.e., the node2as seen from the node1). The restart receiving function162is a program module which is used to restart the OS15in response to a restart request from the companion node.

Here, the relationship of the various constructions shown inFIG. 2will be briefly described. The communications memory14is hardware. The other parts, i.e., the failover program11, installation program12, BIOS13, OS15and IOP16are respectively items of software. Furthermore, the failover program11and installation program12are constructed as application programs that are executed by the OS15(the business application17is also constructed as an application program). Furthermore, the BIOS13and IOP16are constructed as items of firmware that are executed at a level lower than the OS15. Accordingly, the BIOS13and IOP16can be executed even when the OS15is stopped.

The functional construction of the node2is shown inFIG. 3. The node2has a construction similar to that of the node1described with reference toFIG. 2. Specifically, the failover program21comprises a heartbeat transmitting and receiving function211, a heartbeat transmission stop receiving function212, a failover function213, a failback function214and a service stop function215. The installation program22comprises a starting method write function221and a heartbeat transmission stop request function222. The BIOS23comprises a starting destination altering function321. A starting method indicator flag241and a diagnosis indicator flag242are respectively stored in the communications memory24. The OS25comprises a diagnostic program execution function251and a stop receiving function252. The IOP26comprises an other-node restart request function261and a restart receiving function262. The contents of these respective functions are the same as those described for the node1.

The functions executed by the node1when the version of the OS15of the node1is upgraded and the functions executed by the node2when the version of the OS25of the node2is upgraded are the same. By the same token, the functions executed by the node2when the version of the OS15of the node1is upgraded and the functions executed by the node1when the OS25of the node2is upgraded are the same. Specifically, both the functions that are executed when the version of a given node's own OS is upgraded and the functions that are executed when the OS of the companion node is upgraded are contained in the constructions of the nodes1and2shown inFIGS. 2 and 3. Accordingly, when the version of the OS15of the node1is upgraded, only the relevant functions among the respective functions contained in the node1are executed.

FIG. 4is an explanatory diagram which shows the memory content of the storage medium4in model form. An OS installer program (hereafter abbreviated to “installer”)41, an OS file42and a diagnostic program43are respectively stored in the storage medium4.

The installer41corresponding to the “installation execution part” or “installation execution program” is a program that installs the OS file42in the node1. The OS file42corresponding to the “specified program” or “OS construction altering program” is a program that is used to improve the function of the OS15or the like. The diagnostic program43is a program which is used to perform specified tests following the upgrading of the version of the OS15. Furthermore, the installation program12may also be stored in the storage medium4. Moreover, in ordinary cases, the OS file42is a program that updates the construction of the OS to a new construction. However, the OS file42is not limited to this; this OS file may also be a program that restores the OS construction to an old construction.

The operation of the present embodiment will be described with reference toFIGS. 5 through 8. First,FIG. 5is a flow chart which shows an overall outline of the method used to upgrade the version of the OS utilizing the above-mentioned failover cluster system. Furthermore, the communications performed between the respective nodes1and2as described below are performed via the communications network CN3.

First, the manager mounts the storage medium4in the node1, and gives instructions for the installation of a new OS file42in the node1via the user interface (not shown in the figures) of the node1(S1). When installation instructions are thus provided by the manager, the starting method write function121of the installation program12sets the content of “starting from the storage medium4” in the starting method indicator flag141of the communications memory14(S2). Next, the heartbeat transmission stop request function122of the installation program12requests the failover program11for the stopping of heartbeat communications. In response to this request from the installation program12, the heartbeat transmission stop receiving function112of the failover program11voluntarily stops the heartbeat communications with the node2(S3).

The failover program21of the node2constantly monitors the heartbeat communications with the node1. When the heartbeat communications are interrupted for a specified period of time or longer, the failover program21of the node2judges that the functioning of the node1has stopped (S4). The IOP26of the node2requests the node1for restart (S5). When the IOP16of the node1receives a restart request from the node2, this IOP16stops the OS15(S6). When the OS15is stopped, the provision of the service of the business application17is also stopped. When the OS15of the node1stops, the stopping of the OS is reported to the IOP26of the node2by the IOP16of the node1(S7). When the stopping of the OS of the node1is confirmed by the IOP26of the node2, the failover program21of the node2executes failover on the basis of the node1service information D1(S8). The node2takes over various resources (file system, IP addresses and the like) form the node1, so that the business service that was provided by the node1is provided from the node2. These steps S1through S8constitute a failover execution step. Viewed in greater detail, the failover execution step is constructed from installation preparation steps (S1, S2), heartbeat stopping steps (S3, S4) and failover steps (S5through S8).

Next, the OS file42is installed in the node1. The BIOS13of the node1refers to the starting method indicator flag141in the communications memory14, and performs starting from the storage medium4. As a result, the installer41stored in the storage medium4is started. The installer41installs the OS file42in the node1(S9). When the OS file42is installed so that the upgrading of the version of the OS15is completed, the BIOS13starts the OS15(S10).

As a result of the restarting of the OS15, heartbeat communications by the failover program11are restarted (S11). Furthermore, the OS15refers to the diagnosis indicator flag142in the communications memory14, and checks in order to ascertain where are not there are instructions for the execution of the diagnostic program. When there are instructions for the execution of the diagnostic program43, the OS15reads out the diagnostic program43from the storage medium4, and executes the diagnostic program43(S12). This diagnostic program43is a program which is used to perform a diagnosis as to whether or not the OS15is operating normally following the installation of the OS file42. Furthermore, the restarting of the heartbeat communications (S11) and the execution of the diagnostic program (S12) are interchangeable in terms of the order in which these steps are performed. These steps S9through S12constitute a program installation step. Viewed in greater detail, this program installation step is constructed from installation execution steps (S9, S10), a heartbeat communications restarting step (S11) and a diagnostic program execution step (S12).

Next, the failback function114of the failover program11requests the failover program21of the node2for failback (S13). In response to such a failback request from the node1, the failover program21of the node2stops the above-mentioned failover (S14). When the failover program21of the node2stops this failover, the failover program21reports the stopping of failover (i.e., reports the stopping of the provision of the business service) to the node1(S15). After confirming the stopping of the business service in the node2, the failover program11of the node1restarts the business service performed by the business application17(S16). These steps S13through S16constitute a failback step.

Next, the details of the operations performed in the respective steps will be described with reference toFIGS. 6 through 8. First,FIG. 6shows the concrete processing of the failover execution steps.

Heartbeat communications are performed between the failover program11of the node1and the failover program21of the node2. Choosing an appropriate time, the user (manager) gives instructions for the installation of the OS file42to the node1(S21). The installation program12is started by these instructions from the user (S22). The starting method write function121of the installation program12sets the content of “starting from the storage medium4” in the starting method indicator flag141of the communications memory14(S23). Next, the heartbeat transmission stop request function122of the installation program12issues a heartbeat transmission stop request to the failover program11(S24).

Then, when the heartbeat transmission stop receiving function112of the failover program11receives a heartbeat transmission stop request from the installation program12, the heartbeat transmitting and receiving function111of the failover program11stops the heartbeat communications (S25).

When a specified time elapses following the interruption of the heartbeat communications, the failover program21of the node2detects the stopping of the heartbeat communications (S26). The failover function213of the failover program21instructs the IOP26to request restarting of the node1(527). The other-node restart request function261of the IOP26requests the IOP16of the node1for restart of the node1(S28). This restart request signal is a signal that permits the upgrading of the version of the OS15as described below, and corresponds to the above-mentioned “installation permission signal”.

When the IOP16(restart receiving function162) of the node1receives a restart request from the IOP26of the node2(S29), the IOP16requests the OS15to stop operation (530). After receiving this stop request from the IOP16, the OS15initiates a stop sequence (S31), and reports the stopping of the OS15to the IOP16(S32). When the IOP16receives a stop report from the OS15, the IOP16notifies the IOP26of the node2that the OS15has stopped (S33). Furthermore, in the present embodiment, the stopping of the OS15and the stopping of the business service are performed at substantially the same time. However, the present invention is not limited to this; it would also be possible to stop the business service first, and then to stop the OS15. The reason for this is that the stopping of the business service by the node1allow failover to be executed in the node2.

When the IOP26of the node2receives an OS stop report from the node1(S34), the IOP26requests the failover program21for the execution of failover (S35). The failover function213of the failover program21executes failover in response to the request from the IOP26(S36). The failover function213of the node2refers to the node1service information D1stored on the shared disk3, and takes over the business service that was being performed by the node1(S37).

Next,FIG. 7is a flow chart which shows the program installation step. After reporting the stopping of the OS to the node2(S33), the IOP16of the node1instructs the BIOS13to start (S38).

The BIOS13starts in response to the start request from the IOP16(S39), and refers to the starting method indicator flag141in the communications memory14(S40). In the abovementioned S23, an indication of “starting from the storage medium4” is noted by the installation program12in the starting method indicator lag141. Accordingly, the BIOS13accesses the storage medium4, and starts the installer41(S41).

The installer41initiates the installation of the OS file42stored in the storage medium4(S42). When the installation of the OS file42is completed (S43), the installer41sets an indication of “starting from the system disk” in the starting method indicator flag141of the communications memory14(S44). Furthermore, the installer41sets an indication of “diagnostic program43to be executed” in the diagnosis indicator flag142of the communications memory14(S45). After setting the starting method indicator flag141and diagnosis indicator flag142, the installer41requests the BIOS13for restart (S46).

When restarting is requested by the installer41, the BIOS13starts (S47), and refers to the starting method indicator flag141of the communications memory14(S48). Since an indication of “starting from the system disk” was set in the starting method indicator flag141in the abovementioned S44, the BIOS13starts the OS15from the system disk (S49).

As a result, the OS15whose version was upgraded by the installation of the OS file is started (S50). The OS15refers to the diagnosis indicator flag142of the communications memory14, and resets the diagnosis indicator flag142after confirming that execution of the diagnostic program43is instructed (S51). After completion of the start (S52), the OS51executes the diagnostic program43stored in the storage medium4with the diagnostic program execution function151(S53). As a result of the execution of the diagnostic program43, the diagnostic processing is completed if there are no abnormalities (S54). When an abnormality is discovered in the OS15, the manager is notified. The manager who receives an error notification performs the re-installation of the OS file42, the installation of a separate patch program or the like. Furthermore, when the OS15is restarted, the node1restarts heartbeat communications with the node2. Furthermore, the business service of the node1is still carried on by the node2even after the OS15is restarted (S37).

FIG. 8is a flow chart which shows the concrete processing of the failback step. When the diagnostic processing performed by the diagnostic program43is completed (S54), the OS15instructs the failover program11to perform failback (S55). The failback function114of the failover program11requests the failover program21of the node2for failback (S56).

The failover program21of the node2ends failover by means of the service stop function115, and stops the business service that had been carried on by the node2(S57). Then, the service stop function115of the failover program21reports the stopping of failover to the node1(S58).

When the failover program11of the node1receives a service stop report from the node2, this program refers to the node2service information D2on the shared disk3, and restarts the business service (S59).

When a shared upgrading of the version is performed in the node1and node2, the version of the OS25of the node2is upgraded using the same method as that described in the case of the node1.

The present embodiment is constructed as was described in detail above, and possesses the following merits. First, when the node2detects a state of a stopped process (stopping of heartbeat communications) in the node1, and an installation permission signal (restart signal) is transmitted from the node2to the node1, the node1starts the installer41and initiates the installation of the OS file42. Accordingly, the initiation of installation work in the node1can be triggered by instructions from the node2, so that a specified program (OS file42) can be installed by causing cooperation between the node1and node2.

Furthermore, since the installation permission signal is associated with initiation of the execution of failover by the node2, and failover by the node2is executed (S36) after the node1is instructed to restart by the node2(S27), cooperation between the execution of failover by the node2and the installation work performed by the node1can be achieved, so that installation work in the node1can be accomplished without any unnecessary interruption of the business service.

Furthermore, the user need merely give initial instructions for the installation of the OS file42; there is no need to execute failover by a manual operation. Specifically, even in the case of a user that is unaccustomed to a failover cluster system, the version of the OS15can be upgraded in a simple manner while maintaining the continuity of the business service, so that the convenience of the system is improved.

Furthermore, since heartbeat communications are voluntarily stopped prior the installation work in a state in which the system is operating normally, the node2can be prompted to perform failover using an existing construction without any use of special commands, signals or the like, and installation work in the node1can be performed while failover is being executed by the node2.

Furthermore, since the work of installing the OS file42is divided between an installation program12that performs installation preparations and an installer41that performs the actual installation work, the node2can be prompted to execute failover by stopping the heartbeat communications by means of the installation program12, and the installer41can be caused to install the OS file42while failover is being executed by the node2.

Furthermore, the installation program12that performs installation preparations requests the stopping of heartbeat communications, and sets “starting from the storage medium4” in the starting method indicator flag141of the nonvolatile communications memory14. Furthermore, the installer41alters the starting method indicator flag141to “starting from the system disk” after installation is completed. Accordingly, installation work following the execution of failover can be performed by the installation program12and installer41with hardly any alteration of the existing construction of the node1. Consequently, the additional cost required in order to realize the present embodiment can be reduced.

Next, a first modification of the first embodiment will be described with reference toFIG. 9. In this modification, heartbeat communications are voluntarily stopped at the point in time at which there is a cut-off point in the business service that is being provided by the node1.

The flow chart shown inFIG. 9shows the details of S25inFIG. 6. When the heartbeat transmission stop receiving function112of the failover program11receives a heartbeat transmission stop request from the installation program (S61: YES), the failover program11judges whether or not the business service is currently being provided (S62). When the business service is not being provided (S62: NO), heartbeat communications are immediately stopped. When the business service is being provided (S62: YES), the acceptance of new service requests in the service waiting queue is stopped (S64), and the processing returns to S62. When all of the service requests in the waiting queue have been processed, a judgment of “YES” is made in S62, and heartbeat communications are stopped (S63).

FIG. 10is a flow chart which shows an outline of the overall operation of the failover cluster system in a second modification of the first embodiment. In this modification, the node1and node2are caused to cooperate loosely, and installation work in the node1is performed without confirming the execution of failover in the node2.

When the user gives instructions for installation in the node1(S71), the installation program12sets “starting from the storage medium4” in the starting method indicator flag141of the communications memory14(S72). When the installation program12transmits a heartbeat transmission stop request to the failover program11, the failover program11voluntarily stops heartbeat communications in spite of the fact that the OS15is operating normally (S73).

When the node2detects the stopping of heartbeat communications (S74), the node2initiates failover (S76). Meanwhile, in the node1, the business service is stopped after heartbeat communications have been stopped (S75). Here, the important point is that the timing of the two operations in the respective nodes1and2is adjusted so that failover is initiated by the node2after the business service has been stopped in the node1(S75). In concrete terms, the time at which the business service is stopped in the node1is set with consideration given to the time t1extending from the point in time at which heartbeat communications are stopped to the point in time at which the stopping of the heartbeat communications is detected by the node2, the time t2extending from the abovementioned point in time to the point in time at which failover is executed in the node2, and some surplus time (communications lag time and the like). As a result, upgrading of the version of the OS15can be performed following the execution of failover by the node2without obtaining a response signal from the node2, i.e., without obtaining a response signal (restart signal in the first embodiment) signifying that the stopping of heartbeat communications has been recognized by the node2and the failover execution sequence has been initiated.

Specifically, in the node1, the OS15is stopped at the time at which it is thought that failover has been executed by the node2(S77), and the OS file42is installed (S78). Subsequently, in the same manner as that described inFIG. 5, the node1restarts the OS15(S79), heartbeat communications are restarted (S80), and the diagnostic program43is executed (S81). Furthermore, then node1requests the node2for failback (S82). The node2then ends failover and reports the stopping of service (S83, S84), and the node1restarts the business service (S85).

Furthermore, the present invention is not limited to the respective embodiments described above. Various additions, alterations and the like may be made within the scope of the present invention by a person skilled in the art. For example, the in abovementioned embodiments, a case in which a cluster was formed from two nodes, i.e., a node1and a node2, was described. However, the present invention can also be applied to a cluster formed from three or more nodes. In this case, the priority order of failover destination nodes that perform failover for a given node may be set in advance. The node with the highest priority plays the role of the node2.

Furthermore, upgrading (updating) of the version of the OS was described as an example. However, the present invention is not limited to this, and may also be used when the version of the OS is downgraded. In addition, the present invention can also be used in the installation of various other types of programs that involve restarting of the nodes.

Moreover, the above description was centered on failover; however, the present invention can also be used when dispersion of the load is performed within the cluster. Specifically, the installation of programs in a state in which failover is started can also be performed by the present invention in cases were each of the nodes1and2provides its own characteristic business service.