JP2008052407A - Cluster system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To solve the problem that since one service failure affects the other services and a cluster manager in a conventional manner, it is necessary to cope with for the OS of an application and a cluster manager, and versatility is poor, and there is any failure which can not be detected by a failure processing mechanism which detects S/W failure from the type of interruption. <P>SOLUTION: This cluster system is provided with: a plurality of computers; virtual machines respectively installed in those computers; a host OS; a cluster manager; 0 or more guest OS; and a shared disk having an OS image which is accessible from each computer. The cluster manager is provided with: functions of the start/stop of each guest OS; the monitor of the status of a service; the failure restoration of a defective service; a heart beat function; and the fail over function of failure restoration using the OS image of the shared disk based on the failure detection of the other cluster manager. Also, each guest OS exclusively installed for a specific service is defined as one service for management. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a cluster system configured by using a plurality of computers having virtual machines, and relates to a technique for improving the reliability of the cluster system.

FIG. 8 shows a conventional cluster system. An operating system 15A operates on the computer 10A, and a cluster manager 20A operates on the computer 10A. An operating system 15B operates on the computer 10B, and the cluster manager 20B operates to constitute a two-node cluster system. Cluster managers connect to each other using heartbeat 90.
In the operating system 15A, applications 30A to 30C operate, and 30A and 30B provide a service 31A, and 30C provides a service 31B. Computers 10A-10B and clients 40A-40B are connected by LAN 91, and clients 40A-40B access services 31A-31B.

Next, the operation will be described.
When the cluster manager 20A monitors the services 31A to 31B and the cluster manager 20B and detects a failure in the service 31A, it stops the applications 30A and 30B, requests the cluster manager 20B to start the applications 30A to 30B, and calculates the service 31A Restore with 10B.
In addition, when the failure of the service 31A occupies the CPU or the like, which impedes the operation of the OS, the operation of the service 31B and the cluster manager 20A also becomes unstable due to the influence. In this case, the cluster manager 20B detects a failure of the cluster manager 20B, stops the computer 10A, and restores the services 31A and 31B with the computer 10B.
It works in this way to improve system reliability.

  FIG. 9 is a configuration diagram relating to a cluster system using a conventional logical computer described in Japanese Patent Laid-Open No. 2003-330740. There are computer resource division mechanisms 2A and 2B on the physical computers 1A and 1B, and logical computers 3A to 3D operate. The computer resource partitioning mechanisms 2A and 2B have the functions of cluster managers 20A and 20B. Using logical computers 3A to 3D, for example, logical computers 3A and 3C as shown in FIG. 9 are paired, and logical computers 3B and 3D are paired. Configure a hot standby cluster system. FIG. 10 shows the configuration of a cluster manager for realizing the conventional method. The cluster manager has a logical computer allocation mechanism, a failure processing mechanism, a physical computer configuration information table, a logical computer configuration information table, and a cluster table.

Next, the operation will be described. The failure processing mechanism detects an interrupt caused by the occurrence of a failure. If a software failure is detected depending on the type of interrupt, the logical computer that caused the interrupt is restarted. When a hardware failure is detected, the logical computer assigned to the failed processor is assigned to another processor and restarted. Further, when the entire physical computer 1A is stopped due to a failure, the logical computers 3C and 3D of the physical computer 1B take over and recover the work of the logical computers 3A and 3B.
As described above, there is shown a mechanism for appropriately restarting a logical computer and improving the reliability of the entire system in response to a hardware failure on a physical computer or a software failure on a logical computer.

JP 2003-330740 A

In the conventional cluster system, the following problems occur.
(1). In the prior art, the application that provides each service and the cluster manager operate on the same OS, so the failure of one service affects the other services and the cluster manager. This can be avoided by allocating a service for each computer. However, in this case, there is a problem that the system becomes complicated, and management costs and introduction costs increase.
(2). In the prior art, since the application providing each service and the cluster manager operate on the same OS, it is necessary to support the OS used by the application and the cluster manager. This reduces the options for applications, cluster managers, and OSs, and increases system construction costs.
(3). In the one described in Japanese Patent Application Laid-Open No. 2003-330740, since the cluster manager is mounted in the computer resource dividing mechanism, the cluster manager and the computer resource dividing mechanism are closely related, and versatility is impaired. As a result, function expansion and maintenance costs increase.
(Four). In the one described in Japanese Patent Laid-Open No. 2003-3307740, since the fault processing mechanism detects a software fault of the logical computer from the type of interrupt, the application operates normally at the interrupt level, but the fault such as not being able to provide the service is detected. It cannot be detected.

The cluster system according to the present invention is:
A plurality of computers, a virtual machine installed in each of the plurality of computers, one host OS, a cluster manager that operates only on the host OS,
A guest OS that operates an application for a service provided externally to at least one of a plurality of computers;
It has an OS image of the guest OS and a shared disk that can be accessed from each computer
The cluster manager uses the virtual machine functions to control the start and stop of each guest OS, monitor the service status, and when a service failure is detected, it restores the service from the failure according to a preset failover policy. Failover function that recovers all services managed by the cluster manager from the failure using the OS image of the shared disk when a failure of other cluster managers is detected. Have
Each guest OS is dedicated to a specific service and is associated with a failover policy instructing a recovery method of each service. The guest OS itself is regarded as one service and is managed by the cluster manager.

According to the cluster system of the present invention, even if a software or hardware failure occurs as a result of the cluster manager monitoring the service or another cluster manager, the service can be detected and recovered. In addition, by allocating a service for each OS, it is possible to prevent a service failure from affecting other services. Thereby, the reliability of the system can be improved.
Furthermore, an unnecessary increase in computers can be prevented by setting the OS as a guest OS on a virtual machine.

Embodiment 1 FIG.
FIG. 1 shows a two-node shared disk type hot standby cluster system including computers 10A to 10B and a shared disk 81.
In the computer 10A, a virtual machine 90A operates, and a guest OS 12A, a guest OS 12B, and a host OS 11A operate. It also has a storage (not shown) and has OS images (not shown) of the guest OS 12A and guest OS 12B. In the guest OS 12A, the applications 30A to 30B operate and provide the service 31A. In the guest OS 12B, the application 30C runs and provides the service 31B. In the host OS 11A, the cluster manager 20A operates and can access the virtual machine 90A using the virtual machine control I / F 91A. Further, the cluster manager 20A has a failover policy 60A in which a recovery method for the services 31A to 31B is described.

  In the computer 10B, the virtual machine 90B operates and the host OS 11B operates. It also has a storage (not shown) and has OS images (not shown) of the guest OS 12A and guest OS 12B. In the host OS 11B, the cluster manager 20B operates and can access the virtual machine 90B using the virtual machine control I / F 91B. Further, the cluster manager 20B has a failover policy 60B in which a recovery method for the services 31A to 31B is described.

The shared disk 81 is connected to the computers 10A to 10B and has OS images 13A to 13B of the guest OS.
The computers 10A to 10B are connected by a heartbeat 90, and the cluster managers 20A to 20B are connected to each other using the heartbeat 90. The computers 10A to 10B and the clients 40A to 40B are connected by a LAN 91, and the clients 40A to 40B are connected to the services 31A to 31B and the host OSs 11A to 11B.

Next, the operation will be described.
The cluster manager 20A uses the LAN 91 to access the services 31A to 31B at regular intervals and monitors whether there is a failure.
When the cluster manager 20A detects a failure of the service 31A, the cluster manager 20A uses the virtual machine control I / F 91A to stop the guest OS 12A on which the service 31A operates. When the guest OS 12A is stopped, the cluster manager 20A starts the guest OS 12A on the computer 10A or 10B according to the failover policy 60A.

When the guest OS 12A is started on the computer 10A by the failover policy 60A, the cluster manager 20A uses the virtual machine control I / F 91A to start the guest OS 12A from the OS image 13A of the shared disk 81, and the service 31A is restored. Resume service to clients 40A-40B.
When the guest OS 12A is activated on the computer 10B by the failover policy 60A, the cluster manager 20A requests the cluster manager 20B to activate the guest OS 12A on the computer 10B.
When the cluster manager 20B receives a guest OS 12A activation request from the cluster manager 20A, the guest OS 12A is activated from the OS image in the storage of the computer 10B using the virtual machine control I / F 91B, and the service 31A is restored.
The cluster managers 20A to 20B use the heartbeat 90 to access each other at regular intervals and monitor the presence or absence of a failure.

  When the cluster manager 20B detects a failure of the cluster manager 20A, the cluster manager 20B stops the computer 10B. After stopping the computer 10B, the cluster manager 20B uses the virtual machine control I / F 91B to start the guest OSs 12A to 12B from the OS images 13A to 13B on the shared disk 81, and the service 31A managed by the cluster manager 20A ~ 31B is restored by the computer 10A, and the services to the clients 40A to 40B are resumed.

As described above, even if a software or hardware failure occurs by monitoring the service or the cluster manager, it can be detected and the service can be recovered. In addition, by allocating a service for each OS, it is possible to prevent a service failure from affecting other services. Thereby, the reliability of the system can be improved.
Furthermore, an unnecessary increase in computers is prevented by making the OS a guest OS on a virtual machine.

Embodiment 2. FIG.
In the first embodiment, the cluster is configured using the shared disk 81, but the second embodiment is a data replication type cluster using a local disk.
FIG. 2 shows the configuration of the second embodiment. The computers 10A to 10B have local disks 80A to 80B and have OS images 13A to 13B of the guest OS 12A and the guest OS 12B, respectively. The host OS 11A to host OS 11B have replicators 70A to 70B. The replicators 70A to 70B are connected by a LAN 91.

Next, the operation will be described.
The replicators 70A to 70B can synchronize files on the local disks 80A to 80B through the LAN 91. The cluster managers 20A to 20B manage the replicators 70A to 70B, and synchronize the OS images 13A to 13B at regular intervals between the local disks 80A to 80B.
When the cluster manager 20B receives a guest OS 12A start request from the cluster manager 10A due to failure detection of the service 31A, the cluster manager 20A uses the virtual machine control I / F 91A to start the guest OS 12A from the OS image 13A on the local disk 80B. I do.
As described above, the effects of the first embodiment can be obtained without using a shared disk. In addition, cost can be reduced without using an expensive shared disk.

Embodiment 3 FIG.
In the second embodiment, the guest OS is handled as one OS image. In the third embodiment, as shown in FIG. 3, the image constituting the guest OS 12A is divided into a system image and a data image. A system image is a partition in which an operating system and applications are stored. A data image is a partition where an application stores data.
When the guest OS is started, the guest OS is configured by combining both the system image and the data image. When the service is running, the application stores important data in the partition provided by the data image and does not write to the system image. Further, as shown in FIG. 4, the replicator synchronizes only the data image.

  As described above, the OS image is separated into the system image and the data image, and only the data image is synchronized with the replicator, thereby reducing the amount of data to be synchronized. As a result, the load on the system can be reduced, the synchronization interval can be shortened, the service reliability can be improved, and the service level can be improved.

Embodiment 4 FIG.
In the first to third embodiments, when the cluster managers 20A to 20B start the guest OSs 12A to 12B, the guest OS is started from the OS image on the shared disk or the local disk. In the fourth embodiment, the guest OS is not an OS image. A case of starting from a snapshot image of will be described.
When registering the service 31A in the cluster system, first the OS image 13A of the guest OS 12A is prepared and stored in the disk, and then a snapshot image is created from the OS image 13A.
FIG. 5 illustrates a method for creating a snapshot image. First, the host OS starts the guest OS 21A using the virtual machine control I / F (S81). Access to the service 31A is performed at regular intervals (S82). It is determined whether or not a correct response can be returned from the service 31A (S83), and when the correct response is returned, it is detected that the applications 30A to 30B are activated and the provision of the service 31A is started. The virtual machine control I / F 91A is requested to create a snapshot image that is a snapshot immediately after the application is started (S84), and the created snapshot image of the guest OS 12A is stored in the disk (S85).

  When the cluster manager 20A requests the cluster manager 20B to start the guest OS 12A because, for example, the failure of the service 31A is detected, the cluster manager 20B starts the guest OS 12A from the snapshot image through the virtual machine control I / F 91B.

  As described above, booting the guest OS from the snapshot image after the start of service provision makes it possible to skip the OS and application startup process rather than booting from the OS image as shown in FIG. Speed is improved, service reliability can be improved, and service level can be improved.

Embodiment 5. FIG.
In the first to fourth embodiments, service monitoring is performed only by access of the cluster manager via the LAN 91. In the fifth embodiment, the cluster manager acquires the status of the guest OS using the virtual machine control I / F in addition to the service monitoring via the LAN 91, and also performs the service monitoring from the information.
The operation of the fifth embodiment will be described.
The cluster manager 20A accesses and monitors the service 31A via the LAN 91 at regular intervals, and acquires the status of the guest OS 12A using the virtual machine control I / F 91A at regular intervals. If the state is a failure state such as a crash, the cluster manager 20A detects the failure of the service 31A and recovers the service 31A.

  As described above, by including the state of the guest OS for monitoring the service, a failure can be detected from the state of the guest OS, and the reliability of the service can be improved.

Embodiment 6 FIG.
In the sixth embodiment, the guest OSs 12A to 12B and the host OS 11A have different types of operating systems or different operating system configurations and parameters.
For example, in FIG. 7, Linux1 is the host OS, Linux1 'is the guest OS12A, and Windows (registered trademark) is the guestOS12B. Linux1 running on the host OS runs the cluster manager, has only the modules and packages necessary for its functions, and the kernel parameters and other settings are optimized for the cluster manager. Linux1 'running on guest OS12A is the same OS as Linux1, but it has only modules and packages that only run applications 30A-31A, and kernel parameters and other settings are optimized for running applications 30A-30B It is. In the guest OS 12B, windows (registered trademark) operates, and an application 30C corresponding to only windows (registered trademark) operates.

  As described above, by applying an OS specialized only for providing services to the guest OS, it is possible to suppress the operation of extra modules and effectively use computer resources. There is no need to consider OS support between cluster managers and applications. In addition, you can select the optimal OS for each application and cluster manager. Therefore, the system construction is facilitated and the service level can be improved.

In Embodiments 1 to 6, the hot standby cluster system is constructed with two computers, but the number of computers may be three or more. Also, other failover methods such as active / active type may be used.
This makes it possible to improve service reliability, such as being able to deal with failures of a plurality of computers.

  The cluster system of the present invention can be applied to a server system that can improve reliability by combining cluster software and virtual machine technology.

BRIEF DESCRIPTION OF THE DRAWINGS It is a block diagram of the cluster system which shows Embodiment 1 of this invention. 5 is a configuration diagram of a cluster system showing a second embodiment. FIG. FIG. 10 is a configuration explanatory diagram of a guest OS according to a third embodiment. FIG. 10 is an operation explanatory diagram of the replicator according to the third embodiment. FIG. 10 is a flowchart of a snapshot image creation method according to Embodiment 4; FIG. 5 is a flowchart of booting from an OS image of a guest OS and a flowchart of booting from a snapshot image. FIG. 3 is an explanatory configuration diagram using different types of operating systems for a host OS and a guest OS. It is a block diagram showing the conventional cluster system. It is a block diagram of the conventional cluster system using a logical computer. It is a block diagram of the cluster manager which comprises the conventional cluster system.

Explanation of symbols

  1A, 1B: Physical computer, 2A, 2B: Computer resource partitioning mechanism, 3A-3D: Logical computer, 10A, 10B: Computer, 11A, 11B: Host OS, 12A, 12B: Guest OS, 13A, 13B: OS image, 15A, 15B: Operating system, 20A, 20B: Cluster manager, 30A, 30B, 30C: Application, 31A, 31B: Service, 40A, 40B: Client, 60A, 60B: Failover policy, 70A, 70B: Replicator, 80A, 80B : Local disk, 81: Shared disk, 90: Heartbeat, 90A, 90B: Virtual machine, 91: LAN, 91A, 91B: Virtual machine control I / F.

Claims (6)

A plurality of computers, a virtual machine installed in each of the plurality of computers, one host OS, a cluster manager that operates only on the host OS,
A guest OS that operates an application for a service provided externally to at least one of a plurality of computers;
It has an OS image of the guest OS and a shared disk that can be accessed from each computer.
The cluster manager uses the virtual machine function to start and stop each guest OS, monitor the service status, and if a service failure is detected, the cluster manager can recover the service from the failure according to a preset failover policy. The cluster manager has a heartbeat function that monitors the status of each other, and when a failure of another cluster manager is detected, a failover function that recovers all services managed by the cluster manager from the failure using the OS image of the shared disk. Have
Each guest OS is dedicated to a specific service, and is associated with a failover policy that instructs how to restore each service. The guest OS itself is regarded as a single service and managed by the cluster manager. Feature cluster system. The shared disk with the OS image of the guest OS is formed with local disks that each computer has,
2. The cluster system according to claim 1, wherein each host OS installed in each computer has a replicator and is configured to synchronize an OS image in a local disk in each computer between the computers.   The OS image of the guest OS is composed of a system image that is an image of a disk partition in which the OS and applications are stored, and a data image that is an image of a disk partition in which the applications store data. Or the cluster system of 2. In addition to the OS image of the guest OS, the shared disk has a snapshot image that is a snapshot immediately after the guest OS starts and the application starts.
The cluster system according to any one of claims 1 to 3, wherein the cluster manager is configured to start from a snapshot image when the guest OS is started during operation.   The cluster manager obtains the status of each guest OS by using the virtual machine control I / F together with service monitoring by access via a LAN, and handles the information as service monitoring information. The cluster system as described in any one of thru | or 4.   The cluster system according to any one of claims 1 to 5, wherein the guest OS and the host OS installed in the computer have different types of operating systems or different configurations and parameters of the operating systems. .

Images