JP5419166B2 - Checkpoint creation device, checkpoint creation system, checkpoint creation method, and checkpoint creation program - Google Patents

Description

  The present invention relates to a technique for creating a checkpoint in a distributed processing apparatus constituting a distributed system.

  A checkpoint method and a message log method are known as conventional techniques corresponding to a crash failure of a distributed processing apparatus.

  In the checkpoint method, the state (hereinafter referred to as “checkpoint”) of a computer constituting the distributed system at a certain point in time is periodically saved in a stable storage means such as a hard disk. Then, when a crash failure occurs, some computers roll back to a past recording state to recover consistent execution.

  When creating checkpoints on each computer that constitutes a distributed system, checkpoints are also created in cooperation with other computers to prevent inconsistencies between computers when rolling back to the latest state. To do. Such a coordinated checkpoint method is effective in a distributed system that provides a long-term service. Note that Non-Patent Document 1 is known as a method for creating a checkpoint of a system in which the number of agents does not change, and Non-Patent Document 2 is a method of creating a checkpoint in a system in which the number of agents varies.

  In the message log method, messages sent and received by each computer during service execution are stored in the memory (volatile storage medium) or stable storage means of each computer, and when a crash occurs, the crashed computer is set to an initial state. The crashed computer, from the normal process, based on the communication record stored in its memory and stable storage means, have other computers send information on what messages have been sent and received in the past, Based on this information, the application is re-executed to return to a consistent state as a whole. However, since the message log method alone has a problem that message records accumulate, it is usually used in combination with the cooperative checkpoint method described above. In the message log method, only the failed computer needs to be rolled back. However, when a plurality of computers fail at the same time, there is a problem that recovery is difficult.

K.M. Chandy and L. Lamport, "Distributed snapshots: Determining global states of distributed systems", ACM Transactions on Computer Systems, 1985, Volume 3, Issue 1, pp.63-75 Noboru Moriya, Tomoyuki, “Dynamic Snapshot Algorithm and Partial Rollback Algorithm for Internet Agents”, IEICE Transactions, 2003, Vol. J86-D-I, No.5, pp.301-317

  Since the prior art assumes that a single application or a service agent program operates on one distributed processing device, when one or more service threads operate on one distributed processing device, There is a problem that there is no method for efficiently transmitting and receiving markers and the like.

  In order to solve the above problems, in the checkpoint creation technique according to the present invention, one or more service threads, one or more flag threads, and a checkpoint thread operate and stop on the distributed processing device. The flag is information indicating whether or not the service thread operating on the distributed processing device is to be stopped, the execution list is a list of service threads operating on the distributed processing device, and the stop list is operating on the distributed processing device. When it is a list of stopped service threads, the service thread performs processing according to the request of the application running on the distributed system or other service threads, and stores the execution history of each service thread as a request log. When the checkpoint thread first receives a marker on the distributed processing unit, or When the distributed processing device starts the snapshot, update the stop flag to something that indicates the stop of the service thread that runs on this checkpoint creation device, and before the service thread performs processing on demand, or When the flag thread periodically refers to the stop flag, and the stop flag means stop of the service thread operating on the checkpoint creation device, the service thread processing is stopped, and the execution list and When the service threads stored in the stop list match, the request log is stored in a storage area that is not lost due to a failure.

  Since the present invention collectively manages one or more service threads operating on one distributed processing apparatus, markers can be efficiently transmitted / received, the network traffic in the distributed system is reduced, and transmission / reception is performed. There is an effect that processing (calculation amount) can be reduced.

1 is a diagram illustrating a configuration example of a distributed system 10. FIG. The figure which shows the software structural example of checkpoint production apparatus 100-n. The functional block diagram of checkpoint creation apparatus 100-n. The figure which shows the example of data of the request log memorize | stored in the request log memory | storage means 103a. The figure which shows the example of data of the stop flag memorize | stored in the stop flag memory | storage means 103b. The figure which shows the example of data of the marker list memorize | stored in the marker list memory | storage means 103c. The figure which shows the example of data of the execution list memorize | stored in the execution list memory | storage means 103d. The figure which shows the example of data of the stop list memorize | stored in the stop list memory | storage means 103e. The figure which shows the processing flow of a service thread. The figure which shows the processing flow of a checkpoint thread | sled. The figure which shows the example of a processing flow of a flag thread. The figure which shows the example of a processing flow of the distribution system. The figure which shows the example of a processing flow of the distribution system. The block diagram which illustrated the hardware constitutions of distributed processor 100-n.

  Hereinafter, embodiments of the present invention will be described in detail.

<Distributed system 10>
A distributed system 10 according to the first embodiment will be described. As shown in FIG. 1, the distributed system 10 includes N distributed processing devices 100-n (n = 1, 2,..., N, N = 3 in FIG. 1) connected by a network. The end user uses the user terminal 90 to access the distributed processing system 10 via the Internet and request a service. In the distributed system 10, N distributed processing devices 100-n transmit and receive information to and from each other through a network, and provide services to end users.

<Distributed processing apparatus 100-n>
The distributed processing apparatus 100-n will be described with reference to FIGS. In preparation for a crash failure of some of the distributed processing devices in the distributed system 10, each distributed processing device 100-n has stable storage means such as a hard disk with contents consistent with the other distributed processing devices 100-p (n ≠ p). Record the status. That is, each distributed processing apparatus 100-n proceeds with processing while creating checkpoints. Therefore, the distributed processing device is also called a checkpoint creation device.

  As shown in FIG. 2, the web service middleware 21 is mounted on one distributed processing device 100-n configuring the distributed system 10. Further, M service threads 22-m (m = 1, 2,..., M) that process services on the web service middleware 21 are operating. One distributed processing apparatus 100-n has Q databases 23-q (q = 1, 2,..., Q), and each service thread can share these databases. Details of the service thread will be described later.

  As shown in FIG. 3, the distributed processing apparatus 100-n includes an input / output unit 101, a storage unit 103, a control unit 105, M service thread units 110-m (m = 1, 2,..., M), a check. Point thread 130, R flag thread means 140-r (r = 1, 2,..., R, however, since at most one flag thread is associated with each service thread being executed, R ≦ M) Is provided.

  Web service middleware refers to software that performs intermediate processing and operations between an operation system (hereinafter referred to as “OS”) and web service software. Provide functionality.

  In the present embodiment, a means for directly introducing a coordinated checkpoint method is provided to web service middleware often used in building a web service. In particular, a method for creating a consistent checkpoint that can be re-executed by each distributed processing device is provided.

  By adopting such a configuration, it is possible to separate application development and fault-tolerant mounting work. Therefore, the application developer can use the function without being aware of the fault tolerance method, and can concentrate on application development. As a result, application development is facilitated.

  In addition, since the user is guaranteed a high fault-tolerant function in the web service, the user can use the service with peace of mind, and the use of the web service is promoted.

<Input / output means 101>
The input / output unit 101 includes, for example, an input interface for inputting an output signal of an input device (for example, a keyboard, a mouse, etc.) to which data is input, a signal read from an external storage device, a signal received from a network, etc. , And an output interface for outputting an output signal of an output device (for example, a display or a printer) from which data is output, a signal to be written to an external storage device, a signal to be transmitted to a network, or the like.

<Storage unit 103 and control unit 105>
The storage means 103 stores input digital signals, signals being processed, various parameters, and the like. The control means 105 reads / writes predetermined signals and parameters from / to the storage means 103 in each processing step. However, the control means 105 does not necessarily have to read / write each data with respect to the memory | storage means 103, You may control so that data may be passed directly between each means.

  For example, the storage unit 103 includes a request log storage unit 103a, a stop flag storage unit 103b, a marker list storage unit 103c, an execution list storage unit 103d, a stop list storage unit 103e, and a stable storage unit 103f.

  The request log is data used to express the state of a service thread described later. For example, the request log includes a combination of service contents, an execution counter, and an execution history (see FIG. 4). The service content is a pair of a service name and an argument when the service thread is called. At this time, the caller application name, service thread name, output order, time, and the like may be used as arguments, and by using such data, the service thread means can be uniquely identified. The execution counter is a number indicating the number of service thread operations that the service thread is currently counting from its generation. When recovering by rollback, processing is performed from the execution part indicated by the stored execution counter. To resume. The execution history is, for example, history data of synchronous request transmission and database read operations among service thread operations performed in the past (hereinafter referred to as “service thread operations”).

  The stop flag is information indicating whether or not the M service thread means 110-1,..., 110-M operating on the checkpoint creation apparatus 100-n are stopped (for example, in this embodiment). In FIG. 5, if the stop flag is “on”, it means that the service thread means is stopped, and if it is “off”, it means that the service thread means is not stopped. (Refer to FIG. 6 registered for each checkpoint creation device, not for each service thread, refer to FIG. 6). The execution list is a service thread means 110 operating on this checkpoint creation device 100-n. -M list (see FIG. 7), and the stop list is for stopping operations on the checkpoint creation apparatus 100-n. A list of service thread means 110-m that (see FIG. 8). One stop flag, marker list, execution list, and stop list are provided for each checkpoint creation device, and a request log is provided for each service thread.

  The stable storage means 103f is a storage area (for example, a hard disk or ROM that is a nonvolatile memory) that is not lost due to a failure.

<Service thread means 110-m>
The service thread is a program for causing a computer to function as service thread means 110-m that performs processing in response to a request from an application or other service thread means operating on the distributed system. The service thread means is also simply called a service thread.

  Service thread operations that can be observed from the outside are transmission of a request to the web service middleware of another distributed processing device, and access to the database of the distributed processing device that is operating. Request transmission is classified into an asynchronous type that does not require a response to a request and a synchronous type that waits for a response of a result. Database access includes “write” and “read”. In addition, the service thread performs processing such as internal calculation.

  The service thread processing flow will be described with reference to FIG. When the service thread is generated, an application for registration of an execution list is made to the checkpoint thread, and a request log (see FIG. 4) including service contents is generated (s111). Next, the service thread refers to the stop flag storage unit 103b (s112). If the stop flag is on, the service thread applies to the checkpoint thread 130 for registration to the stop list (s113), and periodically sets the stop flag. Refer to (s114). In s112 and s114, when the stop flag is off, the following processing is performed. The stop flag is updated to on or off by a checkpoint thread described later. When the service thread operation type is a synchronous request transmission operation or a database read operation (s115), the service thread generates a flag thread described later (s116).

  The service thread increments the execution counter of the request log stored in the request log storage unit 103a, registers the contents of the service processing in the execution history (s117), provides the service (s118), and responds to the processing result. The execution history of the request log is updated (s119).

  If the service thread operation type is a synchronous request transmission operation or a database read operation (s120), the service thread ends the flag thread (s121). When the service request is completed by this service thread operation (s122), the request log corresponding to the service request is deleted from the request log storage means 103a. Further, the service thread makes an application for deletion from the execution list to the checkpoint thread (s123). If the service request is not finished (s122), s112 to s121 are repeated until the service is finished.

(Update request log)
The request log is updated by the service thread as follows. When a request arrives from another distributed processing apparatus, a new service thread is generated to process the request. At this time, a request log corresponding to the service thread is generated. For example, the service content (service name, its caller, argument that is the order of call, etc.) and execution counter (for example, the execution counter is set to 0 at the time of generation) are registered. Thereafter, the execution counter is incremented by 1 each time the service thread performs a service thread operation. When synchronous request transmission or database reading is performed, in addition to the request transmission operation and the database reading operation, the response result and the reading result are also registered in the execution history. Registrations are arranged in order of execution. In the case of a request transmission operation, as an execution history, a service name (shown as service1 and service2 in FIG. 4), an argument (shown as v2 and v3 in FIG. 4), a target checkpoint device name (shown in FIG. 4). , Distributed processing apparatuses 100-2 and 100-1) and response results are registered. In the case of a database read operation, as an execution history, an SQL statement (shown as read1, read2, read3 in FIG. 4), a target database name (shown as d1, d2, d3 in FIG. 4) and a read result ( In FIG. 4, w1, w2, and w3) are registered. Until the response result and the read result are obtained, the response result and the read result portion of the execution history are registered as undecided.

<Checkpoint thread means 130>
The checkpoint thread is a program for causing the computer to function as the checkpoint thread means 130 that performs transmission / reception of marker messages transmitted / received between the distributed processing devices and causes the computer to function to update the stop flag and the marker list. One checkpoint thread exists in each distributed processing device. The checkpoint thread means is also simply called a checkpoint thread.

  In addition, the checkpoint thread registers and updates the transmission destination of the request transmitted by the service thread m and the generation source of the service thread m in the marker list. In web service communication, message communication is limited to request transmission for generating a service thread or transmission for returning a return value of the request, so the above two may be registered. The description of the marker list creation method, update method, and marker transmission will be omitted. Details are described in Non-Patent Document 2. However, in Non-Patent Document 2, marker transmission / reception is performed in units of agents, but the present invention is different in that marker transmission / reception is performed in units of distributed processing devices.

  The processing flow of the checkpoint thread will be described with reference to FIG. When there is an application for registration or deletion from the service thread to the execution list (s130), the checkpoint thread performs registration or deletion from the execution list (s131). The checkpoint thread updates the stop flag to on (s133) when a marker arrives first from another distributed processing device or when this distributed processing device starts a snapshot (s132). Thereafter, when there is a stop list registration application from the service thread or flag thread (s134), the target service thread is registered in the stop list (s135), and a stop report is issued from all the service threads that register the execution status. (That is, it is determined whether or not the service thread registered in the execution list matches the service thread registered in the stop list, s136), and if there is a stop report from all the service threads ( If they match, the stop list is reset and the stop flag is updated to off (s137). Then, the marker is transmitted to the distributed processing apparatus registered in the marker list. If the service thread registered in the execution list does not match the service thread registered in the stop list (s136), s134 and s135 are repeated until they match.

<Flag thread means 140-r>
The flag thread is a program for causing a computer to function as flag thread means 140-r that refers to a stop flag. For example, the flag thread is generated when the service thread operation of the service thread is a synchronous request transmission operation or a database read operation. The flag thread means is also simply called a flag thread.

  The processing flow of the flag thread will be described with reference to FIG. The generated flag thread refers to the stop flag of the stop flag storage means 103b periodically (for example, every time a predetermined time elapses (s141)) (s143), and when the stop flag is on (s145), checkpoint The thread is requested to register the corresponding service thread in the stop list (s147).

  In the coordinated checkpoint method, a marker is transmitted and received between distributed processing devices, and a checkpoint is started, ended, and a message to be stored is determined. In this embodiment, a checkpoint is created based on this marker.

  When the request log is recorded in the stable storage unit 103f, there may be a case where a synchronous request transmission or a database read response result is not obtained. Regarding the database reading, when there is a response, it is added to the stable storage means 103f. As for the return value of the synchronous request transmission, if the return value is returned before the destination distributed processing apparatus marker arrives, the value is added to stable storage. If the marker arrives before the return value, the return value is undecided and the request thread record of the service thread is confirmed. By performing such processing, consistent checkpoints can be created for the distributed system.

<Operation example>
An example of the operation will be described with reference to FIGS. It is assumed that there are a distributed processing device 100-1 and a distributed processing device 100-2, and a service thread 1 is generated in the distributed processing device 100-1 with a service name service1 and an argument v1 in response to a request from an application operating in the distributed system 10 ( s61). The checkpoint thread registers the service thread 1 in the execution list, the service thread 1 generates a request log, and stores the service contents (service1, v1) as the request log in the request log storage unit 103a (s62). Assume that the first service thread operation of the service thread 1 is to read the database d1. The service thread 1 refers to the stop flag stored in the stop flag storage unit 103b before execution. In this operation example, the initial state of the stop flag is set to off and is updated by the checkpoint thread. Since the stop flag is off, the service thread 1 generates a flag thread, increments the execution counter by 1, and registers database read (read1, d1), which is a service thread operation, in the execution history of the request log (s63). Next, the database is read and service processing is executed (s64). The flag thread periodically refers to the stop flag in the stop flag storage unit 103b. In this embodiment, since the stop flag is still off, the flag thread does not make a stop list registration application. As a result of the operation, the service thread 1 obtains the value w1 from the reading of the database d1, records the value in the request log, updates the request log, and terminates the flag thread (s65). Next, the service thread operation of the service thread 1 is a synchronous request transmission to the distributed processing apparatus 100-2, and it is assumed that the service name is service2 and the argument is v2. First, the service thread 1 refers to the stop flag, and since the stop flag is off, the service thread 1 newly generates a flag thread and registers the synchronous request transmission (service2, v2, distributed processing device 100-2) in the request log. (S66). Request transmission is performed and service processing is executed (s67).

  Upon receiving this request, the web service middleware of the distributed processing device 100-2 generates a service thread 2 of the service content (service2, v2) (s68). The checkpoint thread registers the service thread 2 in the execution list, and the service thread 2 generates its request log (s69). It is assumed that the first service thread operation of the service thread 2 is a synchronous request transmission (service 3, v3) to the distributed processing device 100-1. The service thread 2 refers to the stop flag. At this time, it is assumed that the stop flag of the checkpoint processing device 100-2 is off. The service thread 2 creates a flag thread and registers (service 3, v 3, distributed processing device 100-1) in the request log (s70). The service thread 2 transmits a request and performs service processing (s71).

  Upon receiving this request, the web service middleware of the distributed processing device 100-1 generates a service thread 3 of service contents (service3, v3) (s72). The checkpoint thread of the distributed processing device 100-1 registers the service thread 3 in the execution list. The service thread 3 generates a request log with the service content as (service3, v3) (s73). Assume that the first service thread operation of the service thread 3 is to read the database d2. The service thread 3 refers to the stop flag. Since the stop flag is off, the service thread 3 generates a flag thread and registers (read2, d2) in the execution history of the request log (s74). The database is read and service processing is performed (s75). Thereafter, the service thread 3 obtains the return value w2, records it in the request log execution history, updates the request log, and terminates the flag thread (s76).

  At this time, it is assumed that the first marker reaches the distributed processing apparatus 100-1. The checkpoint thread updates the stop flag to on. The first marker has a role of causing each checkpoint creation device to start stopping the service thread. The marker includes the identifier of the service thread that activated the snapshot, the activation order, the time, and the like, and the checkpoint thread can determine the marker that originates from the same snapshot program. The first marker means the first marker resulting from the same snapshot program.

  Thereafter, it is assumed that the service thread 3 is to read the database d4 for the next service thread operation. The service thread 3 refers to the stop flag before executing reading of the database d4. Since the stop flag is on, the service thread 3 makes a stoplist registration application for the service thread 3 to the checkpoint thread, and stops execution (s77).

  Among them, the flag thread corresponding to the service thread 1 refers to the stop flag, and the stop flag is on. Therefore, the flag thread applies to the checkpoint thread for registering the stop list of the service thread 1 and executes the service thread 1 Instruct to stop. The service thread 1 receives this stop support and stops execution (s78).

  The checkpoint thread registers service thread 1 and service thread 3 in the stop list. As a result, since the contents of the execution list and the stop list match, the checkpoint thread instructs to record the request logs for the service thread 1 and the service thread 3 in the stable storage means 103f. Further, the marker is transmitted to the distributed processing apparatus 100-2, the stop list is reset (the service thread is not registered at all), and the stop flag is updated to off.

  The checkpoint thread of the distributed processing device 100-2 that has received the first marker turns on the stop flag. Thereafter, the flag thread corresponding to the service thread 2 refers to the stop flag, makes a stoplist registration application for the service thread 2 to the checkpoint thread, and instructs the service thread 2 to stop execution. Upon receiving this instruction, the service thread 2 stops its execution (s79). At this time, since the execution list and stop list of the distributed processing device 100-2 match, the checkpoint thread records the request log for the service thread 2 in the stable storage means 103f and transmits the marker to the distributed processing device 100-1. Then, the stop list is reset and the stop flag is updated to off.

  The service thread 3 that has resumed execution generates a flag thread and registers the reading (read4, d4) of the database d4 in the request log execution history (s80). The service thread 3 reads the database d4, records the execution result in the execution history of the request log, and updates the request log. Further, the flag thread is terminated (s81). Then, the service thread 3 returns the acquired return value w4 to the service thread 2. By this process, it is assumed that the service thread 3 ends the service request. The service thread 3 deletes the corresponding request log from the request log storage unit 103f, applies to the checkpoint thread to delete the service thread 3 from the execution list, and disappears (s82).

  At this time, the service thread 2 also receives the return value w4 and advances its execution.

  On the other hand, the distributed processing device 100-1 receives the marker from the distributed processing device 100-2, and the service thread 1 is sent from the distributed processing device 100-2 before the return value from the service thread 2 of the distributed processing device 100-2. As a result, the return value from the request log service thread remains undecided, and the request log record is fixed.

<Effect>
The distributed processing apparatus according to the present embodiment can create consistent checkpoints similarly to Non-Patent Document 1, and moreover, one or more service threads can be collectively managed on one distributed processing apparatus. The marker can be transmitted and received efficiently, and the amount of network communication in the distributed system can be reduced, and the processing (calculation amount) related to transmission and reception can be reduced.

  Conventionally, the realization (implementation) of crash-resistant faults has been devised for each service application to be operated. However, the realization of crash-tolerant faults requires expert knowledge about fault-tolerance, and it has not been easy for service application developers to implement. With the configuration as in the present embodiment, the crash-resistant failure can be realized by the web service middleware, and the application development and the failure-resistant mounting operation can be separated. Therefore, it is possible to create checkpoints in each computer for the coordinated checkpoint method suitable for crash-resistant failures in large-scale distributed systems.

[Modification]
Registration of the service thread in the execution list and stop list may be performed not by the checkpoint thread but by the service thread or flag thread. Also, the deletion of the service thread from the execution list may be performed by the service thread itself before termination, not by the checkpoint thread.

<Hardware configuration>
FIG. 14 is a block diagram illustrating a hardware configuration of the distributed processing device 100-n according to the present embodiment. As illustrated in FIG. 14, the distributed processing device 100-n in this example includes a CPU (Central Processing Unit) 11, an input unit 12, an output unit 13, an auxiliary storage device 14, a ROM (Read Only Memory) 15, and a RAM. (Random Access Memory) 16 and a bus 17 are provided.

  The CPU 11 in this example includes a control unit 11a, a calculation unit 11b, and a register 11c, and executes various calculation processes according to various programs read into the register 11c. The input unit 12 is an input interface for inputting data, a keyboard, a mouse, and the like. The output unit 13 is an output interface for outputting data, a display, a printer, and the like. The auxiliary storage device 14 is, for example, a hard disk, a semiconductor memory, or the like, and stores programs and various data for causing the computer to function as the distributed processing device 100-n. Further, the above program and various data are expanded in the RAM 16 and used by the CPU 11 or the like. The bus 17 connects the CPU 11, the input unit 12, the output unit 13, the auxiliary storage device 14, the ROM 15, and the RAM 16 so that they can communicate with each other. In addition, as a specific example of such hardware, a server apparatus, a workstation, etc. other than a personal computer can be illustrated, for example.

<Program structure>
As described above, each program for executing each process of the distributed processing device 100-n of the present embodiment is stored in the auxiliary storage device 14. Each program constituting the checkpoint creation program may be described as a single program sequence, or at least a part of the program may be stored in the library as a separate module.

<Cooperation between hardware and program>
The CPU 11 expands the above-described program and various data stored in the auxiliary storage device 14 in the RAM 16 according to the read OS program. The address on the RAM 16 where the program and data are written is stored in the register 11c of the CPU 11. The control unit 11a of the CPU 11 sequentially reads these addresses stored in the register 11c, reads a program and data from the area on the RAM 16 indicated by the read address, causes the calculation unit 11b to sequentially execute the operation indicated by the program, The calculation result is stored in the register 11c.

  FIG. 3 is a block diagram illustrating a functional configuration of the distributed processing device 100-n configured by reading and executing the above-described program in the CPU 11 in this manner.

Here, the storage unit 103 corresponds to any one of the auxiliary storage device 14, the RAM 16, the register 11 c, other buffer memory and cache memory, or a storage area using these in combination. Also, service thread means 110-m, checkpoint thread means 130
The flag thread 140-r is configured by causing the CPU 11 to execute a checkpoint creation program.

  The checkpoint created in the present invention can be used for rollback.

DESCRIPTION OF SYMBOLS 10 Distributed system 100-n Checkpoint creation apparatus 103 Storage means 110-m Service thread means 130 Checkpoint thread means 140-r Flag thread means

Claims (4)

A checkpoint creation device that configures a distributed system and proceeds with processing while creating checkpoints,
One or more service thread means for performing processing in response to a request of an application or other service thread means operating on the distributed system;
A stop flag indicating whether or not the service thread means operating on the checkpoint creation device is to be stopped, an execution list which is a list of service thread means operating on the checkpoint creation device, and the checkpoint creation Storage means for storing a stop list that is a list of the service thread means that has stopped operating on the device, and a request log that includes an execution history of each service thread means;
Stable storage means that is a storage area that is not lost by failure;
Checkpoint thread means for updating the stop flag;
Flag thread means for referring to the stop flag,
The checkpoint thread means operates a stop flag on the checkpoint creation device when a marker reaches the checkpoint creation device for the first time or when the checkpoint creation device starts a snapshot. When the service thread means stored in the execution list and the stop list coincides with the stop flag that means stop of the service thread means, the request log is stored in the stable storage means.
A checkpoint creation device characterized by that. A checkpoint creation system comprising one or more checkpoint creation devices that process while creating a checkpoint,
Each of the checkpoint creation devices constituting this checkpoint creation system is:
One or more service thread means for performing processing in response to a request of an application or other service thread means operating on the checkpoint generation system;
A stop flag indicating whether or not the service thread means operating on this checkpoint creation device is stopped, and a list of transmission destinations of marker messages transmitted and received between checkpoint creation devices constituting the checkpoint creation system A marker list, an execution list that is a list of service thread means operating on the checkpoint creation device, and a stop list that is a list of service thread means that has stopped operating on the checkpoint creation device; A storage unit for storing a request log including an execution history of each service thread unit;
Stable storage means that is a storage area that is not lost by failure;
Checkpoint thread means for transmitting and receiving the marker message and updating the stop flag and the marker list;
Flag thread means for referring to the stop flag,
The checkpoint thread means of each checkpoint creation device checks the stop flag when a marker arrives for the first time from another checkpoint creation device or when this checkpoint creation device starts a snapshot. When the service thread means stored in the execution list and the stop list coincides with the stop flag that means stop of the service thread means operating on the point creation device, the request log is stored in the stable storage means, The stop flag is set to a stop flag that does not mean stop of service thread means operating on the checkpoint creation device, the stop list is reset, and a marker message is transmitted to other checkpoint thread means.
A checkpoint creation system characterized by that. A checkpoint creation method for a distributed processing device constituting a distributed system,
One or more service threads, one or more flag threads, and a checkpoint thread operate on the distributed processing device, and whether or not the stop flag means stop of a service thread that operates on the distributed processing device The execution list is a list of service threads operating on the distributed processing device, the stop list is a list of service threads that have stopped operating on the distributed processing device,
A service thread step in which the service thread performs processing in response to a request of an application or other service thread operating on the distributed system;
A request log storage step for storing an execution history of each service thread as a request log;
A service thread that operates the stop flag on the checkpoint creation device when the checkpoint thread first reaches the distributed processing device or when the distributed processing device starts a snapshot. Updating to something that means stopping,
Before the service thread performs processing on demand, or the flag thread refers to the stop flag periodically, and the stop flag means stop of the service thread that operates on the checkpoint creation device. If there is a step to stop processing of the service thread;
A stable storage step of storing the request log in a storage area that is not lost due to a failure when the service threads stored in the execution list and the stop list match.
A checkpoint creation method characterized by this.   A program for causing a computer to function as the checkpoint creation apparatus according to claim 1.

Images