BERGHEAUD, Philippe (34 avenue Georges Clemenceau, Colmar, Colmar, F-68000, FR)
SUBHRAVETI, Dinesh (1189 Sunrise Way, Milpitas, CA, 95035, US)
COMPAGNIE IBM FRANCE (Tour Descartes, La Défense 5, Avenue Gambetta Courbevoie, F-92400, FR)
VERTES, Marc (858 chemain Giraoudeou, Saint Lys, Saint Lys, F-31470, FR)
BERGHEAUD, Philippe (34 avenue Georges Clemenceau, Colmar, Colmar, F-68000, FR)
SUBHRAVETI, Dinesh (1189 Sunrise Way, Milpitas, CA, 95035, US)
| Claims
1. A method executing on a computer system for replicating program executing on said computer system having a first storage means, one destination being accessible from said computer system, said method comprising the steps of:
- if a non deterministic event occurs, blocking the request from an executing program corresponding to that event;
- testing if the non deterministic event corresponds either to a message which is an input for the executing program to be replicated or if it corresponds to a request from an executing program for sending an output message (so called Non Abortable Event or NAE) ;
-if no NAE notification occurs, logging the event in the first storage means, delivering the event to the executing program to be replicated and unblocking the input request;
- if an NAE notification occurs, transferring the first storage means content to the destination, waiting for acknowledgment and, when acknowledgment is received, unblocking the output request and going to first step.
2. The method of claim 1 further comprising after the logging step : if said first storage means is full, transferring the first storage means content to the destination, waiting for acknowledgment and, when acknowledgment is received, unblocking the executing program request and going to first step .
3. The method of claim 1 or 2 further comprising after the logging step: if a timer, reset at each occurrence of a NAE notification, expires, transferring the first storage means content to the destination, waiting for acknowledgment and, when acknowledgment is received, unblocking the input request and going to first step.
4. The method of any one of claims 1 to 3 wherein if an NAE notification occurs, the following replacing steps are executed:
- writing the NAE in a second storage means and executing in parallel the following steps:
- unblocking the executing program request and going to first step; and, in parallel, - transferring the first storage means content to the destination, waiting for acknowledgment and, when acknowledgment is received, performing the request, removing the NAE from the second storing means and going to first step.
5. The method of claim 4 further comprising if an NAE notification occurs: if said second storage means is full, re-testing if said second storage means is full until a removing step is executed and said second storage means is no more full.
6. The method of anyone of claims 1 to 5 wherein if an NAE notification occurs the following replacing steps are executed:
- if said second storage means is not full, writing the NAE in a second storage means, unblocking the executing program request and going to first step;
- if said second storage means is full, for all the NAEs in the second storage means and the last NAE, transferring the first storage means content up to this NAE to the destination, waiting for acknowledgment and, when acknowledgment is received performing the request, removing the NAE from the second storing means and going to first step.
7. The method of any one of claims 1 to 6 wherein the logging step in a first storage means is performed in a FIFO.
8. The method of any one of claims 4 to 7 wherein the writing step in a second storage means is performed in a cache memory.
9. The method of claim 6 the writing step in a second storage means is performed in a cache memory having more than one entry.
10. A computer program product comprising programming code instructions for executing the steps of the method according to any one of claims 1 to 9 when said program is executed on a computer .
11. A system comprising means adapted for carrying out the method according to any one of claims 1 to 9. |
METHOD FOR IMPROVING TRANSFER OF EVENT LOGS FOR REPLICATION OF EXECUTING PROGRAMS
Field of the Invention
The present invention generally relates to replication of executing programs from an application or modules of an operating system; more particularly, the present invention optimizes the process of recording events and transferring them from a primary machine on which programs are executed to a standby computer system.
Background of the Invention
It may be desirable to entirely replicate on a second machine, an application or an operating system running on a primary machine. Replication may be needed for program debugging purpose. Replication may be also needed for balancing workloads of systems for system management purpose. Also, replication can be needed because of a failure of the primary machine, the second machine, the standby machine, being used in replacement of the primary machine. System management and Fault Tolerant (FT) systems using replication
have a need for performance. An instant replication is even required in these cases.
The replication is achieved by record and replay of events that produce non deterministic results. Events producing deterministic results are not recorded, as they can be reproduced by simple re-execution of the programs on the standby machine. Applications implementing communication protocols or transactional applications, such as server applications which communicate with outside world, receive input information candidate to event logging for replication and generate output information. The output events have no need of being logged, they are just replayed by re-executing the application in the standby machine. On the contrary, when an internal or external input event occurs, the event is first locally logged and transferred to the standby system. The data transferred can be used immediately in an active-active FT model or used for a replay later in an active-passive FT model. The transfer of logged event data recorded on the primary system to the standby system where they will be replayed, must be done safely and efficiently.
It is always desirable and necessary for replication in fault tolerant systems, to improve the efficiency of the main stream record of events in logs and transfer of this log. Assuming that we are able to implement record and replay locally on the primary machine, by storing the event log on the local storage system, the next step to achieve fault-tolerance is to be able to transfer in real-time all the necessary data (recorded events) to the standby machine. The most costly step in the process of replication for fault tolerant systems is this transfer of information between the primary and the standby systems; local logging costs around a few nanoseconds on lGo/s memory throughput CPUs as acknowledged transfer costs around dozens of microseconds on Ethernet Gbit link.
However, the process must be done safely, this requirement being achieved if the standby system is able to recover from a failure of the primary system no matter when the failure occurs. In case of failure of the operational machine, all the data must be made available for replaying the application until the point where the failure occurred, and then, the application can resume on the standby with no visible interruption from the external world. During the execution of the application on the operational machine, a failure may happen at any moment. In particular, a failure may impact the log transfer itself, inducing the loss of critical replay data.
Existing log transfer systems have been designed, which are fast but unsafe, by not ensuring data integrity; such fast and unsafe solutions are not acceptable for FT systems. An example of such fast and unsafe protocol is UDP or Multicast
IP, as used in multimedia stream broadcast systems.
Other standard solutions are safe but slow. One example is the TimesTen Database Transaction replication protocol over
TCP-IP, by Oracle, when used in synchronous mode to ensure fault tolerance. To avoid the negative impact of the loss of the last recorded event, a possible solution, so called in the rest of the document the standard solution, is to transfer any event to the standby prior to its processing by the application on the operational primary machine. The primary machine, then, receives non-deterministic events or results only after they have been transmitted to the standby. This standard solution implies a latency in the application which corresponds to the logging and transfer of events, followed by the transfer and reception of the acknowledgment. This standard solution imposes a lot of serialization points in the application execution, or a large amount of data to be
frequently transferred. Each input is delayed before being provided to the application.
There is a need for improving efficiency of event logging and transfer while preserving data integrity applicable for instance when replicating an application in fault tolerant systems .
Summary of the Invention
It is an object of the present invention to reduce waiting time during log and transfer of events occurring during execution of programs, for instance of an application, by improving efficiency of processing these during replication, for instance in a Fault Tolerant system.
The solution includes a characterization of the Non Abortable Events (NAEs) . Non Abortable Events are external events (non deterministic output events) which constitute non return point. The Non Abortable Events change irremediably the state of the external world, that cannot be rollbacked, even if the primary machine itself can be rollbacked. In one additional feature of the solution a λ write cache' is used for storing an NAE or some NAEs.
The object of the invention is reached, according to Claim 1 with a method executing on a computer system for replicating program executing on said computer system having a first storage means, one destination being accessible from said computer system, said method comprising the steps of: - if a non deterministic event occurs, blocking the request from an executing program corresponding to that event; - testing if the non deterministic event corresponds either to a message which is an input for the executing program to be replicated or if it corresponds to a request from an executing
program for sending an output message (so called Non Abortable
Event or NAE) ;
-if no NAE notification occurs, logging the event in the first storage means, delivering the event to the executing program to be replicated and unblocking the input request;
- if an NAE notification occurs, transferring the first storage means content to the destination, waiting for acknowledgment and, when acknowledgment is received, unblocking the output request and going to first step.
The object of the invention is reached, according to Claim 2 with the method of claim 1 further comprising after the logging step: if said first storage means is full, transferring the first storage means content to the destination, waiting for acknowledgment and, when acknowledgment is received, unblocking the executing program request and going to first step .
The object of the invention is reached, according to Claim 3 with the method of claim 1 or 2 further comprising after the logging step: if a timer, reset at each occurrence of a NAE notification, expires, transferring the first storage means content to the destination, waiting for acknowledgment and, when acknowledgment is received, unblocking the input request and going to first step.
The object of the invention is reached, according to Claim 4 with the method of any one of claims 1 to 3 wherein if an NAE notification occurs, the following replacing steps are executed:
- writing the NAE in a second storage means and executing in parallel the following steps:
- unblocking the executing program request and going to first step; and, in parallel,
- transferring the first storage means content to the destination, waiting for acknowledgment and, when acknowledgment is received, performing the request, removing the NAE from the second storing means and going to first step.
The object of the invention is reached, according to Claim 5 with the method of claim 4 further comprising if an NAE notification occurs: if said second storage means is full, re-testing if said second storage means is full until a removing step is executed and said second storage means is no more full.
The object of the invention is reached, according to Claim 6 with the method of anyone of claims 1 to 5 wherein if an NAE notification occurs the following replacing steps are executed:
- if said second storage means is not full, writing the NAE in a second storage means, unblocking the executing program request and going to first step;
- if said second storage means is full, for all the NAEs in the second storage means and the last NAE, transferring the first storage means content up to this NAE to the destination, waiting for acknowledgment and, when acknowledgment is received performing the request, removing the NAE from the second storing means and going to first step.
The object of the invention is reached, according to Claim 7 with the method of any one of claims 1 to 6 wherein the logging step in a first storage means is performed in a FIFO.
The object of the invention is reached, according to Claim 8 with the method of any one of claims 4 to 7 wherein
the writing step in a second storage means is performed in a cache memory.
The object of the invention is reached, according to
Claim 9 with the method of claim 6 the writing step in a second storage means is performed in a cache memory having more than one entry.
The object of the invention is reached, according to
Claim 10 with a computer program product comprising programming code instructions for executing the steps of the method according to any one of claims 1 to 9 when said program is executed on a computer.
The object of the invention is reached, according to Claim 11 with a system comprising means adapted for carrying out the method according to any one of claims 1 to 9.
The solution of the invention brings further advantages:
- with the present solution, there is no more waiting time upon reception of an input to the application, even if processing the output events is increased but in a lower measure. An application typically receives between ten and one hundred times more internal inputs than external inputs, but an application generates the same occurrence of external outputs as external inputs events. Therefore, by slightly impacting processing time of external events, one typically slows down one hundred times less than with the standard solution. Without changing the transfer protocol properties, and simply if log is transferred upon an occurrence of an external output event rather than an occurrence of an internal or external input event, then, overhead is greatly reduced.
- as with the standard solution, implementing the solution of the present invention does not imply any change in the application .
- the transfer protocol remains unchanged with the solution of the present invention. The FT system implementing the solution of the present invention can use a standard transfer protocol such as TCP which warranties data integrity. - finally, a strong advantage of the solution of the present invention is the possibility to be upgradable with an optional λ write cache' (deferred write strategy) which allows unblocking output requests from the application. Activating this option requires increasing storage capacity comparable to the size of the log with the standard solution.
- in the case of multicpu primary systems, the solution of the present invention allows full parallelism of transfer, one processor could be dedicated to log transfer without slowing down the application. On the contrary, with the standard solution because of the serialization of transfer and event delivery, a dedicated CPU is useless for improving performance .
Generalization of the use of the invention: the solution of the present invention, improving the performance of transfer of event log during replication, can be applied to any environment where replication is needed. Fault tolerant systems are taken as example as being very sensitive to performance. The invention is more useful for fault tolerant systems applying an active-active model, that is, having both the primary and standby machine in active mode. But the transfer of event log of the invention can be performed in fault tolerant systems implementing an active-passive model that is, having the primary machine in active mode and the standby machine in passive mode. Event log data may be sent by the primary machine towards a remote machine storing event log data for later replay in one other machine; this remote machine acknowledging to the primary machine reception of event log data. This configuration can be used for archiving purpose when, for instance, this is required by law.
the invention can be implemented as well to replicate application for debugging purpose even if this use is less sensitive to performance.
- finally, the example of replication of application taken in the document is sufficiently general to encompass any type of application. Replication is a solution for virtualization and there are many models of virtualization. In some models, the user applications are virtualized and thus can be replicated. In other models, the hypervisor on which operates the user applications are themselves virtualized and thus may be replicated. Finally, a virtual machine can be also virtualized and the entire virtual machine may in this case be replicated. In all the cases the improvement of the solution of the invention can be applied for the transfer of event log.
Brief Description of the Drawings
FIG. 1 illustrates a FT system implementing the standard solution of prior art for event log transfer;
FIG. 2 illustrates a FT model implementing a solution for event log transfer according to the preferred embodiment, transfer being triggered by each external output event;
FIG. 3 illustrates the data flows between primary and standby machine of the optional process using a write cache to defer the external output commit;
FIG. 4 is the general flowchart of the method of log transfer according to the preferred embodiment of the invention;
FIG. 5 is the general flowchart of the method of log transfer according to the preferred embodiment of the invention wherein an optional write cache memory containing one NAE is used;
FIG. 6 is the general flowchart of the method of log transfer according to the preferred embodiment of the invention wherein an optional write cache memory containing more than a NAE is used.
Detailed Description of the preferred embodiment
The replication of an executing programs consists in logging information concerning the execution of the programs at one point in time in a computer system in which the programs are executed. Then, the logged information is used in one other computer system to replay the programs and recreate the programs environment at that point in time in that other computer system. This replication is done for fault tolerant system, which objective is to maintain a standby machine ready for restarting at any time the execution of the programs. The replication can also be used for archival purpose or for programs. The replication applies usually to an entire application which is the best example taken in the rest of the description. It is noted that when an application is executed on a computer the executing programs may be programs from the application itself or other programs such as operating system modules executing for the application.
The logged information is a series of events, the events being sent or received by the modules of the application or the modules of the operating system operating in the computer system in which the application is executing. There is no need to log deterministic events as they can be replayed by simply re-executing the application. Non-deterministic events need to be logged because they will be re-injected during the replay of the application. The object is to have a minimum impact on execution of the application during the logging of events. The figures illustrate methods for logging events and transferring them for replication in a fault tolerant system, that is when
the logged events are transferred to a standby machine for immediate replay.
FIG. 1 illustrates, with a dialog between its different system components, a FT system implementing the "safe and slow" standard solution of prior art for event log transfer. In this solution, the event log transfer is triggered by each input event, that is for each non deterministic event received by the application and logged by the replication program which performs the record of the application on a primary machine and the replay of this application on a standby machine. In Fig. 1 the operational machine, the primary machine (110) executes an application (145) in the user space (135) . The replication program (140) performing the application record in the primary machine operates in the kernel space (130) of the system. When an input (155) is received for the application from the external world, the network (100) or as an internal input from one other process of the kernel (155), it is captured by the replication program (140) implementing the standard solution. The record part of the replication program creates a log of the captured event which is not detailed here but may be performed by any efficient way to record an event for its replaying in the replay phase of the replication. The replication program sends (160) the captured input event as an event log to the replay part of the replication program (140) operating in the kernel space of a standby machine (120) . Then, the replay part of the replication program in the standby machine acknowledges (165) the good reception of the event log transmission. Upon reception of the acknowledgment, the record part of the replication program in the primary machine can forward (170) the event to the application. In parallel, as this illustrates a fault tolerant system, the replay part of the replication program operating in the standby machine forwards (175) the event to the application operating in the standby machine in order to maintain it updated in case of failure. As noted sooner in the document,
the application executing on the primary machine receives the input event after a latency comprising the delay for capturing the input, logging it, forwarding the event and for receiving the acknowledgment of good reception by the standby machine. Even if this standard solution can be used for any situation where replication of application is required, in the case of fault tolerant system the two applications must be maintained in phase in real time, which means that a high speed communication is desired between the primary and the standby machine for transmissions (160, 165) . These may imply the use of different physical links from the standard network (100), such as optical fiber connections as shown in Fig. 1.
The problem of that standard solution resides in the latency of the log transfer and acknowledgment protocol, now imposed at each and every event occurrence, would it be from external or internal source. Even with high speed interconnect networks, this latency would be in the range of several microseconds (at best) , which is enormous compared to the initial duration of nanoseconds for internal events. The latency of event logging is located at the source of input data for the application. It first slows down the rate of external data for the application. It also makes the operating system very slow by transforming very frequent internal non-deterministic events in serialization points.
FIG. 2 illustrates a FT model implementing a solution for event log transfer according to the preferred embodiment. In the fault tolerant system of Fig. 2, the replication program of Fig. 1 has been modified (240) on the primary (110) and the standby (120) machines to implement the invention according to the preferred embodiment. When applying deterministic replay to fault tolerance of transactional systems connected to external clients (assuming that those remote communication peers can not be rollbacked) , an important point to notice is that a diverging behavior of the replica can be tolerated as
long as no message is sent to the external world. In a fault tolerant system based on concurrent processing, it means that the state of the replica must be identical to the original at the moment an external message is sent, by means of deterministic replay. If a failure occurs, all the non-deterministic events posterior to the last external message transmit can be ignored, and the replica still be consistent with the external world. Consequently, the output of an external message constitutes a non-return point. It is mandatory to ensure that the standby can reach that state, by having the standby acknowledging the reception of the log of non-deterministic event up to that point, prior to sending the external message. Let us generalize this concept with ' 'Non Abortable Events' ' (NAE), which are events that change irremediably the state of the external world, that we can not rollback (we could only rollback the server) . We can also define an ''Abortable Sequence of Events'' (ASE) as the list of all non-deterministic events that can be safely disregarded at standby recovery. They are all the events following the last NAE. A NAE, being by nature an output message, is not part of the event log, the output content being already determined by the replay system. It is rather a signal indicating that the event log must be committed to the standby before proceeding, to ensure recoverability . A consistent recovery of a transactional application interacting with the external world depends on the fact that critical log data has been committed at the time of Non Abortable Events, rather than at the non-deterministic event occurrence itself.
The two inputs received (150, 155) by the application (145) executing in the user space of the primary machine are not captured by the replication program (140) and reach the application. On the contrary, the record part of the replication program operating on the primary machine (140) captures the output (230) sent from the application which is a NAE. Then, the record part of the replication program creates
a log of the captured event which is not detailed here but may be performed by any efficient way to record an event for its replaying in the replay phase of the replication. The replication program sends (260) a signal to the replay part of the replication program (240) operating in the kernel space of the standby machine (120) . Then, the replay part of the replication program in the standby machine acknowledges (265) the good reception of the event log transmission. Upon reception of the acknowledgment, the record part of the replication program in the primary machine can forward (240) the output in the name of the application to the external world, the network (100) in this case. In parallel, as this illustrates a fault tolerant system, the replay part of the replication program operating in the standby machine forwards (175) the NAE event to the application operating in the standby machine in order to maintain it updated in case of failure. The output issued by the application is actually sent after a latency comprising the delay for capturing, logging, forwarding the event and for receiving the acknowledgment of good reception by the standby machine. With this new method, the log transfer serialization point is moved from any NDE (internal or external) input to output of NAE only.
With this solution, in some circumstances, the result of non-deterministic events can be forwarded to the application before sending them to the standby machine, as some entire sequences of events can be disregarded without impacting the consistency of the recovered application. A consequence is that sequences of non-deterministic events can be sent in ''batch' 1 , rather than one by one, thus reducing the impact of the transfer latency. The event log transfer is triggered by each external output event. This method removes internal serialization points due to event log transfer, by applying a strategy similar to caching, which speeds up the input operations and defers the physical write operations. The log transfer can run in parallel with the normal execution of the
application, instead of being serialized, reducing even more the impact of log transfer latency.
FIG. 3 illustrates the data flows between primary and standby machine of the optional process using a write cache to defer external output commit. This option of the solution brings an additional level of optimization by introducing parallelism in transfer of the event log with the execution of the application. The occurrence of a NAE is broken down in two steps. The first step is the notification of a NAE, triggering the action of event log flush to the standby until the state reached at NAE notification. The second step is the NAE physical commit, which is buffered and deferred until the acknowledgment from the standby is received. The processing on NAE is the following:
- The replication program in the operational machine (110) intercepts a NAE about to start (but not yet committed), i.e. the NAE notification (320) .
- Instead of being committed, the NAE is stored (330) in a temporary buffer, the NAE cache, and acknowledged to the module that posted the NAE, so that the application or operating system is not blocked.
- all the log events comprising the NAEs of the cache until the last NAE plus the logged ASE in the FIFO on the operational is transmitted (335) to the standby (120). - On the reception of the acknowledgment from the standby (340), the NAE is physically committed (345), and removed from the cache .
The ASE log of events (390) is replayed on the standby machine after log transfer (335)
Committing the log at external data output is sufficient to ensure consistency of recovery, allowing the transmission of event log in bursts of ASEs. Deferring the transmission of NAEs until reception of event log transmit acknowledgment
allows to make transfer parallel for event log and the further execution of operational application. The NAE delay
(350) comprises the Log latency (355) + the Acknowledgment latency (360) . The Replay delay (370) comprises the ASE latency (375) + the Log latency (380) . While this total latency is incurred only once per a set of several events contained in an ASE, an equivalent latency is incurred per each and every nondeterministic event, in the methods suggested in the prior art. By amortizing the overhead over a number of events, the proposed system achieves high performance .
FIG. 4 is the general flowchart of the method of log transfer according to the preferred embodiment of the invention. This method is implemented as a program in the operational machine as a part of the replication process of a set of programs (for instance from an application or it can be modules from an operating system) executing in an operational machine. This replication process consists in logging information on the execution of the application programs and transferring this information to the standby machine for replay of the application in that standby machine. The preferred embodiment is described in a fault tolerant system maintaining a concurrent processing in the operational and standby machines. The information logged and transferred consists in 'event' occurring between executing programs. These events may be internal or external to the operational machine, in input or output of the executing program. There is no processing required for deterministic events: deterministic event information has no need to be logged and transferred to the standby machine because it will be replayed in the standby machine by simple execution of the application. A non deterministic event could potentially lead to more than one resultant application states, then, this event needs to be logged and transferred to the standby machine for replay with this information. The first step consists in waiting for a
non-abortable event (NAE) notification or a nondeterministic event (NDE) (400) during execution of the application. A test for finding a non deterministic event is executed (410); such a test is implemented by selecting some types of events such as a system call for querying time which is a nondeterministic event. Then a test is executed to check if a so called NAE notification has occurred (420) . An occurrence of a NAE such as a request by an executing module of sending an output message from the operational machine implies that there will be an irreversible change of the state of the external world. In this case, there is a need to replicate this situation and the events already logged up to the NAE notification need to be immediately sent to the standby machine. If there is no notification of a NAE (answer No to test 410), and that a non deterministic event occurs, the non deterministic event can be safely disregarded at standby recovery, because there is no irreversible change of the state of the external world pending. This event needs to be logged in the operational machine. This non deterministic event could correspond to one executing program sending a request for an input message to the application. The input message is blocked (425) . The event (starting an ASE if occurring just after a NAE has been notified) is logged preferably in a FIFO (480) if the Log FIFO is not full (answer No to test 460) and, optionally, if a timeout, preferably set as Log flush timer, has not expired (answer No to test 470), the event is delivered to the application (490) and the requesting module is unblocked (495) in the operational machine. If the FIFO is full (answer Yes to test 460) the logging is not possible and one does not want to loose the event information. The use of a timeout is optional: if a NAE doesn't occur for a long time, it could be desirable to force the log flush (430) to ensure that the switchover time is small. A timer called log flush timer keeps track of the time interval between subsequent NAEs. The timer is reset each time a new NAE occurs: this is not mentioned in the general algorithm to avoid complicating the figures. It is
noted that any way of counting a timeout between two NAEs may be implemented with the same benefit to the method of he invention. In both cases (answer Yes to test 460 or answer Yes to test 470) the event log information needs to be transferred to the standby machine.
If a NAE notification occurs (answer Yes to test 420), this means that a request for sending an output message external to the application is performed by an executing module. This request is blocked (427) . The occurrence of a NAE means that a portion of the application state is to be published to the external world: in this case, the logged event records in the FIFO, up to the NAE notification, need to be transferred to the standby machine.
In the case where a NAE notification occurs (answer yes to test 420) or when the non-deterministic event which not a
NAE cannot be logged in the operational machine (answer Yes to test 460 or answer Yes to test 470), the content of the log is transferred (430) to the standby machine. The replication process waits in the operational machine until an acknowledgment of the transfer is received (440, answer No to test 450) . When the acknowledgment is received (answer Yes to test 450), the request for output (NAE notification) or input
(non deterministic event without any NAE notification) , is unblocked in the operational machine and the execution goes on. It is noted that the log transfer (430) is for an entire
ASE sequence between two NAEs if either the log is full or if the log flush timer expires.
FIG. 5 is the general flowchart of the method of log transfer according to the preferred embodiment of the invention wherein an optional write cache memory containing one NAE is used. The method implemented as a program in the operational machine, as a part of the replication process, uses a write cache in the operational machine for storing in a
cache the a NAE notification while acknowledging the module which had posted the NAE and thus avoiding to block the execution on the operational machine. Then, when the cache is full with one NAE and when a new NAE arrives, the event log transfer is performed up to the NAE, the unblocking of process having requested the output being blocked until reception of transmit acknowledgment. In parallel, the NAE physical commit is performed and the cache is freed.
FIG. 5 is the flowchart of the method of the preferred embodiment to which use of an optional write cache is added. This method is implemented as a program in the operational machine as part as the replication process, transferring information on the execution of an application to the standby machine, for replay of the application in the standby machine. The write cache option may be selected during a customization of the program. In this case, the operational system contains a write cache memory which is used to cache the NAE notification until the cache is full. In the case where the underlying operating system already provides a write cache (buffer cache in the case of file system, for example) , an additional write cache is not used. In that case, the flush of the cache provided by operating system would be the NAE. Compared to the method without operational write cache (steps 400 to 495) this method executed in the operational machine comprises new steps (500, 510, 530, 535, 540, 550) in relation with the use of write cache memory. If a NAE notification or a NDE occurs (400) and if it is not a NAE (answer No to test 420), the process is similar than with the preferred embodiment (415 420, 460, 470, 430, 440, 450, 470, 480, 490) even with the step of unblocking the input request (540 replacing 495 of Fig. 4) the request being always an input request in Fig. 5. If a NAE notification occurs (answer Yes to test 420), and the cache memory is not full (answer No to test 500), the event is logged in the write cache (510) and acknowledged to the module that posted the NAE requesting the
output message to be sent, so that the execution is unblocked (550) . In parallel to the execution of unblocking of output request 550), the log of events in the FIFO until the NAE notification, and containing the ASE, is transferred (430) to the standby machine. The replication process waits in the operational machine until an acknowledgment of the transfer is received (440, answer No to test 450) . When the acknowledgment is received (answer Yes to test 450), the NAE is read from the cache and physically committed (530) to the standby machine. Then the NAE is removed from the cache memory (535) .
While the NAE has not been removed from the cache because the commit has not yet completed, if another NAE notification occurs, the cache memory is tested as full (answer Yes to test
500) . A loop allows waiting for the cache to be freed and the test to become negative (answer No to test 500) .
FIG. 6 is the flowchart of the method of the preferred embodiment to which use of an optional write cache adapted to contain more than one NAE is added. This method is implemented as a program in the operational machine as part as the replication process transferring information on the execution of an application to the standby machine for replay of the application in the standby machine. The multiNAE write cache option may be selected during a customization of the program. In this case, the operational system contain a write cache memory large enough to contain more than one NAE which will be re-read, the NAE being stored until the cache is full. In the case where the underlying operating system already provides a write cache (buffer cache in the case of file system, for example) having the required capacity, an additional write cache is not used. In that case, the flush of the cache provided by operating system would be the NAE. Compared to the method with an operational write cache for storing one NAE only, this method executed in the operational machine comprises new steps (525, 555, 532) in relation with the use
of a multiNAE sized write cache memory. In Fig. 6, the NAE process differs in that, if the event is a NAE (answer Yes to test 420) and the cache memory is not full (answer No to test 500), the event is added in the write cache (510) and acknowledged to the module that posted the NAE, so that the execution is unblocked (520) . If the cache is full (answer yes to test 500) after a NAE notification has occurred, the log of events, the ASEs up to the different NAEs in the cache and logged in the FIFO are transferred (525) to the standby machine. The replication process waits in the operational machine until an acknowledgment of the transfer is received
(440, answer No to test 450) . When the acknowledgment is received (answer Yes to test 450), the NAE corresponding the acknowledged log transfer is physically committed (530) to the standby machine and the NAE is removed from cache (525) . If all the ASEs logged in the FIFO are not all transferred, the log transfer is repeated (525, 440, 450, 530, 535, 450) until all the log are transferred until the last NAE.
The three embodiments described in Fig 4, Fig. 5 and Fig. 6 can be used in a computer system performing replication for immediate transfer to a standby machine in case of a fault tolerant system comprising an operational machine maintaining a standby machine in case of failure. The same embodiments can be used if the transfer is done to a storage for recording application replication information to be replayed later on one other machine for archiving purpose. Or, the same embodiments can be used by a developer for testing the application and which will analyze all the logged and transferred events. The replication method can apply to programs executing for an application, the replication allowing in this case application container isolation. However, as already mentioned, this same method may apply for replicating modules of an operating system executing on the operational machine. This method applies to replication used for virtualization architectures based on hypervisors.
Next Patent: PLANT CONTAINER