JP5002296B2 - Cluster system and program - Google Patents

Description

  The present invention relates to a cluster system and a program composed of a plurality of server machines and a shared disk device, and in particular, a cluster capable of matching data in the shared disk device even when a failover occurs. The present invention relates to a system and a program.

  For example, in the cluster system disclosed in Non-Patent Document 1, an active server machine 10 (#A) and a standby server machine 10 (#B) are provided as shown in FIG. The server machine 10 (#A) executes the application 11 (#A), and writes data as an execution result to the shared disk device 13 as shown in (i). Meanwhile, as shown in (ii), 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 14 to notify each other of their survival.

  When the standby server machine 10 (#B) detects the disconnection of the heartbeat a, as shown in (iii), the same application 11 (#B) is stored 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) The active server machine 10 (#A) is down.
(2) A failure of the communication path 14.
(3) Temporary slowdown due to high CPU load or the like in the active server machine 10 (#A).

  In the case of (1) above, failover b should simply be performed on the standby server machine 10 (#B), but in the cases (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. 16, when a cluster configuration is formed with a plurality of server machines 10 (#A, #B) connected to the same shared disk device 13, the above (2) and (3) When failover b is performed due to the interruption of the cause heartbeat a, as shown in FIG. 17, both the active server machine 10 (#A) and the standby server machine 10 (#B) are shared disks. There is a possibility of writing to the same data area 15 in the device 13, and in this case, the consistency of the data in the shared disk device 13 is lost, and the data may be destroyed.

  For this reason, some countermeasures against this inconvenience are taken even in the conventional cluster system. Two conventional technologies that have taken this measure are introduced below.

  The first prior art deals with the above (1) to (3), uses the reserve exclusive function defined as the SCSI specification, and uses one I / O (read or other) per LU (Logical Unit). The number of servers that can issue (write) is limited to one. That is, when a heartbeat a break is detected as shown in (i) of FIG. 18 and failover b is performed to the standby server machine 10 (#B) as shown in (ii), as shown in (iii) The standby server machine 10 (#B) reserves the target LU in the shared disk device 13, and the active server machine 10 (#A) writes more to the target LU as shown in (iv). Then, the application 11 (#B) is started, and writing to the shared disk device 13 is performed as shown in (v).

  The second prior art deals with the above (1) and (2). As shown in FIG. 19, a special LU called a QUARUM area 17 is provided in the shared disk device 13, and (iii) As shown in FIG. 6, by periodically writing the current time from the server machine 10 (#A, #B) constituting the cluster, the server machine 10 (#A, #B) other than the heartbeat a shown in (i). Monitor the status of #B).

According to the second prior art, even when the standby server machine 10 (#B) confirms the heartbeat a disconnection due to the failure of the communication path 14, the standby server machine 10 (#B) is QUIORUM. Reference area 17 is referred to. Since the QUARUM area 17 can be referred to even if there is a failure in the communication path 14, it can be confirmed that the active server machine 10 (#A) continues to write the current time, It can be known that the system server machine 10 (#A) is not down.
Toshiba Review Vol. 54 No. 12 (1999), pages 18-21

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

  First, in the case of the first prior art, whether or not reserve exclusion as shown in (iii) and (iv) of FIG. 18 is possible is determined by mounting the shared disk device 13 and its multipath driver (not shown). There is a problem that depends on. Therefore, in order to support the new shared disk device 13 and its multipath driver, it is necessary to verify each time. In addition, there is a tendency that fine restrictions are attached depending on the shared disk device 13 and its multipath driver. For example, in a certain shared disk device 13, if a one-path failure occurs in an environment where physical paths of disk I / O are multiplexed, the reserve is not maintained and cannot be excluded.

  In the case of the second prior art, for example, as shown in FIG. 20, when (i) the active server machine 10 (#A) falls into a high CPU load during write and slows down. (Ii) The standby server machine 10 (#B) detects that the heartbeat a has expired and thinks that the active server machine 10 (#A) has gone down, and (iii) performs failover b End up. Thus, (iv) the standby server machine 10 (#B) writes the current time in the QUIORUM area 17 and (v) writes data to the data area 15 in the application data area 18.

  On the other hand, since (vi) the active server machine 10 (#A) is not stopped, the current time is written in the QUIORUM area 17 in a slow-down state, and (vii) the application data area immediately after the return. Continue to write data to 18 data areas 15.

  In this way, immediately after the active server machine 10 (#A) recovers from the slowdown, there is a problem in that data is written to the same LU from both servers and data corruption may occur.

  The present invention has been made in view of such circumstances, and in a cluster system composed of a plurality of server machines and a shared disk device, reserved exclusive use is not required without depending on the implementation of the shared disk device and its multipath driver. Cluster system and program capable of matching data in a shared disk device without causing data corruption due to writing in a plurality of server machines even when failover occurs The purpose is to provide.

  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 including a plurality of server machines and a shared disk device connected to the plurality of server machines, and the plurality of server machines are respectively connected to the plurality of server machines. The shared disk device includes an application that operates, cluster software that operates on each of a plurality of server machines, and a filter driver that operates on each of the plurality of server machines. Each server area includes a server area for storing machine data and a common area shared by each server machine. Each server area includes a cache area and a patch area for storing data, and the common area includes a cache area. Copy permission for copying data stored in the area to the master area The cluster software provided in the multiple server machines communicates with each other periodically to check each other's survival status, and includes the commit right management unit that defines the server machines to which the server rights are granted. There are two types of states, active and standby.

  When the cluster software is active, the cluster software changes the commit right management unit so that the commit right is given only to the own server machine, and the master area is visible from the own server machine side. Start the application provided on the local server machine. Also, the filter driver provided in the own server machine waits for I / O input, and when the I / O input is a read request to the master area, part or all of the read request data is for the own server machine. Read from the cache area if there is any other read request data, read from the master area if there is any other read request data, return the read data to the I / O input side that requested the read, and the I / O input to the master area If there is no free space to write to the cache area for the local server machine and the commit right is granted to the local server machine, the cache area data is copied to the master area. Clear the cache area, and if the commit right is not granted to the local server machine, an error will be sent to the I / O input side that made the write request. Thereafter, the write position information and the written data in the master area are written in the cache area for the own server machine, and this write result is returned to the I / O input side that requested the write, and the I / O input is the master area. If the request is neither a read request nor a write request, the I / O input data is transferred to the lower side of the filter driver provided in the server machine, and the return value is returned to the I / O input side.

  On the other hand, if the cluster software is the standby system and the standby cluster software determines that the active cluster software is not alive, the determined cluster software changes the commit right management unit. The commit right is granted only to the local server machine, and the data in the cache area for the server machine equipped with the active cluster software is copied to the patch area for the local server machine, and the patch area becomes the master area. As an alternative, the master area can be seen from the server machine side, and the application provided on the server machine is started. The filter driver provided on the local server machine waits for I / O input after the cluster software provided on the local server machine becomes active, and the I / O input is a read request to the master area. If part or all of the read request data is in the patch area for the local server machine, it is read from the patch area, and if part or all of the read request data is in the cache area for the local server machine, the cache area is read. If there is any other read request data read from the master area, the read data is returned to the I / O input side that requested the read, and if the I / O input is a write request to the master area If all the write request destinations are in the patch area for the local server machine, write to the patch area and return to the I / O input side; otherwise, it corresponds to the patch area If there is no free space to write only the data to the patch area and write to the cache area for the local server machine, refer to the commit right management unit to check whether the commit right is granted to the local server machine. If it is assigned, the cache area data for the local server machine is copied to the master area to clear the cache area. If not assigned, an error is returned to the I / O input side, and then the write position information in the master area Are written in the cache area for the own server machine and returned to the I / O input side, and the I / O input is neither a read request nor a write request to the master area, it is prepared for the own server machine. The data by the I / O input is transferred to the lower layer of the received filter driver, and the return value is returned to the I / O input side.

  The invention of claim 2 is a program applied to the cluster system of the invention of claim 1.

  According to a third aspect of the present invention, in the program of the third aspect, each filter driver has a memory cache area having the same data as the cache area of the own server machine, and refers to the cache area for the own server machine. Instead of referring to the memory cache area for the own server machine and writing the write position information and the written data in the master area to the cache area for the own server machine, the memory cache area and the cache area for the own server machine are stored. This is a program for copying data in the memory cache area to the master area instead of copying data in the write / cache area to the master area.

  According to the present invention, in a cluster system composed of a plurality of server machines and a shared disk device, reserve exclusion is possible without depending on the implementation of the shared disk device and its multipath driver, and failover occurs. Even in this case, it is possible to realize a cluster system and a program capable of matching data in the shared disk device without causing data corruption due to writing in a plurality of server machines.

  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. 16 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 the shared disk device 13 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). And a filter driver 21 (#A, #B) and a disk driver 22 (#A, #B). The filter driver 21 is provided between the application 11 and the disk driver 22. 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 13 is connected to each server machine 10 (#A, #B) via an FC (Fiber Channel) cable 23 (#A, #B), and includes a QUIORUM area 17 and a master area 30. ing. Each may be divided into different LUs or may be divided into different partitions.

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

  As shown in FIG. 2, the QUARUM area 17 includes three areas: a common area 170, a server A area 171, and a server B area 172. Further, the common area 170 includes a commit right management table 170a, the server A area 171 includes a cache area 171a and a patch area 171b, and the server B area 172 includes a cache area 172a and a patch area 172b.

  The cache area 171a is an area where data is written from the application 11 (#A) of the server machine 10 (#A) via the FC cable 23 (#A). Similarly, the cache area 172a is an area where data is written from the application 11 (#B) of the server machine 10 (#B) via the FC cable 23 (#B).

  The commit right management table 170a defines the server machine 10 to which the commit right that is permission to copy the data stored in the cache areas 171a and 172a to the master area 30 is given. FIG. 2 shows an example in which the commit right is given to the server machine 10 (#A) and the commit right is not given to the server machine 10 (#B).

  The master area 30 is an area for moving data written to the cache areas 171a and 172a when the data written to the cache areas 171a and 172a is full. When the cache areas 171a and 172a are full, the migration is performed by the server machine 10 having the commit right, that is, the filter driver 21 of the server machine 10 defined as “with commit” in the commit right management table 170a. , Starting by committing to the master area 30.

  In such a cluster system according to the present embodiment, the cluster software 12 (#A, #B) regularly communicate with each other to check the survival state of each other's server machine 10, and each operating system And 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.

  In this way, the cluster software 12 (#A) that is the active system sets the commit right management table 170a so that the commit right is given only to the own server machine 10 (#A), and the own server that is the upper side The master area 30 can be seen from the machine 10 (#A) side, and the application 11 (#A) provided in the server machine 10 (#A) is started.

  The filter driver 21 (#A) provided in the server machine 10 (#A) waits for I / O input from the host, and if the I / O input is read to the master area 30, the read data If part or all of the data is in the cache area 171a for the server machine 10 (#A), it is read from the cache area 171a, and if there is any other read data, it is read from the master area 30, and the read data is read from the I / O Return all data to the input side.

  Further, this is a case where the I / O input is a write to the master area 30, and there is no free space for writing to the cache area 171a for the own server machine 10 (#A), and the own server machine 10 (#A) If the commit right is granted, the data in the cache area 171a is copied to the master area 30 and the cache area 171a is cleared. On the other hand, if the commit right is not given to the own server machine 10 (#A), an error is returned to the I / O input side that made the write request, and thereafter, as shown in the data table 171c of FIG. Write position information (start position, length) in the master area 30 and the written data are written to the cache area 171a for the own server machine 10 (#A), and the write result is sent to the I / O input side that has issued the write request. return.

  On the other hand, when the I / O input is neither read nor write to the master area 30, the disk driver 22 (on the lower side of the filter driver 21 (#A) provided in the own server machine 10 (#A) ( The data by I / O input is transferred to #A) as it is, and the return value is returned to the I / O input side as it is.

  Next, standby cluster software 12 (#B) and filter driver 21 (#B) will be described.

  If the standby cluster software 12 (#B) determines that the active cluster software 12 (#A) is not alive, that is, is not operating, it changes the commit right management table 170a to The commit right is given only to the server machine 10 (#B). Then, the data in the cache area 171a for the server machine 10 (#A) is copied to the patch area 172b for the own server machine 10 (#B), the patch area 172b is used as a part of the master area 30, and the own server The master area 30 is made visible from the machine 10 (#B) side, and the application 11 (#B) provided in the own server machine 10 (#B) is activated.

  The filter driver 21 (#B) provided on the own server machine 10 (#B) starts from the upper level after the cluster software 12 (#B) provided on the server machine 10 (#B) becomes an active system. Wait for I / O input. If this I / O input is read to the master area 30, if part or all of the read data is in the patch area 172b for the own server machine 10 (#B), it is read from the patch area 172b, If some or all of the read data is in the cache area 172a, it is read. If there is other read data, it is read from the master area 30, and the read data is collectively returned to the I / O input side that requested read.

  If the I / O input is a write to the master area 30, if all the write destinations are in the patch area 172b for the own server machine 10 (#B), the I / O input is written to the patch area 172b. Return to the side. Otherwise, only the data corresponding to the patch area 172b is written to the patch area 172b, and if there is no free space for writing data to the cache area 172a for the own server machine 10 (#B), the commit right management table 170a is stored. It is confirmed whether or not the commit right is given to the own server machine 10 (#B).

  As a result of the confirmation, if the commit right is given, the data in the cache area 172a for the own server machine 10 (#B) is copied to the master area 30 to clear the cache area 172a. On the other hand, if the commit right is not given, an error is returned to the I / O input side, and then the write position information (start position, length) in the master area 30 and the written data are shown in the data table 171c of FIG. As shown in FIG. 4, the data is written in the cache area 172a for the local server machine 10 (#B) and returned to the I / O input side.

  On the other hand, when the I / O input is neither read nor write to the master area 30, the disk driver 22 (#) which is a lower layer of the filter driver 21 (#B) provided in the server machine 10 (#B). B) The data by the I / O input is transferred as it is, and the return value is returned to the I / O input side as it is.

  Each server machine 10 manages whether each server machine 10 has a patch area (171b or 172b) to be copied to the master area 30. Further, when the cluster software 12 becomes active, all the patch areas (171b or 172b) to be copied to the master area 30 may be copied to the master area 30 based on the management result.

  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) and the QUIORUM area 107 and the master area 30 are not visible from the upper layer (the filter driver is fence-off), and the server machine 10 (#A, #B ) Both applications 11 (#A, #B) are not 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. 3 and the conceptual diagram 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 commit right management table 170a is set by the cluster software 12 (#A) so that the commit right is given to the server machine 10 (#A) (S2). Then, the cluster software 12 (#A) notifies the filter driver 21 (#A) that it has become an active system (S3). Thereafter, the master area 30 is made visible from the upper layer by the filter driver 21 (#A) of the server machine 10 (#A) (S4). Then, the application 11 (#A) is activated by the cluster software 12 (#A) of the server machine 10 (#A) (S5).

  Next, the flow of processing by the filter driver 21 (#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 21 (#A) of the server machine 10 (#A) waits for an I / O input from the host (S11). When an I / O input is made, the type of the made I / O input is determined (S12). If the I / O input made is read to the master area 30, the process proceeds to step S13, if it is write, the process proceeds to step S19, and if not, the process proceeds to step S26.

  In step S13, if part or all of the read destination data is in the cache area 171a, the corresponding data in the cache area 171a is read (S14), and the process proceeds to step S15. If there is no read destination data in the cache area 171a, the process of step S14 is skipped and the process proceeds to step S15.

  In step S15, if some or all of the read destination data is not in the cache area 171a, only the remaining data is read from the master area 30 (S16), and the process proceeds to step S17. Otherwise, the process of step S16 is skipped and the process proceeds to step S17.

  In step S17, the read data is merged into one and returned to the upper level of the read request source (S17), and the process proceeds to step S18.

  In step S18, if the OS ends, the process ends. Otherwise, the process returns to step S11 (S18).

  In step S19, it is determined whether there is enough free space in the cache area 171a (S19). If it is determined that there is enough free space to write, in step S20, the filter driver 21 (#A) of the server machine 10 (#A) writes the write start address and length on the shared disk device 13. The three raw data are written into the cache area 171a of the server machine 10 (#A) (S20) and returned to the upper level (S21). Thereafter, the process proceeds to step S18.

  On the other hand, if it is determined in step S19 that the cache area 171a does not have enough free space to write, the commit right management table 170a is referred to in step S22, and the commit right is assigned to the server machine 10 (#A). It is confirmed whether it is given (S22).

  If the commit right is given to the server machine 10 (#A), the process proceeds to step S23, and the filter driver 21 (#A) of the server machine 10 (#A) performs the commit (from the cache area 171a to the master area 30). (Reflect) is performed (S23).

  Next, the filter driver 21 (#A) of the server machine 10 (#A) deletes the committed cache from the cache area 171a (S24), and proceeds to the process of step S20.

  On the other hand, if the commit right is not given to the server machine 10 (#A) in step S22, the process proceeds to step S25, and the filter driver 21 (#A) returns an error to the upper level (S25), and then the step is performed. The process proceeds to S18.

  In step S26, the process is transferred to the disk driver 22 (#A) as it is, and then in step S27, the return value is returned to the upper level as it is, and the process proceeds to step S18.

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

  First, the cluster software 12 (#B) of the server machine 10 (#B) is slowed down during the write by the cluster software 12 (#A) of the server machine 10 (#A) as indicated by X in FIG. Or when the hard beat is detected by slowing down during commit as shown by Y in FIG. 7 (S31), the commit right management is performed so that the commit right is given to the server machine 10 (#B). The table 170a is set (S32). In any case, the slow-down cluster software 12 (#A) is assumed to return after a while.

  Next, the cluster software 12 (#B) stores all data in the cache area 171a for the server machine 10 (#A) (including data before or during commit) in the patch area of the server machine 10 (#B). Copy to 172b (S33).

  Then, the cluster software 12 (#B) notifies the filter driver 21 (#B) that the server machine 10 (#B) has become an active system (S34). Thereafter, the master area 30 is made visible from the upper layer by the filter driver 21 (#B) of the server machine 10 (#B) (S35). Then, the application 11 (#B) is activated by the cluster software 12 (#B) of the server machine 10 (#B) (S36).

  Next, the flow of processing by the filter driver 21 (#B) after failover to the server machine 10 (#B) will be described using the flowchart of FIG. 8 and the conceptual diagram shown in FIG.

  First, the filter driver 21 (#B) of the server machine 10 (#B) waits for an I / O input from the host (S41). When an I / O input is made, the type of the made I / O input is determined (S42). If the I / O input made is read to the master area 30, the process proceeds to step S43, if it is write, the process proceeds to step S51, and if not, the process proceeds to step S61.

  In step S43, if part or all of the read destination data is in the patch area 172b, the corresponding data on the patch area 172b is read (S44), and the process proceeds to step S45. If there is no read destination data in the patch area 172b, the process of step S44 is skipped and the process proceeds to step S45.

  In step S45, if part or all of the read destination data is in the cache area 172a, the corresponding data in the cache area 172a is read (S46), and the process proceeds to step S47. Otherwise, the process of step S46 is skipped and the process proceeds to step S47.

  In step S47, if part or all of the read destination data is not in the patch area 172b or the cache area 172a, only the remaining data is read from the master area 30 (S48), and the process proceeds to step S49. . Otherwise, the process of step S48 is skipped and the process proceeds to step S49.

  In step S49, the read data is merged into one and returned to the upper level of the read request source (S49), and the process proceeds to step S50.

  In step S50, if the OS ends, the process ends. If not, the process returns to step S41 (S18).

  In step S51, if part or all of the write destination is on the patch area 172b, the process proceeds to step S52, the corresponding data is written to the patch area 172b (S52), and the process proceeds to step S53.

  In step S53, if all of the write destinations are the patch area 172b, the process proceeds to step S56, and after the result is returned to the upper level, the process proceeds to step S50. On the other hand, if the entire write destination is not the patch area 172b, the process proceeds to step S54.

  In step S54, it is determined whether there is enough free space in the cache area 172a (S54). If it is determined that there is enough free space to write, in step S55, the filter driver 21 (#B) of the server machine 10 (#B) writes the write start address and length on the shared disk device 13. The three raw data are written to the cache area 172a of the server machine 10 (#B) (S55) and returned to the upper level (S56). Thereafter, the process proceeds to step S50.

  On the other hand, if it is determined in step S54 that the cache area 172a does not have enough free space to write, the commit right management table 170a is referred to in step S57, and the commit right is given to the server machine 10 (#B). It is confirmed whether it is given (S57).

  If the commit right is given to the server machine 10 (#B), the process proceeds to step S58, and the filter driver 21 (#B) of the server machine 10 (#B) commits (transfers from the cache area 172a to the master area 30). (Reflect) is performed (S58).

  Next, the filter driver 21 (#B) of the server machine 10 (#B) deletes the committed cache from the cache area 172a (S59), and proceeds to the process of step S55.

  On the other hand, if the commit right is not given to the server machine 10 (#B) in step S57, the process proceeds to step S60, and the filter driver 21 (#B) returns an error to the upper level (S60), and then the step is performed. The process proceeds to S50.

  In step S61, the process is transferred to the disk driver 22 (#B) as it is, and then in step S62, the return value is returned as it is to the upper level, and the process proceeds to step S50.

  As described above, in the cluster system according to the present embodiment, sharing is performed in the cluster system configured by the plurality of server machines 10 (#A, #B) and the shared disk device 13 by the operation as described above. Reserve exclusion is possible without depending on the implementation of the disk device 13 or its multipath driver.

  In addition, even when a failover occurs for any reason such as a down or slowdown of the active server machine 10 (#A) or a failure of the communication path 14, a plurality of server machines 10 (#A, # The data in the shared disk device 13 can be matched without causing data corruption due to redundant writing in B). In addition, the server A area 171 and the server B area 172 for application data need not be increased as compared with the normal case, and the amount of data to be copied at the time of failover can be reduced, so that a quick failover is possible. It becomes.

  Each server machine 10 manages whether each server machine 10 has a patch area (171b or 172b) to be copied to the master area 30. Further, when the cluster software 12 becomes an active system, all the data of the patch area (171b or 172b) to be copied to the master area 30 can be copied to the master area 30 based on this management result. Even when the status of the original active server machine 10 (#A) cannot be confirmed (down / slowdown / survival) and the new active server machine 10 (#B) having the patch area 172b is stopped It is possible to avoid the risk of breaking the consistency of application data.

(Second Embodiment)
FIG. 9 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, in the cluster system according to the present embodiment, each server machine 10 (#A, #B) further includes a commit thread 24 (#A, #B) and a memory cache area 25 ( #A, #B). Both the commit thread 24 and the memory cache area 25 are provided in the filter driver 21.

  In addition, the shared disk device 13 includes a QUIORUM file 31 in the master area 30 instead of eliminating the QUARUM area 17 shown in FIG. Furthermore, as shown in FIG. 10, the QUIORUM file 31 includes a common area 170 including a commit right management table 170a and a patch area holding state management table 170b, and a server A area 171 including a cache area 171a and a patch area 171b. A server B area 172 including a cache area 172a and a patch area 172b.

  The patch area holding state management table 170b manages information indicating whether or not each server machine 10 (#A, #B) holds data to be reflected in the master area 30 in the patch areas 171b and 172b.

  Data written from the application 11 (#A) of the server machine 10 (#A) via the filter driver 21 (#A) is written in the memory cache area 25 (#A). The same data is also written to the cache area 171a in the server A area 171 via the FC cable 23 (#A).

  Similarly, data written from the application 11 (#B) of the server machine 10 (#B) via the filter driver 21 (#B) is written in the memory cache area 25 (#B). The same data is also written to the cache area 172a in the server B area 172 via the FC cable 23 (#B).

  As a result, each filter driver 21 (#A, #B) creates a memory cache area 25 (#A, #B) having the same data as the cache areas 171a, 172a of each server machine 10 (#A, #B). Each will be prepared.

  When the commit right is given to the own server machine 10, the commit thread 24 transfers the data in the cache area (171 a or 172 a) for the own server machine 10 to the master area 30 directly or via the filter driver 21. Make copies regularly.

  In such a cluster system according to the present embodiment, the filter driver 21 of the cluster system according to the first embodiment instead of referring to the cache area (171a or 172a) for the own server machine 10 The memory cache area 25 for the machine 10 is referred to. Further, instead of writing the write position information and the written data in the master area 30 into the data table (171c or 172c) in the cache area (171a or 172a) for the own server machine 10, a memory cache for the own server machine 10 is used. Write to the area 25 and the cache area (171a or 172a). Further, instead of copying the data in the cache area (171a or 172a) to the master area 30, the data in the memory cache area 25 is copied to the master area 30.

  Next, the operation of the cluster system according to this embodiment configured as described above will be described.

  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 received by the user operation to the cluster software 12 (#A) of the server machine 10 (#A) (S71). Next, the commit right management table 170a is set by the cluster software 12 (#A) so that the commit right is given to the server machine 10 (#A) (S72). Then, the cluster software 12 (#A) notifies the filter driver 21 (#A) that it has become an active system (S73). Then, the filter driver 21 (#A) refers to the patch area holding state management table 170b, and the contents of the designated patch area (171b or 172b) of the server machine 10 are reflected in the master area 30 (S74). .

  Thereafter, the master area 30 is made visible from the upper layer by the filter driver 21 (#A) of the server machine 10 (#A) (S75). Then, the commit thread 24 (#A) is started by the filter driver 21 (#A) of the server machine 10 (#A) (S76), and the cluster software 12 (#A) of the server machine 10 (#A) The application 11 (#A) is activated (S77).

  Next, the flow of processing by the commit thread 24 (#A) after setting the server machine 10 (#A) to the active system will be described using the flowchart of FIG.

  After the server machine 10 (#A) is set to the active system, the commit thread 24 (#A) issues a commit execution command to the filter driver 21 (#A) (S81). If the commit is continued continuously, the load of the server machine 10 (#A) is always 100%, and there is a possibility that there is no room for other processing. In order to avoid this, after step S81, for example, sleep is performed for 10 seconds (S82). As a result, the cache area 171a is not filled up, for example for 10 seconds, and the commit is continued (S83).

  Next, the flow of processing by the filter driver 21 (#A) after setting the server machine 10 (#A) to the active system will be described using the flowchart of FIG.

  First, the filter driver 21 (#A) of the server machine 10 (#A) waits for an I / O input from the host (S91). If the I / O input made is a commit execution instruction, the process proceeds to step S93. If the input is not a commit execution instruction, the process proceeds to step S100.

  In step S93, the commit right management table 170a is referred to and it is confirmed whether or not the commit right is given to the server machine 10 (#A). If the commit right is given to the server machine 10 (#A), in step S94, lock is a process that blocks the application 11 (#A) so that a read / write command is not issued at the time of commit. Is acquired by the commit thread 24 (#A).

  Then, the memory cache area 25 (#A) is referred to by the filter driver 21 (#A), and after committing the range to be committed (S95), the commit, that is, from the memory cache area 25 (#A) to the master area 30 is performed. Reflection is performed (S96). Then, after the committed cache is deleted from the memory cache area 25 (#A) and the cache area 171a (S97), the lock acquired in step S93 is released (S98). Thereafter, the process proceeds to step S120.

  In step S120, if the OS ends, the process ends. If not, the process returns to step S91 (S120).

  On the other hand, if the commit right is not granted to the server machine 10 (#A) in step S93, an error is returned to the upper level by the filter driver 21 (#A) (S99), and then the process of step S120 is performed. move on.

  In step S100, the type of I / O input made in step S91 is determined (S100). If the I / O input made is read to the master area 30, the process proceeds to step S101. If it is write, the process proceeds to step S109. Otherwise, the process proceeds to step S118.

  In step S101, the application 11 (#A) acquires a lock, which is a process for blocking the commit thread 24 (#A) so as not to issue a commit command during read (S101). If part or all of the read destination data is in the memory cache area 25 (#A) (S102), the corresponding data in the memory cache area 25 (#A) is read (S103), and the process of step S104 is performed. move on. If there is no read destination data in the memory cache area 25 (#A), the process of step S103 is skipped and the process proceeds to step S104.

  In step S104, if some or all of the read destination data is not in the cache area 171a, only the remaining data is read from the master area 30 (S105), and the process proceeds to step S106. Otherwise, the process of step S105 is skipped and the process proceeds to step S106.

  In step S106, the lock acquired in step S101 is released, and then the read data is merged into one and returned to the upper level of the read request source (S107), and the process proceeds to step S120.

  In step S109, the application 11 (#A) acquires a lock that is a process for blocking the commit thread 24 (#A) so as not to issue a commit instruction during write. Then, it is determined whether the memory cache area 25 (#A) has enough free space for writing (S110). If it is determined that there is enough free space to write, in step S111, the filter driver 21 (#A) of the server machine 10 (#A) writes the write start address and length on the shared disk device 13. Three pieces of raw data are written into the memory cache area 25 (#A) and the data table 171c of the cache area 171a of the server machine 10 (#A) (S111), and the lock acquired in step S109 is released (S112). ) Later, the data written in step S111 is returned to the upper level (S113). Thereafter, the process proceeds to step S120.

  On the other hand, if it is determined in step S110 that the cache area 171a does not have enough free space to write, the lock acquired in step S109 is released (S114), and in step S115, the filter driver 21 (#A ) Issues a commit execution command (S115). If the commit execution instruction is successful, the process returns to step S109. If the commit execution instruction is not successful, an error is returned to the upper level by the filter driver 21 (#A) (S117), and the process proceeds to step S120.

  In step S118, the process is transferred to the disk driver 22 (#A) as it is, and then in step S119, the return value is returned to the upper level as it is, and the process proceeds to step S120.

  Next, the flow of processing by the cluster software 12 (#B) of the server machine 10 (#B) when the server machine 10 (#B) detects a heartbeat break and fails over using the flowchart shown in FIG. Will be explained.

  First, the cluster software 12 (#B) of the server machine 10 (#B) is slowed down during the write by the cluster software 12 (#A) of the server machine 10 (#A) as indicated by X in FIG. If the hard beat is detected by slowing down during commit as shown by Y in FIG. 7 (S131), the cluster software 12 (#B) gives the commit right to the server machine 10 (#B). Is set such that the commit right management table 170a is assigned (S132). In any case, the slow-down cluster software 12 (#A) is assumed to return after a while.

  Next, the cluster software 12 (#B) stores all data in the cache area 171a for the server machine 10 (#A) (including data before or during commit) in the patch area of the server machine 10 (#B). It is copied to 172b (S133).

  Then, the cluster software 12 (#B) changes the patch area holding state management table 170b so that the patch area holding state of the server machine 10 (#B) is designated (S134).

  Next, the cluster software 12 (#B) notifies the filter driver 21 (#B) that the server machine 10 (#B) has become an active system (S135). Thereafter, the master area 30 is made visible from the upper layer by the filter driver 21 (#B) of the server machine 10 (#B) (S136). Then, the commit thread 24 (#B) is activated by the cluster software 12 (#B) of the server machine 10 (#B) (S137), and then the application 11 (#B) is activated (S138).

  Next, the flow of processing by the filter driver 21 (#B) after failover to the server machine 10 (#B) will be described using the flowchart of FIG.

  First, the filter driver 21 (#B) of the server machine 10 (#B) waits for an I / O input from the host (S141). If this I / O input is a commit execution instruction, the process proceeds to step S143. If not, the process proceeds to step S150 (S142).

  In step S143, the commit right management table 170a is referred to, and it is confirmed whether the commit right is given to the server machine 10 (#B). If the commit right is given to the server machine 10 (#B), in step S144, lock is a process that blocks the application 11 (#B) so as not to issue a read / write command at the time of commit. Is acquired by the commit thread 24 (#B).

  Then, the memory cache area 25 (#B) is referred to by the filter driver 21 (#B), and after the range to be committed is determined (S145), the commit, that is, from the memory cache area 25 (#B) to the master area 30 is performed. Reflection is performed (S146). Then, after the committed cache is deleted from the memory cache area 25 (#B) and the cache area 172a (S147), the lock acquired in step S143 is released (S148). Thereafter, the process proceeds to step S174.

  In step S174, if the OS ends, the process ends. If not, the process returns to step S141 (S174).

  On the other hand, if the commit right is not granted to the server machine 10 (#B) in step S143, an error is returned to the upper level by the filter driver 21 (#B) (S149), and then the process of step S174 is performed. move on.

  In step S150, the type of I / O input made in step S141 is determined (S50). If the I / O input made is read to the master area 30, the process proceeds to step S151. If it is write, the process proceeds to step S160. Otherwise, the process proceeds to step S172.

  In step S151, if part or all of the read destination data is in the patch area 172b, the corresponding data on the patch area 172b is read (S152), and the process proceeds to step S153. If there is no read destination data in the patch area 172b, the process of step S152 is skipped and the process proceeds to step S153.

  In step S153, the application 11 (#B) acquires a lock that is a process for blocking the commit thread 24 (#B) so as not to issue a commit command during read (S153). If part or all of the read destination data is in the memory cache area 25 (#B) (S154), the corresponding data in the memory cache area 25 (#B) is read (S155), and the process of step S156 is performed. move on. If there is no read destination data in the memory cache area 25 (#B), the process of step S155 is skipped and the process proceeds to step S156.

  In step S156, if part or all of the read destination data is not in the cache area 172a or the patch area 172b, only the remaining data is read from the master area 30 (S157), and the process proceeds to step S158. . Otherwise, the process of step S157 is skipped and the process proceeds to step S158.

  In step S158, the lock acquired in step S153 is released, and then the read data is merged into one and returned to the upper level of the read request source (S159), and the process proceeds to step S174.

  In step S160, if part or all of the write destination is on the patch area 172b, the process proceeds to step S161, the corresponding data is written to the patch area 172b (S161), and the process proceeds to step S162.

  In step S162, if all of the write destinations are the patch area 172b, the process proceeds to step S167, and after the result is returned to the upper level, the process proceeds to step S174. On the other hand, if not all of the write destinations are the patch area 172b, the process proceeds to step S163.

  In step S163, the application 11 (#B) acquires a lock that is a process for blocking the commit thread 24 (#B) so as not to issue a commit instruction during write. Then, it is determined whether the memory cache area 25 (#B) has enough free capacity to write (S164). If it is determined that there is enough free space to write, in step S165, the filter driver 21 (#B) of the server machine 10 (#B) writes the write start address and length on the shared disk device 13. , Three of the raw data are written into the memory cache area 25 (#B) and the cache area 172a of the server machine 10 (#B) (S165), and after the lock acquired in step S163 is released (S166), the step The data written in S165 is returned to the upper level (S167). Thereafter, the process proceeds to step S174.

  On the other hand, if it is determined in step S164 that there is not enough free space in the cache area 172a, the lock acquired in step S163 is released (S168), and in step S169, the filter driver 21 (#B ) Issues a commit execution command (S169). If the commit execution instruction is successful, the process returns to step S163. If the commit execution instruction is not successful, an error is returned to the upper level by the filter driver 21 (#B) (S171), and the process proceeds to step S174.

  In step S172, the process is passed to the disk driver 22 (#B) as it is, and then in step S173, the return value is returned as it is to the upper level, and the process proceeds to step S174.

  The processing flow by the commit thread 24 (#B) after failing over to the server machine 10 (#B) is the server machine 10 (#A) and the filter driver 21 (#A) shown in the flowchart of FIG. The commit thread 24 (#A) and the cache area 171a are the same as the server machine 10 (#B), the filter driver 21 (#B), the commit thread 24 (#B), and the cache area 172a. is there.

  As described above, in the cluster system according to the present embodiment, the common area 170, the server A area 171 and the server B area 172 are provided in the master area 30, so that a new special LU or partition is newly created. For example, it is possible to easily apply to a cluster system that is already in operation.

  When the filter driver 21 commits, for example, in the configuration as in the first embodiment, for the read of data from the cache area (171a or 172a) and the write of data to the master area 30 Although two disk accesses were required, according to the present embodiment, the number of disk accesses is reduced, so the load on the shared disk device 13 is reduced, and higher-speed processing is performed for I / O from higher-level applications. Is possible.

  Furthermore, in the cluster system according to the present embodiment, the commit thread 24, when the commit right is given to the own server machine 10, directly or via the filter driver 21, the cache area for the own server machine 10 ( Since the data of 171a or 172a) is periodically copied to the master area 30, the process of copying the data of the cache area (171a or 172a) to the master area 30 is performed in parallel with the process for normal I / O input. Therefore, it is possible to prevent I / O delay from the host application and increase the speed.

  Furthermore, since the cluster system according to the present embodiment includes the patch area holding state management table 170b for managing the patch area holding state, the master area 30 can be referred to by referring to the patch area holding state management table 170b. It can be ascertained whether each server machine 10 (#A, #B) has a patch area (171b or 172b) to be reflected. Therefore, for example, even when it is desired to stop the server machine 10 (#B), the state of the server machine 10 (#A) can be confirmed, and the necessary reflection from the patch area 171b to the master area 30 is forgotten. It is possible to avoid redundant writing by both the server machine 10 (#A) and the server machine 10 (#B), and to reliably reflect the patch area (171b or 172b) in the corresponding area of the master area 30. Become.

  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 the shared disk apparatus in 2nd Embodiment. The flowchart which shows the flow of a process by cluster software in setting a server machine to an active system. The conceptual diagram which shows the flow of a process by the cluster software in the case of setting a server machine to an active system, and the filter driver after a setting. The flowchart which shows the flow of a process by the filter driver after setting a server machine to an active system. The flowchart which shows the flow of a process by the cluster software of a server machine when a server machine detects heartbeat expiration and fails over. The conceptual diagram which shows the flow of the process by the cluster software of the server machine when a server machine detects heartbeat expiration, and fails over, and the process by the filter driver after a failover to the server machine. The flowchart which shows the flow of a process by the filter driver after failover to a server machine. The functional block diagram which shows the structural example of the cluster system which concerns on 2nd Embodiment. The conceptual diagram which shows the detailed structural example of the shared disk apparatus in 2nd Embodiment. The flowchart which shows the flow of a process by cluster software in setting a server machine to an active system. The flowchart which shows the flow of a process by the commit thread after setting a server machine to an active system. The flowchart which shows the flow of a process by the filter driver after setting a server machine to an active system. The flowchart which shows the flow of a process by the cluster software when a server machine detects a heartbeat break and fails over. The flowchart which shows the flow of a process by the filter driver after failover to a server machine. 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. The conceptual diagram for demonstrating the failover by the cluster system of the prior art using a reserve exclusive function. The conceptual diagram for demonstrating the failover by the cluster system of the prior art using QUIORUM. The conceptual diagram for demonstrating the data destruction which arises at the time of the failover by the cluster system of the prior art using QUIORUM.

Explanation of symbols

  a ... heartbeat, b ... failover, 10 ... server machine, 11 ... application, 12 ... cluster software, 13 ... shared disk device, 14 ... communication path, 15 ... data area, 17 ... QUIORUM area, 18 ... application data Area, 21 ... filter driver, 22 ... disk driver, 23 ... FC cable, 24 ... commit thread, 25 ... memory cache area, 30 ... master area, 31 ... QUIORUM file, 107 ... QUARUUM area, 170 ... common area, 170a ... Commit right management table, 170b ... Patch area holding state management table, 171 ... Server A area, 171a, 172a ... Cache area, 171b, 172b ... Patch area, 171c ... Data table, 172 ... Server B area

Claims (3)

A cluster system composed of a plurality of server machines and a shared disk device 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, and a filter driver that runs on each of the plurality of server machines,
The shared disk device includes a master area for storing data of the application, an area for each server for storing data of each server machine, and a common area shared by each server machine,
Each server area includes a cache area and a patch area for storing data, respectively.
The common area includes a commit right management unit that defines a server machine to which a commit right that is permission to copy data stored in the cache area to the master area is provided,
Each cluster software provided in the plurality of server machines communicates with each other periodically to check each other's survival state, and each has two types of states, an active system and a standby system,
If the cluster software is active,
The cluster software changes the commit right management unit so that only the own server machine is given the commit right, makes the master area visible from the own server machine side, and is provided in the own server machine. Start the application
The filter driver provided in the own server machine waits for I / O input, and when the I / O input is a read request to the master area, part or all of the read request data is the own server machine. If there is another read request data, it reads from the cache area, and if there is any other read request data, it reads from the master area, and returns the read data to the I / O input side that has made the read request. If / O input is a write request to the master area, if there is no free space to write to the cache area for the own server machine and the commit right is granted to the own server machine, The cache area is copied to the master area, the cache area is cleared, and the commit right is not granted to the local server machine If this is the case, an error is returned to the I / O input side that made the write request, and then the write position information in the master area and the written data are written into the cache area for the local server machine, and the write result is written to the write area. If the I / O input is neither a read request nor a write request for the master area, the I / O input is sent to the lower side of the filter driver provided in the server machine. Pass data by I / O input, and return the return value to the I / O input side,
When the cluster software is a standby system and the standby cluster software determines that the active cluster software is not alive,
The determined cluster software changes the commit right management unit so that the commit right is given only to the own server machine, and the cache area data for the server machine provided with the active cluster software is stored. Copy to the patch area for the local server machine, substitute the patch area as a part of the master area, make the master area visible from the local server machine side, and start the application provided on the local server machine ,
The filter driver provided on the local server machine waits for I / O input after the cluster software provided on the local server machine becomes active, and the I / O input is read into the master area. If it is a request, if part or all of the read request data is in the patch area for the local server machine, it is read from the patch area, and part or all of the read request data is in the cache area for the local server machine. Read from the cache area, if there is any other read request data, read from the master area, return the read data to the I / O input side that requested the read, and the I / O input to the master area If it is a write request, if all of the write request destinations are in the patch area for the local server machine, the write request is written in the patch area and the I / O input side If not, only the data corresponding to the patch area is written to the patch area, and if there is no free space to write to the cache area for the own server machine, refer to the commit right management unit and refer to the own server machine. Whether or not the commit right is granted to the master area, the cache area data for the local server machine is copied to the master area to clear the cache area, and if not granted, the I An error is returned to the / O input side, and then the write position information and the written data in the master area are written to the cache area for the own server machine, returned to the I / O input side, and the I / O input is If the request is neither a read request nor a write request to the master area, the filter driver provided in the local server machine is used. Cluster system adapted delivers the data by the I / O input to the lower layer of the server, and returns the return value to the I / O input. A program applied to a cluster system composed of a plurality of server machines and a shared disk device 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, and a filter driver that runs on each of the plurality of server machines,
The shared disk device includes a master area for storing data of the application, an area for each server for storing data of each server machine, and a common area shared by each server machine,
Each server area includes a cache area and a patch area for storing data, respectively.
The common area includes a commit right management unit that defines a server machine to which a commit right that is permission to copy data stored in the cache area to the master area is provided,
Each cluster software provided in the plurality of server machines communicates with each other periodically to check each other's survival state, and each has two types of states, an active system and a standby system,
When the cluster software is active, the program is
The cluster software changes the commit right management unit so that only the own server machine is granted the commit right, makes the master area visible from the own server machine side, and is provided in the own server machine. A function to start
The filter driver provided in the own server machine waits for I / O input, and when the I / O input is a read request to the master area, the cache area for the own server machine is referred to, If some or all of the read request data is in the cache area for its own server machine, it is read from the cache area, and if there is any other read request data, it is read from the master area. The I / O input is returned to the I / O input side, and the I / O input is a write request to the master area, and there is no free space for writing to the cache area for the own server machine. If the commit right is granted, the cache area is cleared by copying the data in the cache area to the master area. If the commit right is not given to the own server machine, an error is returned to the I / O input side that made the write request, and then the write position information in the master area and the written data are returned for the own server machine. When writing to the cache area and returning the write result to the I / O input side that has made the write request, and the I / O input is neither a read request nor a write request to the master area, the local server machine A function of passing the data by the I / O input to the lower side of the filter driver provided in the server and returning a return value to the I / O input side in the local server machine ,
The program is further provided when the cluster software is a standby system.
When the standby cluster software determines whether the active cluster software is alive, and determines that the active cluster software is not alive, the standby cluster software changes the commit right management unit. The commit right is granted only to the local server machine, and the cache area data for the server machine provided with the active cluster software is copied to the patch area for the local server machine to copy the patch area. Substituting as a part of the master area, making the master area visible from the own server machine side, and starting an application provided in the own server machine,
The filter driver provided on the local server machine waits for I / O input after the cluster software provided on the local server machine becomes active, and the I / O input is read into the master area. If it is a request, if a part or all of the read request data is in the patch area for the own server machine, read from the patch area, refer to the cache area for the own server machine, and Or, if all are in the cache area for the server machine, read from the cache area, if there is other read request data, read from the master area, and return the read data to the I / O input side that requested the read When the I / O input is a write request to the master area, all the write request destinations must be in the patch area for the own server machine. Write to the patch area and return to the I / O input side; otherwise, only the data corresponding to the patch area is written to the patch area and there is no free space to write to the cache area for the local server machine. For example, the commit right management unit is referred to confirm whether or not the commit right is granted to the own server machine. If granted, the cache area data for the own server machine is copied to the master area and The cache area is cleared, and if it is not granted, an error is returned to the I / O input side. Thereafter, the write position information in the master area and the written data are written into the cache area for the own server machine, and the I / O When the I / O input is neither a read request nor a write request to the master area. The I / O input passes the data by, the return value the program for a function that returns the I / O input side to realize the local server machine to the lower layer of the filter driver that the provided in the own server machine. The program according to claim 2,
Each filter driver, each comprise a memory cache area having the same data as the cache area of the local server machine,
Instead of referring to the cache area for the own server machine, instead of referring to the memory cache area for the own server machine, the write position information in the master area and the written data are written to the cache area for the own server machine. In addition, a program for copying data in the memory cache area to the master area instead of writing to the memory cache area and the cache area for the server machine and copying the data in the cache area to the master area.

Images