JP4874847B2 - Cluster system - Google Patents

Description

  The present invention relates to a cluster system and a program including a plurality of server machines, and more particularly to a cluster system capable of matching data even when a failover occurs.

  For example, in a cluster system represented by the system disclosed in Non-Patent Document 1, as shown in FIG. 20, there are an active server machine 10 (#A) and a standby server machine 10 (#B). The active server machine 10 (#A) is executed, and the application 11 (#A) is executed, and the execution result data is written to the mirroring disk device 20 (#A) as indicated by (101). Meanwhile, as shown in (102), the cluster software 12 (#A) of the active server machine 10 (#A) and the cluster software 12 (#B) of the standby server machine 10 (#B) are: A predetermined packet called heartbeat a is continuously exchanged via the communication path 50 to notify each other of their survival.

  Further, as shown in (103), the data stored in the mirroring disk device 20 (#A) is mirrored to the mirroring disk device 20 (#B) by always performing mirroring while the heartbeat continues. .

  In this state, when the cluster software 12 (#B) detects the disconnection of the heartbeat a, as shown in (104), the same application 11 (#B) is used in the standby server machine 10 (#B). In general, so-called failover b is performed in which application processing is continued by activating.

The main reasons for the heartbeat a breaking are as follows.
[1] Down of the active server machine 10 (#A).
[2] Communication path 50 failure.
[3] Temporary slowdown due to high CPU load or the like in the active server machine 10 (#A).

  In the case of the above [1], it is sufficient to simply fail over to the standby server machine 10 (#B), but in the case of [2] and [3], the active server machine 10 (# Since A) continues the processing, the following inconvenience occurs when failover b occurs.

  That is, as shown in FIG. 21, in the state in which the mirroring disk devices 20 (#A) and 20 (#B) are mirrored via the communication line 52 in a plurality of server machines 10 (#A and #B), When a cluster is configured for a database server application (hereinafter referred to as “DB server”) 13 (#A, #B), if failover b occurs due to heartbeat a interruption caused by [3] above, a mirroring disk device Mirroring between 20 (#A) and 20 (#B) is forcibly stopped. This is because the write from the DB server 13 (#B) newly executed on the server machine 10 (#B) that is the standby system and the DB server 13 (# #) of the server machine 10 (#A) that is the active system. This is to avoid data destruction due to the mixed write from A).

  However, in order for the server machine 10 (#B) that is the standby system to take over all of the IP address, data, and the like of the server machine 10 (#A) that is the active system, the database client (hereinafter referred to as “DB client”). 61) does not recognize that the DB server 13 (#A) has failed over to the DB server 13 (#B), and there is a possibility that transaction consistency may be lost.

  For example, as shown in FIG. 21, when the DB server 13 (#A) of the server machine 10 (#A) receives a commit request from the DB client 61 in the client 60 (201) and slows down as it is (202 ) When the cluster software 12 (#B) detects that the heartbeat a is expired (203), the mirroring is stopped (204) and the server machine 10 (#B) performs failover (205). However, the DB server 13 (#A) of the restored server machine 10 (#A) writes to its mirroring disk device 20 (#A) and completes normally (206). At this time, since mirroring is already stopped, it is not performed (207), but a commit success is returned to the DB client 61 (208).

  However, since this commit is not reflected in the server machine 10 (#B), when the server machine 10 (#B) receives a rollback request from the DB client 61 after failover (209), the server machine 10 (#B) The DB server 13 (#B) of #B) is rolled back to a checkpoint one before the checkpoint intended by the DB client 61 (210). After that, when the database is updated or committed in the database B according to the request (211) made from the DB client 61 to the server machine 10 (#B) (212), the server machine 10 (#A) The DB server 13 (#A) of the server and the DB server 13 (#B) of the server machine 10 (#B) will be in different states from what they should be.

  As shown in FIG. 22, the same problem occurs in the server A data area 32 (# for writing data made by the server machine 10 (#A) instead of the mirroring disk device 20 (#A, #B). This can occur even when a cluster is formed by using the shared disk device 31 including A) and the server B data area 32 (#B) for writing data made by the server machine 10 (#B). There is sex.

  That is, as shown in FIG. 22, when the DB server 13 (#A) of the server machine 10 (#A) receives a commit request from the DB client 61 in the client 60 (301) and slows down as it is (302) ) When the cluster software 12 (#B) detects that the heartbeat a is expired (303), the data in the server A data area 32 (#A) is copied to the server B data area 32 (#B) (304). ), The server machine 10 (#B) performs failover (305). However, the DB server 13 (#A) of the server machine 10 (#A) that has returned thereafter writes to the server A data area 32 (#A), ends normally (306), and commits successfully to the DB client 61. Return (307).

  However, since this commit is not reflected in the server machine 10 (#B), when the server machine 10 (#B) receives a rollback request from the DB client 61 after failover (308), the server machine 10 (#B) The DB server 13 (#B) of #B) is rolled back to a checkpoint one before the checkpoint intended by the DB client 61 (309). Thereafter, when the database server 13 (#B) updates or commits the database (311) according to the request (310) made from the DB client 61 to the server machine 10 (#B), the server machine The DB server 13 (#A) of the 10 (#A) and the DB server 13 (#B) of the server machine 10 (#B) will be in different states from what they should be.

From the above, in the conventional cluster system, when the server machine 10 (#A) that was the original active system is restored and the heartbeat a is restored, the server machine 10 (#A) and the server machine are immediately restored. 10 (#B) is stopped or restarted, or a failure occurs in one of the communication paths 50 by multiplexing the communication paths 50 between the cluster software 12 (#A) and 12 (#B) Even so, measures are taken to prevent the heartbeat a from being interrupted.
Toshiba Review Vol. 54 No. 12 (1999), pages 18-21

  However, such a conventional cluster system has the following problems.

  That is, even if the above measures are taken, if a temporary slowdown occurs due to a high CPU load or the like in the [3] active server machine 10, transaction inconsistency occurs immediately after failover. There is a problem that the possibility is not completely avoided.

  For example, in the cluster system shown in FIG. 22, a shared area 33 is provided in the shared disk apparatus 31 as shown in FIG. 23, and the shared disk apparatus 31 is managed by the disk access right management table 33a stored in the shared area 33. The server machine 10 is provided with a filter driver 14 every time data write (Write) or read (Read) (hereinafter referred to as I / O) occurs in the shared disk device 31. A method of returning the processing result to the upper client 60 according to the presence or absence of the access right is used, and at the time of failover, the server machine 10 (#B) as the standby system accesses the server machine 10 (#A) as the active system It can be avoided by improving to take away the right.

  That is, in this configuration, when the DB server 13 (#A) of the server machine 10 (#A) receives a commit request from the DB client 61 in the client 60 (401) and slows down as it is (402), the cluster When the software 12 (#B) detects that the heartbeat a is expired (403), the cluster software 12 (#B) further sets the disk access right management table 33a in the server machine 10 (#A) instead of the server machine 10 (#A). B) is rewritten so that the access right to the shared disk device 31 is given (404).

  Thereafter, the data in the server A data area 32 (#A) is copied to the server B data area 32 (#B) (405), and the server machine 10 (#B) fails over (406). However, when the DB server 13 (#A) of the server machine 10 (#A) is subsequently restored, the filter driver 14 (#A) displays the processing result of the DB server 13 (#A) as the server A data area 32 (# A) is written to (A) (407), and further, referring to the disk access right management table 33a, it is confirmed whether or not the access right is given to the server machine 10 (#A) (408).

  If the access right is given, a normal return is returned from the filter driver 14 (#A) to the DB server 13 (#A). If the access right is not given, an error return is returned (409). In this case, since an access right is given to the server machine 10 (#B), an error is returned. Further, this error is returned from the DB server 13 (#A) to the DB client 61 (410).

  As a result, the client 60 grasps that the processing for the commit request made to the server machine 10 (#A) in (401) has an error, and this time requests the server machine 10 (#B) to make a commit request. Is retried (411). In response to this, the DB server 13 (#B) notifies the DB client 61 of the completion of the commit request (412). Thereafter, the database is updated in the DB server 13 (#B) in accordance with the database update request (413) made by the DB client 61 to the server machine 10 (#B) (414).

  Thereafter, a database rollback request is made from the DB client 61 to the DB server 13 (#B) (415). In response to this, a rollback request is completed from the DB server 13 (#B) to the DB client 61 (success). ) Is notified (416). Subsequently, a database update request is made from the DB client 61 to the DB server 13 (#B) (417). In response to this, an update request completion (success) is sent from the DB server 13 (#B) to the DB client 61. Notification is made (418). Further, a commit request is made from the DB client 61 to the DB server 13 (#B) (419), and in response thereto, the commit request completion (success) is notified from the DB server 13 (#B) to the DB client 61. (420).

  However, in the configuration shown in FIG. 23, each time a disk I / O (read or write) occurs once, I / O (read or write) to the shared disk device 31 occurs once. A new problem arises that the performance degradation of / O becomes large.

  On the other hand, FIG. 24 shows a configuration in which the improvement as shown in FIG. 23 is applied to the cluster system including the mirroring disk device 20 shown in FIG.

  That is, in this configuration, the DB server 13 (#A) of the server machine 10 (#A) receives a commit request from the DB client 61 in the client 60 (501), and based on this, the filter driver 14 (#A ) Issues a write corresponding to the commit request to the mirroring disk device 20 (#A) (502).

  After that, when the mirroring disk device 20 (#A) copies and mirrors data to the mirroring disk device 20 (#B), the server machine 10 (#A) slows down (503) and then returns. It shall be. In this case, when the slowdown occurs, the cluster software 12 (#B) detects that the heartbeat a has expired (504). Thereafter, even if the server machine 10 (#A) returns, mirroring from the mirroring disk device 20 (#A) to the mirroring disk device 20 (#B) fails due to a communication timeout or the like (505).

  Thereafter, the filter driver 14 (#A) refers to the disk access right management table 33a and confirms whether the access right is given to the server machine 10 (#A) (506). At this time, the disk access right management table 33a is not rewritten by the cluster software 12 (#B) so that the access right is given to the server machine 10 (#B), that is, at the timing of (506). Later, if the cluster software 12 (#B) rewrites the disk access right management table 33a so that the access right is given to the server machine 10 (#B) (507), the filter driver 14 (#A) Returns a normal return to the DB server 13 (#A) (508).

  Thereafter, the server machine 10 (#B) fails over (509). On the other hand, the DB server 13 (#A) notifies the DB client 61 of the commit processing result (success) (510).

  However, since this commit is not reflected in the server machine 10 (#B), when the server machine 10 (#B) receives a rollback request from the DB client 61 after the failover (511), the server machine 10 (#B) The DB server 13 (#B) of #B) is rolled back to a checkpoint one before the checkpoint intended by the DB client 61 (512). Thereafter, when the database server 13 (#B) updates or commits the database (514) according to the request (513) made from the DB client 61 to the server machine 10 (#B), the server machine The DB server 13 (#A) of the 10 (#A) and the DB server 13 (#B) of the server machine 10 (#B) will be in different states from what they should be.

  As described above, when the improvement as shown in FIG. 23 is applied to the cluster system including the mirroring disk device 20, the possibility that transaction inconsistency occurs immediately after failover can be completely avoided. The problem is not solved.

  The present invention has been made in view of such circumstances, and in a cluster system including a plurality of server machines, even if a failover occurs, a transaction can be performed while suppressing deterioration in disk I / O performance. It is an object of the present invention to provide a cluster system and a program capable of matching the above.

  In order to achieve the above object, the present invention takes the following measures.

  That is, the invention of claim 1 is a cluster system comprising a plurality of server machines and a shared disk device shared and connected to the plurality of server machines, wherein the plurality of server machines are a plurality of server machines. Each of the above applications, cluster software that runs on multiple server machines, filter drivers that run on multiple server machines, and expiration date notification daemons that run on multiple server machines ing. The shared disk device includes a server data area for storing data of each server machine, and a shared area shared by each server machine. The shared area is connected to the shared disk device for each server machine. An access management unit for managing access information in which permission or denial of access is set.

  The expiration notification daemon periodically refers to the access information managed by the access management unit, and if access by the local server machine is permitted, the expiration notification daemon adds a predetermined time to the current time. Set and notify the filter driver of this server machine of this expiration date, and each cluster software provided in multiple server machines communicate with each other periodically to check the survival status of each other's server machine, Each has two types of states, an active system and a standby system.

  When the cluster software becomes an active system, the cluster software changes the access information managed by the access management unit so that only the local server machine is allowed access, and the local server machine automatically changes the access information. Make the server data area of the server machine visible, and start the application provided on the server machine. After the cluster software becomes active, the filter driver of the active server machine waits for I / O input, and if some or all of the I / O input processing results are successful, confirms the current time. If the current time is within the expiration date notified from the expiration date notification daemon, the processing result is returned to the I / O input side, and if it is not within the expiration date, an error is returned to the I / O input side. If the cluster software on the standby server machine determines that the active server machine is not alive, the cluster software on the standby server machine sends the access information managed by the access management unit to its own server. Change so that only the machine is allowed access, wait for a certain period of time, and then make the server data area of the local server machine visible from the local server machine and start the application provided on the local server machine .

  According to the present invention, in a cluster system including a plurality of server machines, even when failover occurs, a cluster system capable of achieving transaction matching while suppressing performance degradation of disk I / O. Can be realized.

  The best mode for carrying out the present invention will be described below with reference to the drawings.

  In addition, the code | symbol in the figure used for description of each following embodiment attaches | subjects and shows the same code | symbol about the same part as FIG. 20 thru | or FIG.

(First embodiment)
FIG. 1 is a functional block diagram illustrating a configuration example of the cluster system according to the first embodiment.

  That is, the cluster system according to the present embodiment includes a plurality of server machines (here, two server machines 10 (#A, #B) are shown as an example) and these server machines 10 (#A, #B). This is a cluster system composed of a shared disk device 31 connected to. Here, it is assumed that the server machine 10 (#A) is an active system and the server machine 10 (#B) is a standby system as an initial state. Each server machine 10 (#A, #B) has an application 11 (#A, #B) and cluster software 12 (#A, #B) respectively running on each server machine 10 (#A, #B). , Filter driver 14 (#A, #B), disk driver 15 (#A, #B), and expiration date notification daemon 16 (#A, #B). The filter driver 14 is provided between the application 11 and the disk driver 15. The application 11 mainly assumes a server application, and is assumed to be a proxy cache server in the present embodiment.

  The shared disk device 31 is connected to each of the server machines 10 (#A, #B) via FC (Fiber Channel) cables 51 (#A, #B), and further to the server A data area 32 (#A). And a server B data area 32 (#B) and a shared area 33. These may be different LUs (Logical Units), different partitions, or different files.

  FIG. 2 is a conceptual diagram showing a detailed configuration example of the shared disk device 31.

  As shown in FIG. 2, the shared area 33 is a disk access right for managing access information in which permission or non-permission of access to the shared disk device 31 is set for each of the server machines 10 (#A, #B). A management table 33a is held. As shown in FIG. 2, when the server A is set to “present” and the server B is set to “none”, the access of the server machine 10 (#A) is permitted and the access of the server machine 10 (#B) Indicates that is not allowed.

  The expiration date notifying daemon 16 refers to the disk access right management table 33a periodically (for example, every 30 seconds). Then, if access by the server machine 10 is permitted, the expiration date notification daemon 16 sets an expiration date obtained by adding a predetermined time (for example, 60 seconds) to the current time, and this expiration date is set. Is sent to the filter driver 14 of the server machine 10. For example, as shown in FIG. 3, the expiration date notifying daemon 16 grasps the current time from the one that is not affected by the time change (such as the startup time after booting).

  Further, the cluster software 12 (#A, #B) communicates with each other periodically, confirms the survival state of each server machine 10, and has two types of states: an active system and a standby system. In the following description, it is assumed that the server machine 10 (#A) is an active system and the server machine (#B) is a standby system. Therefore, the cluster software 12 (#A) is in an active state, and the cluster software 12 (#B) is in a standby state.

  When the cluster software 12 (#A) becomes an active system, the cluster software 12 (#A) is permitted to access only the information of the disk access right management table 33a only to its own server machine 10 (#A). And the server data area 32 (#A) can be seen from the server machine 10 (#A) side, and the application 11 (#A) provided in the server machine 10 (#A) is started.

  After the cluster software 12 (#A) becomes active in this way, the filter driver 14 (#A) waits for an I / O input from the client 60 as shown in FIG. When a part or all of the processing results of the O input are successful, the current time is confirmed, and if the current time is within the expiration date notified from the expiration date notification daemon 16 (#A), the processing result is, for example, the client Returns to the I / O input side such as 60, and returns an error to the I / O input side if it is not within the validity period. Such confirmation of the current time is performed every time the filter driver 14 (#A) returns the processing result to the I / O input side.

  On the other hand, if the cluster software 12 (#B) of the standby server machine 10 (#B) determines that the active server machine 10 (#A) is not alive, the cluster software 12 (#B ) Changes the information set in the disk access right management table 33a so that only the server machine 10 (#B) is permitted to access, waits for a predetermined time (for example, 30 seconds), and then The server data area 32 (#B) can be seen from the server machine 10 (#B) side, and the application 11 (#B) is activated.

  By waiting in this way, the server machine 10 (#B) does not immediately fail over after acquiring the access right, but fails over after entering a safe time zone. The predetermined time for standby can be arbitrarily set, but the longer it takes, the longer the time required for failover. On the other hand, as the time is shorter, the time required for failover becomes shorter, but the access frequency to the shared area 33 becomes higher.

  Next, the operation of the cluster system according to this embodiment configured as described above will be described. However, as an initial state, the cluster software 12 (#A, #B) exchanges heartbeats between the server machine 10 (#A) and the server machine 10 (#B), and the existence of each other can be confirmed. The server machine 10 (#A, #B) is in a state where the shared area 33 and the server data areas 32 (#A, #B) are not visible from the upper layer (the filter driver 14 is fence-off). In addition, it is assumed that the application 11 (#A, #B) is not activated in either the server machine 10 (#A, #B).

  First, the flow of processing by the cluster software 12 (#A) when the server machine 10 (#A) is set as an active system will be described using the flowchart shown in FIG.

  First, a notification that the server machine 10 (#A) should be an active system is sent to the cluster software 12 (#A) of the server machine 10 (#A) (S1). Next, the disk access right management table 33a is set so that the access right is given to the server machine 10 (#A) by the cluster software 12 (#A) (S2). Then, the cluster software 12 (#A) notifies the filter driver 14 (#A) that it has become an active system (S3). Thereafter, the server A data area 32 (#A) is made visible from the upper layer by the filter driver 14 (#A) of the server machine 10 (#A) (S4). Then, the expiration date notification daemon 16 (#A) is activated by the cluster software 12 (#A) of the server machine 10 (#A) (S5), and further the application 11 (#A) is activated (S6).

  Next, the flow of processing by the filter driver 14 (#A) after setting the server machine 10 (#A) to the active system will be described using the flowchart of FIG. 5 and the conceptual diagram shown in FIG.

  First, the filter driver 14 (#A) of the server machine 10 (#A) waits for an I / O input from a host such as the client 60 shown in FIG. 21 (S11). If an I / O input is made and the I / O input made is a notification of an expiration date (S12: Yes), the process proceeds to step S13, and if it is not a notification of an expiration date (S12: No), Proceed to step S14.

  In step S13, the validity period is updated to the notified validity period, and then the process proceeds to step S24.

  In step S14, if the I / O input made in step S11 is read to the server A data area 32 (#A), go to step S15, if write, go to step S16, otherwise go to step S22. Proceed with each.

  In step S15, read is executed, and in step S16, write is executed, and the process proceeds to step S17.

  In step S17, if the I / O is partially or wholly successful, the process proceeds to step S18. If not, the process proceeds to step S20.

  In step S18, the current time is acquired. In step S19, the expiration date is notified from the expiration date notification daemon 16 (#A), and it is determined whether or not the current time acquired in step S18 is within the expiration date. If it is within the expiration date, the I / O processing result is returned to the upper level as it is (S20), and then the process proceeds to step S24.

  On the other hand, if it is determined in step S19 that the expiration date has passed, an I / O processing failure error is returned to the upper level (S21), and then the process proceeds to step S24.

  In step S22, the process is directly passed from the filter driver 14 (#A) to the disk driver 15 (#A). In step S23, the return value from the disk driver 15 (#A) is returned to the upper level as it is. The process proceeds to step S24.

  In step S24, if the OS ends, the process ends. Otherwise, the process returns to step S11.

  Next, the flow of processing by the expiration date notification daemon 16 (#A) after the server machine 10 (#A) is set to the active system will be described using the flowchart of FIG. 7 and the conceptual diagram shown in FIG. To do.

  The expiration date notification daemon 16 (#A) periodically refers to the disk access right management table 33a, for example, every 30 seconds (S31). When it is confirmed that the access right is given to the server machine 10 (#A) (S32), the current time is acquired (S33), and a predetermined time (for example, 60 seconds) is added to the current time. The expiration date is set (S34), the expiration date is notified to the filter driver 14 (#A) (S35), and the process proceeds to step S36. In step S32, if the access right is not given, the process proceeds to step S36. Note that the processing in step S35 corresponds to step S19 in FIG.

  In step S36, for example, after sleeping for 30 seconds, if the OS does not end, the process returns to step S31. If the OS ends, this process also ends.

  Next, the server machine when the cluster software 12 (#B) of the server machine 10 (#B) detects a heartbeat break and fails over using the flowchart shown in FIG. 8 and the conceptual diagram shown in FIG. The flow of processing 10 (#B) will be described.

  First, when the cluster software 12 (#B) of the server machine 10 (#B) detects that the heartbeat a has expired (S41), the cluster software 12 (#B) has access rights only to the server machine 10 (#B). Is set in the disk access right management table 33a (S42).

  Next, the cluster software 12 (#B) sleeps for a predetermined time (for example, 60 seconds) (S43), and then all the data in the server A data area 32 (#A) is transferred to the server B data area 32. (S44), the expiration date notification daemon 16 (#B) is started (S45), and the fact that the server machine 10 (#B) has become an active system is indicated by the filter driver 14 (#B). (S46).

  Then, the server B data area 32 (#B) is made visible from the upper layer by the filter driver 14 (#B) of the server machine 10 (#B) (S47). Then, the application 11 (#B) is activated by the cluster software 12 (#B) of the server machine 10 (#B) (S48).

  As described above, in the cluster system according to the present embodiment, the cluster software 12 (#B) of the standby server machine 10 (#B) is operated by the active server machine 10 ( When it is determined that #A) is not alive, only the server machine 10 (#B) can be permitted to access the shared disk device 31.

  As a result, even if a failover occurs, it is possible to avoid the redundant writing of the plurality of server machines 10 (#A, #B), and to achieve transaction matching.

  In addition, the failover is not executed immediately after the server machine 10 (#B) obtains the access right, but waits for a predetermined time (for example, 30 seconds), and fails over after entering a safe time zone. I have to.

  From the above, the cluster system according to the present embodiment is capable of performing transaction while suppressing deterioration of disk I / O performance even when failover occurs in a cluster system including a plurality of server machines. Can be matched.

(Second Embodiment)
FIG. 10 is a functional block diagram illustrating a configuration example of the cluster system according to the second embodiment. Since the cluster system according to the present embodiment is a modification of the cluster system according to the first embodiment, the same parts as those in the first embodiment are denoted by the same reference numerals, and redundant description is omitted. Different points will be described.

  That is, the cluster system according to the present embodiment is an application of the concept of the cluster system according to the first embodiment to a cluster system including the mirroring disk device 20.

  The difference between the cluster system according to the present embodiment as shown in FIG. 10 and the cluster system according to the first embodiment as shown in FIG. 1 will be described. The mirroring disk device 20 as shown in FIG. 1 is different from the cluster system shown in FIG. 1 in that the server machine 10 (#A) and the server machine 10 (#B) are not provided with the shared disk device 31. Mirroring disk devices 20 (#A) and 20 (#B) are connected to each other. A common computer 70 for holding the shared area 33 is also provided. The shared area 33 holds a disk access right management table 33a as in the cluster system according to the first embodiment. In addition to this, each server machine 10 (#A), 10 (#B) Are also stored in a mirroring error occurrence management table 33b for managing mirroring error information indicating whether or not a mirroring error has occurred in each mirroring disk device 20 (#A) and (#B). Each of the server machines 10 (#A) and 10 (#B) includes mirroring daemons 17 (#A) and 17 (#B) for referencing and setting the mirroring error occurrence presence / absence management table 33b.

  After the cluster software 12 (#A) becomes an active system, the filter driver 14 (#A) waits for an I / O input from the client 60, for example, as in the first embodiment. When a part or all of the processing results of the O input are successful, the current time is confirmed each time the processing results are returned to the I / O input side, and the current time is notified from the expiration notification daemon 16 (#A). If it is within the valid period, the processing result is returned to the I / O input side, and if it is not within the valid period, an error is returned to the I / O input side.

  However, if the processing results are not the same, in the present embodiment, the mirroring daemon 17 (#A) sends the mirroring error information managed in the mirroring error occurrence management table 33b to the server machine 10 (#A). Change so that a mirroring error has occurred.

  If the cluster software 12 (#B) of the standby server machine 10 (#B) determines that the active server machine 10 (#A) is not alive, the cluster software 12 (#B) ) Changes the information set in the disk access right management table 33a so that only the server machine 10 (#B) is permitted to access, and waits for a predetermined time (for example, 30 seconds) before mirroring. If the mirroring error information managed in the error occurrence management table 33b is not set so that a mirroring error has occurred for the server machine 10 (#B), from the server machine 10 (#B) side, While making the mirroring disk device 20 (#B) visible, the application 11 (#B) is activated.

  Next, the operation of the cluster system according to this embodiment configured as described above will be described. However, as an initial state, the cluster software 12 (#A, #B) exchanges heartbeats between the server machine 10 (#A) and the server machine 10 (#B), and the existence of each other can be confirmed. Both the server machine 10 (#A, #B) cannot see the shared area 33 and each mirroring disk device 20 (#A, #B) from the upper layer (the filter driver 14 is fence-off. However, the mirroring daemon 17 only. It is assumed that the application 11 (#A, #B) is not activated on the server machine 10 (#A, #B) and the mirroring daemon 17 is activated.

  First, the flow of processing by the cluster software 12 (#A) when the server machine 10 (#A) is set as an active system will be described using the flowchart shown in FIG.

  First, a notification that the server machine 10 (#A) is to be an active system is sent to the cluster software 12 (#A) of the server machine 10 (#A) by a user operation (S51). Next, the disk access right management table 33a is set so that the access right is given to the server machine 10 (#A) by the cluster software 12 (#A) (S52). Further, the mirroring error information managed in the mirroring error occurrence management table 33b by the cluster software 12 (#A) is such that no mirroring error has occurred in the server machine 10 (#A) (“no mirroring error”). (S53).

  Then, the cluster software 12 (#A) notifies the mirroring daemon 17 (#A) that it has become an active system (S54). Then, the cluster software 12 (#A) of the server machine 10 (#A) starts the expiration date notification daemon 16 (#A) (S55), and the filter driver 14 (#A) is executed by the cluster software 12 (#A). (S56).

  Thereafter, the filter driver 14 (#A) of the server machine 10 (#A) makes the mirroring disk device 20 (#A) visible from the upper layer (S57). Next, the application 11 (#A) is activated (S58).

  Next, the flow of processing by the filter driver 14 (#A) after setting the server machine 10 (#A) to the active system will be described using the flowchart of FIG. 12 and the conceptual diagram shown in FIG.

  First, the filter driver 14 (#A) of the server machine 10 (#A) waits for an I / O input from a host such as the client 60 shown in FIG. 21 (S61). If the I / O input is a notification of an expiration date (S62: Yes), the process proceeds to step S63. If the I / O input is not a notification of the expiration date (S62: No), the process proceeds to step S64.

  In step S63, after the expiration date is updated to the notified expiration date, the process proceeds to step S78.

  In step S64, if the I / O input made in step S61 is read to the mirroring disk device 20 (#A), the process proceeds to step S65. If write, the process proceeds to step S66. Otherwise, the process proceeds to step S76. .

  In step S65, read is executed, and the process proceeds to step S71. In step S66, write is executed, and the process proceeds to step S67.

  In step S67, the mirroring daemon 17 (#A) is requested to perform mirroring and waits. In step S68, mirroring is executed. If the mirroring is successful, the process proceeds to step S71. If the mirroring is not successful, the mirroring daemon 17 (#A) sets the mirroring error occurrence management table 33b to the server machine 10 (#A) in step S70. ) So that a mirroring error has occurred, and the process proceeds to step S71.

  In step S71, if the I / O is partially or wholly successful, the process proceeds to step S72. If not, the process proceeds to step S74.

  In step S72, the current time is acquired. In step S73, the expiration date is notified from the expiration date notification daemon 16 (#A), and it is determined whether or not the current time acquired in step S72 is within the expiration date. If it is within the validity period, the I / O processing result is returned to the upper level as it is (S74), and then the process proceeds to step S78.

  On the other hand, if it is determined in step S73 that the expiration date has passed, an I / O processing failure error is returned to the upper level (S75), and then the process proceeds to step S78.

  In step S76, the process is directly passed from the filter driver 14 (#A) to the disk driver 15 (#A). In step S77, the return value from the disk driver 15 (#A) is returned to the upper level as it is. The process proceeds to step S78.

  In step S78, if the OS ends, the process ends. If not, the process returns to step S61.

  Further, the flow of processing by the expiration date notification daemon 16 (#A) after setting the server machine 10 (#A) to the active system is as shown in the flowchart of FIG.

  Next, using the flowchart shown in FIG. 14 and the conceptual diagram shown in FIG. 15, the cluster machine 12 (#B) of the server machine 10 (#B) detects a heartbeat break and performs a failover. The flow of processing 10 (#B) will be described.

  First, when the cluster software 12 (#B) of the server machine 10 (#B) detects that the heartbeat a has expired (S81), the cluster software 12 (#B) only accesses the server machine 10 (#B). Is set in the disk access right management table 33a (S82).

  Next, the cluster software 12 (#B) sleeps for a predetermined time (for example, 60 seconds) (S83).

  On the other hand, if the server machine 10 (#A) is set to have a mirroring error occurrence in the mirroring error occurrence management table 33b in step S84 (S84: Yes), the process proceeds to step S85, otherwise. In the case (S84: No), the process proceeds to step S91.

  In step S85, the cluster software 12 (#B) sets the server machine 10 (#B) to have no mirroring error in the mirroring error occurrence management table 33b. Next, in step S86, the server machine 10 (#B) The cluster software 12 (#B) of B) notifies the mirroring daemon 17 (#B) that it has become an active system. As a result, reception of the mirroring data is stopped.

  Furthermore, the expiration date notification daemon 16 (#B) is activated (S87), and the server driver 10 (#B) is notified to the filter driver 14 (#B) (S88).

  Thereafter, the mirror driver 20 (#B) is made visible from the upper layer by the filter driver 14 (#B) of the server machine 10 (#B) (S89). Then, the application 11 (#B) is started by the cluster software 12 (#B) of the server machine 10 (#B) (S90), and the process is terminated.

  In step S91, the cluster software 12 (#B) changes the access right of the server machine 10 (#B) from “Yes” to “No” in the disk access right management table 33a (failover is abandoned). Exit.

  As described above, in the cluster system according to the present embodiment, it is possible to prevent failover from occurring when mirroring fails due to the above-described operation. Further, after a failover, it is possible to prevent I / O from succeeding on the server machine 10 (#A) side which is the original operating system. This makes it possible to avoid the occurrence of transaction inconsistencies.

  Further, since I / O to the mirroring disk device 20 is not generated each time the disk I / O (read or write) is performed, it is possible to suppress the performance degradation of the disk I / O.

  From the above, the cluster system according to the present embodiment is capable of performing transaction while suppressing deterioration of disk I / O performance even when failover occurs in a cluster system including a plurality of server machines. Can be matched.

(Third embodiment)
The cluster system according to the present embodiment is a modification of the cluster system according to the first and second embodiments. As shown in FIG. 16, instead of the filter driver 14, a jacket library (hereinafter referred to as "jacket") is used. The only difference is that it is configured to include an I / O processing library (hereinafter referred to as “I / 0 processing DLL”) 19 and a DLL 18. Therefore, here, differences from the cluster systems according to the first and second embodiments will be described.

  That is, in the cluster system according to the first and second embodiments, the filter driver 14 determines the expiration date. However, in this embodiment, the higher-level library is used instead of the filter driver 14. Yes. At this time, a jacket DLL 18 that hooks the I / O and performs its own processing is provided between the I / O processing DLL 19 for performing the original I / O processing and the application 11. For details of the jacket DLL, refer to JP-A-11-110194. The jacket DLL 18 looks as if it is an I / O processing DLL 19 when viewed from the application 11, and has a process handle management table 18a for the application 11 as shown in FIG. Only the application 11 (process 1 and process 2 shown in FIG. 17) passes the determination routine based on the expiration date.

  In the following, as shown in FIG. 16, a case where the present invention is representatively applied to a configuration including the shared disk device 31 as shown in the first embodiment will be described. The configuration provided with the jacket DLL 18 and the I / O processing DLL 19 instead of the filter driver 14 can also be applied to the configuration provided with the mirroring disk device 20 as shown in the second embodiment. What is applied to the configuration including the mirroring disk device 20 as shown in the second embodiment is also understood as an example of the present invention.

  Next, the flow of processing by the filter driver 14 (#A) after setting the server machine 10 (#A) to the active system will be described using the flowchart of FIG. 18 and the conceptual diagram shown in FIG. Note that the flow of processing by the cluster software 12 (#A) when the server machine 10 (#A) is set to the active system, the cluster software 12 (#B) of the server machine 10 (#B) detects a heartbeat break. The process flow of the server machine 10 (#B) at the time of failover is the same as in the first and second embodiments. In addition, regarding the processing by the expiration date notification daemon 16 (#A) after the server machine 10 (#A) is set to the active system, only the notification of the expiration date to the jacket DLL 18 is given instead of the notification to the filter driver 14. Is different.

  That is, in the cluster system according to the present embodiment, first, the jacket DLL 19 (#A) of the server machine 10 (#A) waits for an I / O input from a host, such as the client 60 shown in FIG. S101). If the I / O input is an expiration date notification (S102: Yes), the process proceeds to step S103. If the I / O input is not an expiration date notification (S102: No), the process proceeds to step S104.

  In step S103, after updating to the notified expiration date, the process proceeds to step S115.

  In step S104, if the I / O input made in step S101 is read to the server A data area 32 (#A), go to step S105, if write, go to step S106, otherwise go to step S113. Proceed with each.

  In step S105, read is executed, and in step S106, write is executed, and the process proceeds to step S107.

  In step S107, when the jacket DLL 18 refers to the process handle management table 18a and the application for executing read or write is an application written in the process handle management table 18a (an application managed by the cluster software 12). Advances to the process of step S108, and otherwise proceeds to the process of step S111.

  In step S108, if the I / O is partially or wholly successful, the process proceeds to step S109. If not, the process proceeds to step S111.

  In step S109, the current time is acquired. In step S110, the expiration date is notified from the expiration date notification daemon 16 (#A), and it is determined whether or not the current time acquired in step S109 is within the expiration date. If it is within the expiration date, the I / O processing result is returned to the upper level as it is (S111), and then the process proceeds to step S115.

  On the other hand, if it is determined in step S110 that the expiration date has passed, the jacket DLL 18 returns an I / O process failure error to the upper level (S112), and then proceeds to the process of step S115.

  In step S113, the process is passed from the I / O processing DLL 19 (#A) to the disk driver 15 (#A) as it is, and in step S114, the return value from the disk driver 15 (#A) is returned to the upper level as it is. Then, the process proceeds to step S115.

  In step S115, if the OS ends, the process ends. If not, the process returns to step S101.

  As described above, in the cluster system according to the present embodiment, when the I / O processing result is returned to the upper layer by the above-described operation, the determination process using the expiration date is not performed unconditionally. This can be done only for application I / O under the management of the cluster software 12, and by sharing the disk data with the application not under the management of the cluster software 12, even if a failover occurs, the disk It is possible to achieve transaction matching while suppressing degradation of I / O performance.

  The best mode for carrying out the present invention has been described above with reference to the accompanying drawings, but the present invention is not limited to such a configuration. Within the scope of the invented technical idea of the scope of claims, a person skilled in the art can conceive of various changes and modifications. The technical scope of the present invention is also applicable to these changes and modifications. It is understood that it belongs to.

1 is a functional block diagram showing a configuration example of a cluster system according to a first embodiment. FIG. The conceptual diagram which shows the detailed structural example of a shared disk apparatus. The figure which shows the example of the means to acquire the present time. 6 is a flowchart showing a flow of processing by cluster software when a server machine is set as an active system in the cluster system according to the first embodiment. 5 is a flowchart showing a flow of processing by a filter driver after setting a server machine to an active system in the cluster system according to the first embodiment. The conceptual diagram which shows the flow of the process by a filter driver in the cluster system which concerns on 1st Embodiment. 5 is a flowchart showing a flow of processing by an expiration date notification daemon after setting a server machine to an active system in the cluster system according to the first embodiment. The flowchart which shows the flow of a process of the server machine at the time of detecting failover of a heartbeat and failing over in the cluster system which concerns on 1st Embodiment. The conceptual diagram which shows the flow of the process by the server machine at the time of failover in the cluster system which concerns on 1st Embodiment. The functional block diagram which shows the structural example of the cluster system which concerns on 2nd Embodiment. 9 is a flowchart showing a flow of processing by cluster software when a server machine is set as an active system in the cluster system according to the second embodiment. The flowchart which shows the flow of a process by the filter driver after setting a server machine to an active system in the cluster system which concerns on 2nd Embodiment. The conceptual diagram which shows the flow of the process by a filter driver in the cluster system which concerns on 2nd Embodiment. The flowchart which shows the flow of a process of the server machine at the time of detecting failover of a heartbeat and failing over in the cluster system which concerns on 2nd Embodiment. The conceptual diagram which shows the flow of a process by the server machine at the time of failover in the cluster system which concerns on 2nd Embodiment. The functional block diagram which shows the structural example of the cluster system which concerns on 3rd Embodiment. The figure which shows an example of a process handle management table. The flowchart which shows the flow of a process by the jacket DLL in the case of setting a server machine to an active system in the cluster system which concerns on 3rd Embodiment. The conceptual diagram which shows the flow of the process by jacket DLL in the cluster system which concerns on 3rd Embodiment. The conceptual diagram for demonstrating the failover by the cluster system of a prior art. The conceptual diagram for demonstrating the data destruction which arises at the time of failover by the cluster system of a prior art (at the time of mirroring disk apparatus use). The conceptual diagram for demonstrating the data destruction which arises at the time of failover by the cluster system of a prior art (when using a shared disk apparatus). The figure which shows the structural improvement example of the cluster system of a prior art, and the flow of a process by it (when using a shared disk apparatus). The figure which shows the example of an improved structure of the cluster system of a prior art, and the flow of a process by it (mirroring disk apparatus).

Explanation of symbols

  a ... heartbeat, b ... failover, 10 ... server machine, 11 ... application, 12 ... cluster software, 13 ... database server, 14 ... filter driver, 15 ... disk driver, 16 ... expiration date notification daemon, 17 ... mirroring daemon, 18 ... Jacket DLL, 18a ... Process handle management table, 19 ... I / O processing DLL, 20 ... Mirroring disk unit, 31 ... Shared disk unit, 32 ... Server A data area, 32 ... Server B data area, 33 ... Shared area, 33a ... Disk access right management table, 33b ... Mirroring error occurrence management table, 50, 52 ... Communication path, 51 ... FC cable, 60 ... Client, 61 ... DB client, 70 ... Common computer

Claims (1)

A cluster system composed of a plurality of server machines and a shared disk device shared and connected to the plurality of server machines,
The plurality of server machines include an application that runs on each of the plurality of server machines, cluster software that runs on each of the plurality of server machines, a filter driver that runs on each of the plurality of server machines, And an expiration notification daemon that runs on each server machine,
The shared disk device includes a server data area for storing data of the server machines, and a shared area shared by the server machines,
The shared area includes an access management unit that manages access information in which permission or non-permission of access to the shared disk device is set for each of the server machines,
The expiration date notification daemon periodically refers to the access information managed by the access management unit, and if access by the own server machine is permitted, the expiration date plus a predetermined time is added to the current time. Set and notify the filter driver of this server machine of this expiration date,
Each of the cluster software provided in the plurality of server machines communicates with each other periodically to check the survival state of each server machine, and has two types of states, an active system and a standby system,
When the cluster software becomes an active system, the cluster software changes the access information managed by the access management unit so that only the own server machine is permitted to access, and from the own server machine side. Make the server data area of the local server machine visible, start an application provided in the local server machine,
After the cluster software becomes active, the filter driver of the active server machine waits for I / O input, and if some or all of the processing results of the I / O input are successful, the current time If the current time is within the validity period notified from the validity period notification daemon, the processing result is returned to the I / O input side. If the current time is not within the validity period, the process result is returned to the I / O input side. Returns an error,
If the cluster software of the standby server machine determines that the active server machine is not alive, the cluster software of the standby server machine uses the access information managed by the access management unit. Is changed so that only the own server machine is allowed access, and after waiting for a predetermined time, the server data area of the own server machine is made visible from the own server machine side, and A cluster system in which the provided application is started.

Images