Source: http://www.google.com/patents/US20050289390?ie=ISO-8859-1&dq=5251294
Timestamp: 2014-03-16 12:47:11
Document Index: 578990533

Matched Legal Cases: ['art 1106', 'art 1106', 'art 1111', 'art 1112', 'art 1112', 'arts 1206', 'art 1113', 'art 1113', 'art 1112', 'art 1111', 'art 1112', 'art 1113', 'art 1113', 'art 1111', 'arts 1206', 'art 1111', 'art 1113', 'art 1113', 'art 1111', 'art 1113', 'art 1111', 'art 1112', 'art 1111', 'art 1113', 'art 1111', 'art 1113', 'art 1112', 'arts 1206', 'arts 1206', 'art 1113', 'art 1112']

Patent US20050289390 - Failover method for a cluster computer system - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA high availability cluster computer system can realize exclusive control of a resource shared between computers and effect failover by resetting a currently-active system computer in case a malfunction occurs in the currently-active system computer. In case a malfunction occurs in a certain system in...http://www.google.com/patents/US20050289390?utm_source=gb-gplus-sharePatent US20050289390 - Failover method for a cluster computer systemAdvanced Patent SearchPublication numberUS20050289390 A1Publication typeApplicationApplication numberUS 11/065,352Publication dateDec 29, 2005Filing dateFeb 25, 2005Priority dateJun 29, 2004Also published asUS7418627, US7853835, US20090089609Publication number065352, 11065352, US 2005/0289390 A1, US 2005/289390 A1, US 20050289390 A1, US 20050289390A1, US 2005289390 A1, US 2005289390A1, US-A1-20050289390, US-A1-2005289390, US2005/0289390A1, US2005/289390A1, US20050289390 A1, US20050289390A1, US2005289390 A1, US2005289390A1InventorsTsunehiko BabaOriginal AssigneeTsunehiko BabaExport CitationBiBTeX, EndNote, RefManReferenced by (11), Classifications (9), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetFailover method for a cluster computer systemUS 20050289390 A1Abstract A high availability cluster computer system can realize exclusive control of a resource shared between computers and effect failover by resetting a currently-active system computer in case a malfunction occurs in the currently-active system computer. In case a malfunction occurs in a certain system in a cluster, another system in the cluster which has detected the malfunction issues a reset based on a priority to realize failover in which a standby system takes over the processing of the malfunctioning system when the malfunctioning system is stopped. Images(6) Claims(8)
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS It is to be understood that the drawings and description related to the present invention have been simplified to show suitable elements for providing a clear understanding of the present invention, and that certain known elements are omitted which do not embody the present invention. This technique includes some conventional elements which should be changed to others which seem to be desirable and/or necessary for implementing the present invention. Those elements, which are known and which cannot facilitate a understanding of the present invention, will not be described here. The accompanying drawings will be described below in detail. FIG. 1 shows a system blocks of active/standby computers according to the present invention. For facilitating the description, four-digit numbers are used to identify the programs. For this purpose, the same last two digits appended to the same program are used in common for the active computer and each standby system computer. The thousand's place is expressed as 1 for the active system computer (system A) and is expressed as 2 and 3, respectively, for the standby computers (systems B and C). Each program will be indicated below. The program of each computer is described by the program number on the active computer together with the description of the corresponding program on the standby computer. In FIG. 1, the system A has, as units for transmitting and receiving a communication with the outside, network adapters (NIC) 1103, 1104, and 1105, and a reset part 1106. It also has, as software programs, an operating system (OS) 1107, an application 1102, and a cluster program 1110. The NIC 1103 is used to enable the application 1102 to communicate with the outside. The NIC 1104 is used for communication to enable the cluster program 1110 to monitor other computers. The NIC 1105 is used to enable the cluster program 1110 to reset other computers. The NICs 1103 and 1104 are shown as separate elements for facilitating an understanding of the subject matter, but may be the same element. The reset part 1106 has a function of receiving a reset commend from the cluster programs 1210 and 1310 of the other systems to stop the system A. The function of stopping the system A is realized by application of a forceful stopping to the OS 1107. The cluster program 1110 has three modules. The cluster program will be described later with reference to FIG. 2. (1) A monitoring part 1111 has a function of monitoring whether the application program 1102 in the main system is normally operating, and a function of monitoring the status of the cluster programs 1210 and 1310 of the other systems via a communication part 1112. (2) The communication part 1112 has a function of communicating with the cluster programs 1210 and 1310 of the other systems via the NIC 1104, to effect communication of a reset instruction to reset parts 1206 and 1306 of the other systems in response to a request from the failover part 1113. (3) The failover part 1113 has a function of instructing a reset via the communication part 1112 to a system in which a malfunction occurs, based on the status of each system as obtained by the monitoring part 1111, and a function of indicating success in effecting reset of the malfunctioning system to the cluster programs 1210 and 1310 of the other systems using the communication part 1112 when a reset is successful. When the computer is a standby system which needs to take over the processing of the malfunctioning system, the failover part 1113 has a function of taking over the processing of the malfunctioning system upon reception of the notification of a reset success of the malfunctioning system received from the cluster programs 1210 and 1310 of the other systems, or upon sending a reset instruction of the main system to the malfunctioning system. The more detailed processes of the cluster programs 1110, 1210, and 1310 will be described later with reference to FIG. 3. The failover part 1113 further has a cluster status management table 1114 for managing the status of a cluster. FIG. 2 shows an example of the cluster status management table according to the present invention. In FIG. 2, the cluster status management table provides five pieces of information: (1) a system identifier 21 for uniquely identifying each system; (2) a system status indicator 22 indicating a status monitored by the monitoring part 1111; (3) a reset priority 23 indicating the order in which each system issues a reset; (4) a reset side identifier 24 for identifying the reset parts 1206 and 1306 of the other systems on the communicated side of a reset instruction when resetting the other systems; and (5) a reset timer 25 indicating at what timing reset of each system is instructed. The delay time (reset delay time) from detection of a malfunctioning system to issuance of a reset instruction from the main system to the malfunctioning system is stored in the reset timer 25. In case a malfunction occurs so that heartbeat detection of the system C is impossible, there is a difference in the reset delay time set to the timers of the systems. The reset delay time in the systems is stored so that the issuance of a reset instruction triggered by plural systems is effected with a time interval. In the present embodiment, specifically, the reset delay time of the systems is stored so that reset is performed in a certain order based on the reset priority 23. A system with a priority one rank above that of the main system instructs a reset. Over a fixed time difference to ensure that reset is performed, it is possible to ensure that reset is performed in accordance with the reset priority 23. The reset delay time set to the timer of the systems may be set so as to establish a time difference for the systems along system hardware according to the reset priority set to the systems. Reset interval definitions 1116, 1216, and 1316 hold information on the time difference. Alternatively, the reset delay time of the systems may be directly set to the reset interval definitions 1116, 1216, and 1316 by the user. The reset priority 23 may use a value which is not doubled and is uniquely determined in all of the cluster systems. The reset priority 23, which is statically provided by the user, is provided by the priority definition 1115 to the cluster program 1110. FIG. 5 shows the priority definition 1115. The priority definition 1115 includes a system identifier 51 and a reset priority 52. The system identifier 51 may have the same value as that of the system identifier 21 and may have a value uniquely corresponding to the system identifier 21. The reset priority 52 may have the same value as that of the reset priority identifier 23 and may have a value uniquely determining the reset priority 23 using the reset priority 52. When using an IP address as the reset priority 52, the difference relation is used to uniquely determine the reset priority 23. The user statically provides the reset priority 23 based on the priority definition 1115. A method of dynamically determining the reset priority 23 by the cluster program may also be used. In this case, information included in the priority definition 1115 may be used. System addition and deletion of information in the status management table 1114 are performed as follows. The cluster program 1110 starts monitoring with the cluster program of a new system using the monitoring part 1111 to add the new system to the table. When the cluster program 1110 resets a malfunctioning system using the failover part 1113, or when the cluster programs of other systems notify the cluster program 1110 that the malfunctioning system is reset, information relating to the malfunctioning system is deleted. For simplifying the description, this embodiment illustrates an example in which the failover part 1113 has one cluster status management table 1114. However, the information 21 to 25 included in the cluster status management table may be divided into plural tables for management and may be in a cluster program other than the failover part. FIGS. 3 and 4 show the flows of the processes of the cluster program according to the present invention, in which FIG. 3 shows the malfunction monitoring operation of the system focusing on the monitoring part 1111, and FIG. 4 shows the failover operation focusing on the failover part 1113. These processes will be described below in detail corresponding to FIGS. 1 and 2. When executing the cluster program 1110, it monitors malfunctions of each other's systems are monitored. The monitoring part 1111 periodically communicates with the cluster programs 1210 and 1310 of the other systems via the communication part 1112 to perform system monitoring of the other systems. The status of each of the systems obtained in step 31 is registered into the system status 22 corresponding to the system identifier 21 in the status management table 1114 (step 301 ) The system status 22 of each of the systems obtained in the step 301 is referred to so as to judge whether a system in which a malfunction occurs (malfunction system) exists or not (step 302). When a malfunctioning system does not exist, it is determined that all systems are being normally operated. The routine is returned to the step 301 to periodically continue monitoring. When a malfunctioning system exists, the monitoring part 1111 calls the failover part 1113 (the dotted line in the drawing) to execute step 401 of the failover processing (step 303) The monitoring part 1111 executes the step 303 to return to the step 301 for monitoring the status of the other systems in the cluster again. The instruction to the failover part, which has been performed in step the 303, is judged in step 401. In the step 401, whether a new malfunctioning system has been detected or not is judged. When a new malfunctioning system exists, the failover part 1113 refers to the reset priority 23 of the management table 1114 (step 402). The time during which the main system resets the malfunctioning system is set to the reset timer 25 of the cluster status management table 1114 based on the reset priority (step 403) so as to perform step 404. In the step 401, when a new malfunctioning system does not exist, the step 404 is performed. In the step 404, whether the time of the reset timer set in the step 403 has elapsed or not is judged. At the time to issue a reset, a reset instruction is sent via the communication part 1112 from the status management table 1114 to the reset parts 1206 and 1306 of the other systems indicated by the reset side identifier 24 of the system identifier 21 to be reset (step 405). The reset parts 1206 and 1306, which have received the reset instruction, stop the operation of the main system so as to stop the use of the shared resource. To stop the operation of the main system, the power may be turned off, the software may be reset, the OS may be shut down, or the OS may hang up. In the step 405, after the reset is successful, the failover part 1113 sends a notification via the communication part 1112 to the cluster programs of other systems that the reset of the malfunctioning system has been performed (step 406). The reset timer 25 of the reset malfunctioning system in the status management table 1114 is cleared (step 407), and the processing returns to the step 401. In the step 404, when the time of the reset timer set in the step 403 has not elapsed, whether reset completion is performed from other systems or not is judged (step 408). When other systems having a reset priority higher than that of the main system exist, the cluster programs of the other systems precedently execute steps 404 to 407. The malfunctioning system already may have been reset. When the cluster programs of the other systems indicate a completion of the reset, the reset timer of the reset malfunctioning system is cleared (step 407) so as to not reset the malfunctioning system again, and the processing will return to the step 401. In step 408, when the cluster programs of the other systems have not indicated reset completion, the malfunctioning system has not been reset, and the processing will to return to the step 401 without performing any process. FIG. 6 is a diagram showing the timing at which a reset realized by the present invention is performed. The vertical axis of FIG. 6 indicates the lapse of time and a reset process with time elapse. The left side of FIG. 6 indicates the owner of a shared resource, that is, which system is an active system. The right side of FIG. 6 indicates a reset process in each system. For simplifying the description, FIG. 6 shows a case in which a network split occurs in a cluster of three computers consisting of the systems A, B, and C in descending order of reset priority. When a network split occurs at time T0, times T1, T2, and T3 are set to the reset timers of the systems A, B, and C, respectively, based on the reset priority. When the systems are normal, reset is performed to a malfunctioning system, as seen from its own computer at the set time. When the systems B and C malfunction, as seen from the system A, the system A resets them at the time T1 (arrows 601 and 602). In case malfunctions which cannot be reset by the system A occur at the same time, the system B performs a reset at the time T2 (arrows 611 and 612). In case a malfunction which cannot be reset by the system B occurs, the system C performs reset at the time T3 (arrows 621 and 622). The system A owns the shared resource at the time T0 to T2. The system B owns the shared resource at the time T2 to T3. The system C owns the shared resource at the time T3 to T4. Failover is thus performed. After the time T4, the reset path cannot be normal, which is not targeted in the present invention. According to the above-described embodiment of the present invention, the following effects are provided. In a high availability cluster computer system having a reset path, in case the heartbeat for the system monitoring is lost, the malfunctioning system is reset in accordance with the reset priority. This ensures that only systems in a cluster, in which the system which has performed a reset exists, use the shared resource. Failover can be realized at the time of a network split. When a system having the highest reset priority cannot malfunction, the system resets a malfunctioning system immediately so as to realize a quick failover. The user statically defines the priority definition to the cluster program. It is possible to realize failover to freely set the reset priority to control the side subject to failover. The user defines a reset interval to the cluster program to control reset the timing. According to the present invention, when an active system computer cannot be monitored, failover can be realized to a cluster in which a system having high reset priority exists. Quick failover is thus possible. It is expected that the present invention can be widely embodied as a high availability computer system. Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7467322 *Aug 11, 2005Dec 16, 2008Hitachi, Ltd.Failover method in a cluster computer systemUS7487390 *Jun 8, 2006Feb 3, 2009Hitachi, Ltd.Backup system and backup methodUS7743372Jun 28, 2005Jun 22, 2010Internatinal Business Machines CorporationDynamic cluster code updating in logical partitionsUS7774785Jun 28, 2005Aug 10, 2010International Business Machines CorporationCluster code managementUS7870424 *Nov 13, 2007Jan 11, 2011Honda Motor Co., Ltd.Parallel computer systemUS7913105 *Sep 29, 2006Mar 22, 2011Symantec Operating CorporationHigh availability cluster with notification of resource state changesUS7925922Feb 25, 2009Apr 12, 2011Hitachi, Ltd.Failover method and system for a computer system having clustering configurationUS7937616 *Jun 28, 2005May 3, 2011International Business Machines CorporationCluster availability managementUS8176302 *Sep 26, 2006May 8, 2012Nxp B.V.Data processing arrangement comprising a reset facilityUS8458515Nov 16, 2009Jun 4, 2013Symantec CorporationRaid5 recovery in a high availability object based file systemUS8495323Dec 7, 2010Jul 23, 2013Symantec CorporationMethod and system of providing exclusive and secure access to virtual storage objects in a virtual machine cluster* Cited by examinerClassifications U.S. Classification714/11, 714/E11.072International ClassificationG06F11/00Cooperative ClassificationH04L69/40, G06F11/2046, G06F11/2028European ClassificationH04L29/14, G06F11/20P2E, G06F11/20P12Legal EventsDateCodeEventDescriptionJan 25, 2012FPAYFee paymentYear of fee payment: 4Feb 25, 2005ASAssignmentOwner name: HITACHI, LTD., JAPANFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BABA, TSUNEHIKO;REEL/FRAME:016338/0675Effective date: 20050131RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google