JP5466717B2 - Apparatus, method, and computer program for maintaining data integrity (apparatus for maintaining data consistency) - Google Patents

Description

  The present invention relates to an apparatus for maintaining data integrity.

  In “high availability” commercial computing environments, hardware and software technologies are typically combined to provide immediate recovery of critical programs from hardware and software failures. This environment is designed to eliminate single points of failure.

  For example, a typical high availability environment typically includes several loosely coupled computers that share resources such as disk drives. Essential programs can be run on any computer set. In addition, hardware resources (eg, disk drives) are shared between computers. A hardware or software failure that leads to the unavailability of an essential program can be repaired by restoring its availability by moving the program to another computer.

  A typical high availability environment has historically been managed by software called high availability (HA) software. HA software typically manages hardware and software components by monitoring the components and taking responsibility for moving resources in response to failures.

  An example of such a high availability environment (100) is shown in FIG. 1 and includes a first computer having a first HA software (117) and a first instance (110) of a high availability software component. (105), wherein the software component (110) is operable to access a shared resource (eg, a shared disk (120) comprising data).

  The high availability environment (100) also includes a second computer (115) having second HA software (119) operable to communicate with the first HA software (117).

  In one example, a first instance (110) of a first computer (105) accesses a shared disk (120). The first HA software (117) has “ownership” of the shared disk (120).

  In the event of a failure of the first computer (105), the second HA software (119) responds (eg, the second HA software can no longer communicate with the first HA software (117)). ) Operate to detect the failure.

  Referring to FIG. 2, in response, the second HA software (119) terminates the first instance (110), transfers ownership of the shared disk (120) to itself, and then the second Operable to initiate a second instance (125) of the software component on the computer (115). The second computer (115) is then operable to “take over” the responsibilities from the first computer (105) so that the second instance (125) running on the second computer (115) The shared disk (120) can be accessed.

  The environment (100) of FIGS. 1 and 2 provides a guaranteed single activation of a software component, ie, starting two instances of a software component simultaneously on different computers Impossible. If two instances of a software component are started simultaneously on different computers, this can cause errors such as data corruption on the shared disk (120).

  The aforementioned environment (100) provides high availability of essential programs and a guaranteed single activation of essential programs, but allows special hardware (eg, accessible by multiple computers) Shared disk (120)) and software (e.g. HA software) that need to be specially configured.

  More modern techniques can achieve high availability and a single guaranteed activation without the need for special hardware and / or software.

  Such an environment (200) is shown in FIG. 3, and the environment (200) comprises two instances of the same software component. More specifically, the environment (200) comprises a third computer (205) having a third instance (210) of a high availability software component, the third instance (210) having, for example, data It is operable to access a shared resource such as a shared disk (220) with which it is provided. The environment (200) also includes a fourth computer (215) having a fourth instance (225) of a high availability software component that also accesses the shared disk (220). It is possible to operate.

  In the example of FIGS. 1 and 2, since the environment (100) comprises HA software, the software component need not be responsible for a guaranteed single activation. Since the environment (200) of FIG. 3 does not include HA software, the software component must be able to ensure that data on the shared disk is not corrupted by uncoordinated simultaneous access from both computers (205, 215). There is.

  If each instance of a software component consists of a single process, and if the data on the shared disk is contained in only a few files, the shared It is sufficient to use file locking of data files on disk.

  For example, exclusive file locking can be used to ensure that only one running instance of a software component is reading or writing a data file at a time. In a more complex approach, “range locking” of a region of the data file can be used to ensure that multiple instances of the software component do not corrupt the data file due to uncoordinated access.

    As software components become more complex, further improvements are required.

  According to a first aspect of a preferred embodiment, data integrity is maintained for use in an environment comprising a first software instance having a first plurality of processes and a second software instance. An apparatus is provided for wherein a first software instance and a second software instance are each operable to access shared data, and a file associated with the shared data is used for locking. , In response to the first tier file lock not being held by the first parent process of the first plurality of processes, the device responsive to the first tier file lock on behalf of the second instance. A first lock component and a first hierarchy on behalf of a second instance for obtaining Means for activating a second lock component in response to a file lock being acquired, the second lock component being a child of the first hierarchical file lock; An activity operable to obtain a second hierarchical file lock on behalf of the second instance in response to the second hierarchical file lock not being held by any first plurality of processes In response to the first lock component obtaining the first hierarchy file lock and the second lock component obtaining the second hierarchy file lock. To prevent the first instance from accessing the shared data and to allow the second instance to access the shared data It includes an order of means, the.

  According to a second aspect of the preferred embodiment, data integrity is maintained for use in an environment comprising a first software instance having a first plurality of processes and a second software instance. Are provided, wherein the first software instance and the second software instance are each operable to access shared data, and a file associated with the shared data is used for locking. The method is responsive to the first tier file lock not being held by the first parent process of the first plurality of processes in response to the first tier file lock on behalf of the second instance. Get the first hierarchy file lock on behalf of the second instance And, in response to the second hierarchy file lock being a child of the first hierarchy file lock not being held by any of the first plurality of processes, the second hierarchy on behalf of the second instance Obtaining a file lock; preventing the first instance from accessing shared data in response to obtaining the first hierarchy file lock and the second hierarchy file lock; and Allowing the second instance to access the shared data.

  According to a third aspect of the preferred embodiment, there is provided a computer program comprising program code means adapted to perform all the steps of the method when executed on a computer.

  The invention will now be described by way of example only with reference to the preferred embodiments shown in the following drawings.

It is a block diagram which shows the 1st environment of the high availability of a prior art. FIG. 2 is a block diagram illustrating a first high-availability environment of the prior art illustrated in FIG. 1 when a computer failure occurs in the first high-availability environment. It is a block diagram which shows the 2nd environment of the high possibility of a prior art. FIG. 3 is a block diagram illustrating a second high availability environment according to a preferred embodiment. 5 is a flow diagram illustrating operational steps included in a process associated with a parent process in the environment of FIG. FIG. 5 is a flow diagram illustrating operational steps included in a process associated with a child process of the environment of FIG. FIG. 3 is a block diagram illustrating components associated with a first parent process. FIG. 6 is a block diagram illustrating components associated with a second parent process. FIG. 8 is a block diagram illustrating components associated with a first child process of the parent process of FIG. FIG. 8 is a block diagram illustrating components associated with a second child process of the parent process of FIG.

  An improved approach is required in an environment where multiple instances of a software component each have multiple processes that can access data in a shared resource.

  In the example herein, multiple instances of a software component can be started simultaneously on multiple computers. Each instance is operable to access data in this environment, and each instance comprises one or more operating system processes.

  Each instance of a software component is either an “active” instance (can update data) or a “standby” instance (cannot update data).

  At any point in time, the environment does not have multiple active instances, but multiple standby instances can exist, thereby ensuring a single activation of the essential program.

  Preferably, a single standby instance can become a new active instance if a complete failure of the active instance (ie, a failure associated with any process of the current active instance) occurs. . More preferably, an active instance partial failure (ie, a failure that is associated with a subset of processes of the current active instance but not associated with any process of the current active instance) is a single standby. Prevent an instance from becoming a new active instance.

  Next, implementation of a preferred embodiment will be described with reference to the drawings.

  FIG. 4 shows a high availability environment (300) comprising a fifth computer (305) having a fifth instance (310) of a high availability software component.

  The fifth instance (310) comprises a plurality of processes (311, 312, and 313), each operable to access a shared resource, such as a shared disk (320) comprising data. In one example, the shared disk (320) is associated with a network file system.

  The first process (311) is a parent process having two child processes (ie, the second process (312) and the third process (313)), and this parent process initiates the child process.

  The environment (300) also comprises a sixth computer (315) having a sixth instance (325) of high availability software components, each of which accesses a shared disk (320). A plurality of processes (326, 327, and 328) operable to.

  The fourth process (326) is a parent process having two child processes (ie, a fifth process (327) and a sixth process (328)), and this parent process initiates the child process.

  FIG. 7 is a block diagram illustrating components associated with a first process (311), each of the first processes (311) being operable to access a shared disk (320). Monitoring component (600) and a first locking component (605). The first process (311) also comprises a first initiator component (610).

  FIG. 8 is a block diagram illustrating components associated with a fourth process (326), each of which is operable to access a shared disk (320). Monitoring component (615) and a second locking component (620). The fourth process (326) also comprises a second initiator component (625).

  FIG. 9 is a block diagram illustrating components associated with a second process (312), each of which is operable to access a shared disk (320). Monitoring component (700) and a third locking component (705). The second process (312) also comprises a first terminator (710).

  FIG. 10 is a block diagram illustrating components associated with a third process (313), each of which is operable to access a shared disk (320). Monitoring component (715) and a fourth locking component (720). The third process (313) also comprises a second terminator (725).

  Preferably, each of the parent process and child process is operable to access one or more locks.

  Files stored on the shared disk (320) are used for locking.

  In the example herein, a master lock that can be locked in exclusive mode and an active lock that can be locked in exclusive or shared mode are provided.

  The present invention can be implemented with an advisory lock or mandatory lock.

  Preferably, the lock comprises an identifier associated with the instance whose parent process holds the lock. In one example, this identifier is stored in a file used for locking on the shared disk (320). In other examples, this identifier is stored in a file separate from the file used for locking.

  Next, an example will be described with reference to FIGS.

  In one example, the first process (311) starts execution, thereby starting the fifth instance (310).

  Referring to FIG. 5, the first monitoring component (600) of the first process (311) monitors the master lock to determine if the lock exclusive mode is acquirable (step 400).

  The first monitoring component (600) determines that the exclusive mode can be acquired on the master lock, and in response, the first lock component (605) sets the exclusive mode on the master lock. get. Preferably, the identifier associated with the first process (311) is associated with the master lock.

  The first monitoring component (600) of the first process (311) monitors active locks to determine if the lock exclusive mode is acquirable.

  The first monitoring component (600) determines that the exclusive mode is obtainable on the active lock, and in response, the first lock component (605) is in the exclusive mode on the active lock. To get. Preferably, the identifier associated with the first process (311) is associated with an active lock.

  In response, the fifth instance (310) becomes the active instance (ie, the fifth instance (310) becomes the only active instance).

  In response, the first lock component (605) unlocks the exclusive mode on the active lock and then locks the active lock in the shared mode.

  The first initiator component (610) initiates one or more child processes. In the example herein, the first initiator component (610) initiates a second process (312) and a third process (313).

  Alternatively, at least one of the second process (312) and the third process (313) is initiated independently (eg, by another process separate from the first process (311)) can do.

  Preferably, the second and third processes do not perform any work until the active lock holder confirms that it is the first process, and the third monitoring component (700) and Each of the fourth monitoring components (715) checks the identifier associated with the active lock to determine whether the identifier is associated with the respective parent process of the second process and the third process. To do. If the identifier is not associated with the parent process, the second and third processes assume that the parent process has failed and must be terminated, but this termination procedure is described below. Will be described in more detail.

  In this example, the identifier is associated with the parent process (ie, the first process (311)). In response, referring to FIG. 6, at the start, each of the third monitoring component (700) and the fourth monitoring component (715) determines whether the lock sharing mode can be acquired (steps). 500) for active locks.

  The third monitoring component (700) determines that the sharing mode is obtainable on the active lock, and in response, the third locking component (705) is responsible for the sharing on the active lock. The mode is acquired (step 505).

  The fourth monitoring component (715) determines that the shared mode can be acquired on the active lock, and in response, the fourth lock component (720) determines that the shared mode on the active lock. The mode is acquired (step 505).

  Thus, the first process (311) holds the master lock in exclusive mode, and each of the first process (311), the second process (312), and the third process (313) Hold the lock in shared mode.

  As a result, no other single instance can become the new active instance, and each of the first process (311), the second process (312), and the third process (313) You can safely access the data inside. Since the first process (311), the second process (312), and the third process (313) are associated with the same instance (ie, the fifth instance (310)), the first process ( It should be understood that access to the shared disk (320) by 311), the second process (312), and the third process (313) can be adjusted using known mechanisms.

  Referring to FIG. 5, in this example, the fourth process (326) is initiated by the sixth instance (325).

  The fourth monitoring component (615) of the fourth process (326) monitors the master lock to determine if the lock exclusive mode is obtainable (400).

  The fourth monitoring component (615) determines that the exclusive mode cannot be acquired on the master lock, because the master lock exclusive mode has already been acquired by the first process (311). It is.

  Advantageously, the fourth monitoring component (615) also uses the decision associated with whether the master lock exclusive mode is obtainable to also determine if other instances are active. be able to. If the fourth monitoring component (615) is unable to obtain the master lock exclusion mode, the fourth monitoring component (615) determines that another instance already holds the master lock exclusion mode. .

  In step 430, the sixth instance (325) determines whether to retry to become a new active instance. In response to the sixth instance (325) not retrying to become a new active instance, the process of FIG. 5 ends.

  In response to retrying the sixth instance (325) to be a new active instance, the sixth instance (325) is marked as a standby instance (step 435).

  In this example, the sixth instance (325) retries to become a new active instance (step 435), after which the fourth monitoring component (615) determines whether the lock exclusive mode is available. The master lock is monitored for determination (step 400).

  The fourth monitoring component (615) determines that the exclusive mode is obtainable on the master lock, which in this example is that the master lock exclusive mode is the first process (311). Implicit due to failure of the first process (311) that has been released by the lock component (605) (eg, explicitly released because the first process (311) has completed its work) Because it has been released).

  Thereafter, the fourth lock component (720) acquires the exclusive mode on the master lock (step 405).

  Now the sixth instance (325) tries to become the new active instance.

  In response, the fourth monitoring component (615) then monitors the active lock to determine if the lock exclusive mode is acquirable (step 410).

  The first monitoring component (600) determines that the exclusive mode cannot be acquired on the active lock, which in the example herein is the second process (312) or the third process (313). Because at least one of them still holds the active lock in shared mode.

  Thereafter, the fourth lock component (720) releases the exclusive mode on the master lock, and the sixth instance (325) maintains the standby instance (step 430).

  It should be understood that the preferred embodiment provides "hierarchical" locks, i.e., master locks and active locks, where a master lock can be acquired first, followed by an active lock. The present invention uses the hierarchical lock to adjust the timing window so that the parent process of the current active instance can be terminated but the associated child process is not yet terminated, and as a result, The exclusive mode on the master lock is released by the parent process, and the shared mode on the active lock is trusted by not being released by the child process. Thus, even if the fourth process (326) can acquire the exclusive mode on the master lock (ie, at least one of the second process (312) or the third process (313) is still an active lock). The sixth instance (325) maintains a standby instance even if the fourth process (326) cannot acquire an exclusive mode on the active lock.

  In response to not retrying the sixth instance (325) to become the new active instance (step 435), the process ends.

  In this example, in response to retrying the sixth instance (325) to become the new active instance (step 435), the fourth monitoring component (615) can acquire the lock exclusive mode. The master lock is monitored to determine whether it is (step 400).

  The fourth monitoring component (615) determines that the exclusive mode can be acquired on the master lock, which in this example is the master lock exclusive mode is the first of the first process (311). This is because it is released by the lock component (605).

  Thereafter, the fourth lock component (720) acquires the exclusive mode on the master lock.

  The fourth monitoring component (615) then monitors the active lock to determine if the lock exclusive mode can be obtained (step 410).

  The first monitoring component (600) determines that the exclusive mode can be acquired on the active lock, which in this example is either the second process (312) or the third process (313). This is because the active lock is still not held in the shared mode.

  An event that neither the second process (312) or the third process (313) holds an active lock in shared mode is, for example, that either the second process and the third process are explicit or By being terminated implicitly, or the first process (311) is terminated (explicitly or implicitly by a fault), after which the third monitoring component (700) and the fourth monitoring component Each of (715) may occur by determining (step 510) that the first process (311) has ended using the polling function, and then the second process and the second The first terminator (710) and the second terminator (725) of each of the three processes are terminated. (Step 520), to release the active lock in shared mode. It should be understood that if the first process (311) has not finished, the child process can continue working (step 515).

  In response to the first monitoring component (600) determining that the exclusive mode is obtainable on the active lock, the fourth lock component (720) is in the exclusive mode on the active lock. To get.

  In response, the sixth instance (325) becomes the new active instance.

  In the above example, there is no child process (ie, the previous active instance) of the running fifth instance (310), so the fourth lock component (720) is in exclusive mode on the active lock. It should be understood that is operable to obtain Further, the fourth lock component (720) is on the master lock and on the active lock because the respective processes (311, 312 and 313) associated with the fifth instance (310) are not running. Each of which is operable to acquire an exclusive mode.

  In other implementations, multiple active locks are provided. Preferably, if the exclusive mode on the master lock is released, all processes of the active instance can have multiple active instances to allow other instances to attempt to become the new active instance. All of the locks must be released.

  The fourth lock component (720) then unlocks the exclusive mode on the active lock and then locks the active lock in shared mode.

  The second initiator component (625) can initiate one or more child processes, eg, a fifth process (327) and a sixth process (328).

  Advantageously, the present invention provides high availability of instances (eg, an instance can become a new active instance) as well as software components in an environment where each instance can comprise multiple processes. Guaranteed single activation so that only one instance of can access shared data at a time (eg, by using “hierarchical” locking such as exclusive master lock and exclusive / shared active lock) Make it possible.

  Advantageously, there is no need to configure the instance with the location of other instances, and the network does not have to heartbeat between instances to ensure a single activation. This is because file locking can be used to guarantee a single activation. Advantageously, the failed instance can be placed on the standby instance without having to know the data associated with the failed instance (for example, the location associated with the location where the failed instance was running). Can be replaced.

  Advantageously, HA software is not required. This increases usability and makes it easier to introduce standby instances.

  Further, for example, in the event of a network outage, it is advantageous to associate the identifier of the process holding the lock with the lock. Following a failure stop, the parent process can reacquire the lock and query the identifier to determine if the identifier is its own. If the identifier is itself, then the process knows that it had held the lock before the failure stop and that no other instance acquired the lock during the failure stop. If the identifier is not its own, the process knows that the other instance had to acquire a lock during the failure outage, in which case the parent process and other processes associated with the instance are consistent The instance must be terminated to guarantee its sexuality (and the parent process can be re-executed and attempted to acquire the lock if necessary).

  If there are multiple standby instances, preferably a selection process is implemented to select a single standby instance to be the new active instance if the current active instance is no longer the active instance It should be understood that, for example, multiple standby instances compete to be the new active instance, and the multiple standby instances determine which will be the new active instance. Alternatively, other lock files can be used to coordinate and monitor the standby instance.

Claims (7)

An apparatus for maintaining data integrity, used in an environment comprising a first software instance having a first plurality of processes and a second software instance, wherein the first software instance And the second software instance is each operable to access shared data, and a file associated with the shared data is used for locking;
Each process of the second software instance comprises a first locking component, a second locking component, and a means for activating the second locking component;
In response to a first hierarchy file lock not being held by a first parent process of the first plurality of processes, obtaining the first hierarchy file lock on behalf of the second instance A first locking component for
Means for activating a second lock component in response to obtaining the first hierarchy file lock on behalf of the second instance, the second lock component , On behalf of the second instance, in response to a second hierarchy file lock being a child of the first hierarchy file lock not being held by any of the first plurality of processes. Means for activating, operable to acquire a second hierarchy file lock;
Responsive to the first lock component obtaining the first tier file lock and responsive to the second lock component obtaining the second tier file lock. Means for preventing the first instance from accessing shared data and for allowing a second instance to access the shared data;
An apparatus comprising: Each process of the second software instance further comprises a second monitoring component;
The second lock component is responsive to a second monitoring component determining that a second hierarchy file lock has been acquired by at least one of the first plurality of processes. The apparatus of claim 1, wherein the apparatus is operable to prevent obtaining the second tier file lock on behalf of the second instance.   The second software instance comprises a second plurality of processes, and the second lock component is configured to replace the second hierarchical file lock on behalf of at least one of the second plurality of processes. The apparatus of claim 1, wherein the apparatus is operable to obtain   The apparatus of claim 1, further comprising a first monitoring component for determining whether the first hierarchy file lock is available to be acquired.   The apparatus of claim 1, further comprising a second monitoring component for determining whether the second hierarchy file lock is available to be acquired. A method for maintaining data integrity for use in an environment comprising a first software instance having a first plurality of processes and a second software instance, wherein the first software instance And the second software instance is each operable to access shared data, and a file associated with the shared data is used for locking;
Each process of the second software instance comprises a first locking component, a second locking component, and a means for activating the second locking component;
In response to a first hierarchy file lock not being held by a first parent process of the first plurality of processes, obtaining the first hierarchy file lock on behalf of the second instance To do,
The first tier file lock is acquired on behalf of the second instance, and any second tier file lock that is a child of the first tier file lock In response to being not held by a plurality of processes, obtaining a second hierarchy file lock on behalf of the second instance, and the first hierarchy file lock and the second hierarchy file In response to obtaining a lock, preventing the first instance from accessing the shared data, and allowing the second instance to access the shared data;
Only including,
A method that allows a computer that combines hardware and software techniques to do these things .   A computer program comprising program code adapted to perform the method of claim 6 when executed on a computer.

Images