Patent Grant
7921319
The present invention generally relates to clock virtualization for replication of applications or operating systems executing on a computer; more particularly, the present invention provides a deterministic virtual clock allowing an efficient replication of clock access requests which are non deterministic.
Replication on one replication machine of programs executing on an operational machine includes record and replay of events that produce non deterministic results. For events producing non deterministic results which are recorded on the operational machine the event information is transferred from the operational machine to the other machine for replay. The impact is overhead on the machines and communication cost for transfer of event information. Events producing deterministic results during a program execution are not recorded as they can be reproduced by simple checkpointing and re-execution of the program on the replication machine after restoring the checkpointed environment.
During the execution of a program, when the system clock is accessed, it typically produces a non deterministic event which is recorded in the operational machine, transferred from the operational machine to the replication machine and replayed in the replication machine using the event information. This standard solution could be acceptable when replication of programs is performed for debugging of these programs. In this case the operational machine for application recording and the replication machine for application replay may be the same machines, the replay being definitely a ‘later replay’. This standard solution may be also acceptable when replication is done for legal archiving purpose. For fault tolerant system, wherein executing programs need to be restored on a backup machine in case of failure of the operational machine, this standard solution is not acceptable as the fault tolerant system needs an immediate switch from the operational machine to a backup machine in case of failure. The backup machine is maintained active, the operational machine performs records of event data and periodic transfer of these data to the backup machine. The backup machine uses each event data transfer at each transfer to replicate the program execution.
In the rest of the document replication of executing programs may designate replication per application or per operating system depending on the type of virtualization technology.
If the application to be replicated implements communication protocols or transactional applications such as server applications, it implements intensive accesses to the clock, may be up to several thousands accesses to the clock per second, which leads to an important slow down of the replication process. This is a strong problem when replication is used in a fault tolerant system, wherein an application runs on a operational machine and its execution is immediately and entirely replicated on a second machine in order to immediate recover, in case of primary machine failure.
Hardware based solutions are the most reliable solutions for fault tolerant systems with on the fly recovery and they are successful today. A so called ‘lockstep mode’ of replication consists in replicating instruction by instruction execution on two synchronous CPUs on one unique clock. It allows a single physical clock to drive several processors, by extending the bus between 2 motherboards and forwarding the clock signal. It implies a clock transfer at 10 MHz rate on an optical fiber the operational and backup computer systems being tightly coupled. This mode does not allow the computer systems to be really distributed. It also requires homogeneous replica systems (same processors running at the same speed). The Integrity NonStop Servers which have Itanium based processors of Hewlett-Packard use additional redundant CPUs running the same instruction stream. When a fault is detected (e.g. by lockstep mismatch), the failing module is disabled while the redundant module continues processing the instruction stream without interruption. The Stratus© ftServers© of Stratus Technologies are similar. This hardware based fault tolerant systems have some physical constraints such as that the operational and backup systems must be in the same building. Furthermore, the hardware solution implies replicating the entire physical system and does not provide the granularity of virtualization by application as done with software implementable solutions.
In order to avoid the hardware limitations, it seems preferable to come back to a software implementable solution. It is needed to find a way to replicate virtualized application in a fault tolerant way while avoiding record, transfer and replication of each system clock access request in the virtualized application because it is too costly.
The patent application WO2006/079623 ‘Method for counting instructions for logging and replay of a deterministic sequence of events’ assigned to International Business Machines Corporation, deals with a ‘record and replay’ virtualization of applications which is a pure software implementable virtualization solution. For fault tolerance purpose a backup machine needs to be always maintained in the same status than the operational machine. The application code executing on the operational machine can be replayed by reexecuting the application code in the backup machine. However, this is theoretical because the events (interruption signal, system calls etc. . . . ) occurring during code execution cannot be ‘reexecuted’ on the replication machine. The occurrence of an event needs immediate recording, transfer to the backup machine of the event data and replay of the event on the backup machine. To avoid this costly record transfer and replay steps at each occurrence of a deterministic event which can be identified by its point in the instruction execution flow, the patent application suggests identifying the event occurrence by the number of instructions already executed by the application code. In this way, during the reexecution of the application code in the backup machine, the occurrence of each event can be reproduced by counting the number of instructions already executed in the application code. In the replication machine, an overflow of the user instruction count (provided by the processor as described hereunder) is initialized beforehand in order to determine a number of instructions having to be executed from the start of the replay period and the overflow of which causes an interruption of the replay task. It is sufficient to maintain in each machine a synchronized counter of user instructions executed in the code. To this effect, the performance monitor unit provides the user instruction count (uic) that is the number of instructions executed in the user space without counting the instructions executed in the kernel space. The cited patent application proposes a way of counting exactly the uic for each task in the operational machine and to maintain synchronization of the uic in the backup machine. This implies an exact replication of the application in the backup machine by simple reexecution of the application code including the deterministic events for which the exact point of execution is pointed out by the uic value. More precisely, the uic is maintained in synchronization in the PMC of the operational and the replication machines. The uic is reset to zero at each occurrence of an event, thus avoiding uic counter overflows. Thus, to replay the virtualized application, the backup machine reexecutes the code of the application, including deterministic events, until the occurrence of a non deterministic event. A non deterministic event are replayed from the log.
System clock accesses are non deterministic events because the values returned by the system clock are different each time the system is accessed. Thus, the solution of the cited patent application does not allow replication of non deterministic events such as system clock access requests by simple reexecution of the application code in the backup machine that is without replaying the event from the log.
There is thus still a need for providing a solution for replicating accesses to system clock in a way usable for fault tolerant system configurations.
The object of the present invention is to provide a solution for replicating clock access requests in an efficient and reliable way in order to allow its use in fault tolerant system configurations.
This object is reached with a method for providing a virtual clock on an operational computer having one program executing, comprising:
reading p, a period in number of user instructions;
computing, before the first period of execution of the program, A0, the initial average duration of one instruction using a sample of user instruction executed read from the user instruction count (uic) of the operational computer;
reading R0, the system clock value at starting of the execution of the program;
computing the virtual clock value V(x) corresponding to a given number of user instructions x already executed in the program inside the first period (0≦x<p),
V0(x)=A0*x+R0,
x being read from the uic of the operational computer;
at the end of each nth period (counting from the first period where n=1), computing the virtual clock value Vn−1(np), reading the system clock value (Rn) and computing a new value of the average duration of an instruction, An, as a function of Rn, Rn−1 and Vn−1(np) so that at the end of the nth period, the difference between the virtual clock value and the system clock value is minimal;
for a x value of the uic corresponding to any given number of user instructions x already executed in the program inside a nth period (starting from the first period where n=1) n*p≦x≦(n+1)*p), computing the virtual clock value Vn(x)=An*(x−n*p)+Vn−1(np).
This object is also reached with the method for providing a virtual clock on an operational computer, further comprising:
executing the program on a replication computer;
making the uic of the replication computer synchronized with the uic of the operational computer;
making the storing means content accessible from the replication computer;
reading A0, R0=B0 and p from the storing means;
computing the virtual clock value V0(x) corresponding to any given number of user instructions x already executed in the program inside the first period (0≦x<p) V(x)=A0*x+B0;
for a x value of the uic corresponding to any given number of user instructions x already executed in the program inside a nth period (starting from the first period where n=1) n*p≦x<(n+1)*p), reading An and Bn from the storing means and computing the virtual clock value for any uic value (x) read on the operational computer inside the n period Vn(x)=An*(x−n*p)+Bn.
The object is also reached with the methods as claimed in claims 2 to 8 and claims 10 to 17 for providing a virtual clock on an operational computer.
The object is also reached with the system of claim 18.
With the method of the present invention, the system clock accesses performed by the programs executing in an operational machine can be replicated on a replication immediately without transferring system clock value at each system clock access request. To make the system clock access a deterministic event, a computed clock is provided to the system clock access requester instead of the system clock. As the time is computed from the uic which is maintained between the operational and the replication machines, clock accesses can be reexecuted as a deterministic event according to the solution of the cited prior art patent application. As the virtual clock provided to the executing program depends on the state of the executing program and the operating system in the operational machine, it can be retrieved by re-executing the application in the replication machine. The non deterministic events of system clock accesses have become deterministic events, this makes the replication process much more efficient.
Replacing the system clock by a virtual clock has been already proposed, also in the domain of virtualization, but for a different purpose. It has been suggested by one developer of QEMU which is virtualization program based on operating system emulation, in the Web page: http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00459.html
to provide a virtual clock, instead of the system clock, to operating systems emulated on an operational machine. The problem was to minimize the difference between the system clock of the operating system (host) and the system clock of the emulated operating system (guest). It is suggested to use a virtual clock computed using the number of instructions actually executed by the emulated operating system.
However, if this virtual clock can satisfy some needs for synchronization between processes, it cannot be used for replication of applications in fault tolerance systems. As a matter of fact, a virtual clock based on the number of instructions executed by a process is a linear function of the number of instructions which diverges quickly from the system clock. This prevents from using this QEMU developer clock for replicating the virtualized program by reexecution of program code on a replication machine in a fault tolerant system.
The virtual clock of the present invention is exactly synchronized on the system clock and because the errors of rounding are suppressed, it is thus reliable and thus can be used for fault tolerant system configurations.
With the method of the present invention, there is no need to record and transfer system clock information between the operational and a replication machine at each system clock access request. Thus, this solution limits the processing time in the operational machine for recording (store system clock and transfer to the standby machine) and it consequently limits the latency time of the application which is virtualized in the operational machine. It further limits the communications cost for transferring system clock access event information between the operational and the replication machine. The efficiency of the method allows also use for on the fly replication in fault tolerant system configurations.
As explained later in the document, compared to the existing software virtual clocks for synchronizing the clocks of distributed systems, the virtual clock used by the invention to make the system clock accesses deterministic, is exactly synchronized on the system clock. This is why this clock can be used in the fault tolerant environment which requires the use of a clock exactly synchronized with the system clock of the machines on which the record and the replay are executed.
The deterministic virtual clock can be advantageously used also each time there is a need for clock synchronization between distributed systems. In the domain of virtualization, this virtual clock can be used when virtualization is based on replication of applications or replication of virtual machines or hosted operating systems.
As this method may be software implemented, there is no hardware limitations like the ones that are imposed today by the current hardware fault tolerant systems.
The solution of the invention which has its main benefit with fault tolerant systems having an active-active architecture can be also used with replay later systems having active-passive architectures. In this case, the replication is not immediate. The same comment is valid also when the replication is performed for debugging or legal archiving purpose.
It is noted that different types of system clock access requests can be performed by programs and intercepted as described in the preferred embodiment. One example described above is when a system call to the system clock is executed in the program. The second case is when a machine instruction for reading the system clock is executed. For virtualization purpose, this machine instruction is instrumented to execute an exception handler which computes and returns a virtual clock value. In the rest of the document a ‘system clock access request’ stands for any type of request as presented in here above.
The virtual clock program computes a virtual clock value and returns it to the requesting program (145). For virtual clock computation, the virtual clock program accesses (125) the system clock (120). Some information is logged, for instance, in a file (140) during the recording on the operational machine. This data (and only this data) will be transferred to the replication machine for replay of the system clock accesses. The replication machine will store the transferred data to replay the clock accesses, starting from the checkpointed status of the virtualized application and re-executing the code using the transferred data (140).
Two logical blocks of the virtualization environment (150, 160) of the preferred embodiment are also illustrated in
The computation of the reliable virtual clock is as follows: applying the concept of virtual clock computation based on uic, one can obtain a theoretical value of the virtual clock with the following formula:
V=A*x+B (1)
where A is the average duration of a user instruction in seconds, x is the number of instructions measured at the time of per second and B is the time provided by the real clock when x is set to 0, that is at starting of virtualization of the application when the virtualization container is created. Formula (1) being a monotonic increasing function, it satisfies the criteria for a clock. In order to avoid overflow problems, it is sufficient to periodically reset x and read a new value of B.
One imposes a validity limit to the initial parameter A for a period p expressed in number of user instructions. At the end of the period, a new A, the deviation against the real system clock is measured and a new value A is computed to compensate the virtual clock deviation in the next period. For the nth period of p user instructions, counting from 0, i.e. with any value of x satisfying n*p≦x<(n+1)*p, we have the formula:
Vn(x)=An*(x−(n*p))+Bn (3)
At the beginning of the nth period, x is equal to n*p and
Bn=p*An−1+Bn−1 (6)
and therefore
Where B0 is the time provided by the real clock at the beginning of the first period (when n is equal to 0). The virtual clock depends only on B0 and the successive values of A:
This last formula could be used for computing the Vn(x) values in the operational and replication computers but the computers rather use the (3) formula which is iterative and thus less costly to implement.
We want to keep the virtual clock deviation minimal and to have the virtual time values equally distributed around the real time. In
dn=|Bn−Rn| (9)
where Bn is the virtual clock value and Rn is the real clock value measured at the end of the nth period ((n−1)*p≦x<n*p)
Bn=Vn−1(np)
The real clock value can be expressed in a similar way to the virtual clock value in (6):
Rn=p*ALPHAn−1+Rn−1 (10)
Where ALPHAn−1 is the real clock rate during the nth period.
We compute An such as the deviation dn+1 becomes null at the end of the nth period:
dn+1=|Bn+1−Rn+1|=0 (11)
Which is equivalent to:
Bn+1=Rn+1 (12)
We use (6) and (10) to transform this into:
p*An+Bn=p*ALPHAn+Rn (13)
Which is equivalent to:
An=ALPHAn+(Rn−Bn)/p (14)
We extrapolate the new real clock rate, assuming that ALPHAn is equal to ALPHAn−1, to calculate the new virtual clock rate:
An=ALPHAn−1+(Rn−Bn)/p (15)
We can see that the new virtual clock rate An is of the same order of magnitude than the previous real clock rate ALPHAn−1 with a compensation factor proportional to the previous deviation.
For n>0 the real clock rate ALPHAn−1 can be replaced with its value, from (10):
An=(Rn−Rn−1)/p+(Rn−Bn)/p
An=(2Rn−Rn−1−Vn−1(np))p (16)
Using (7):
This last formula is not used for computing the An values in the operational computer because the computer rather uses the (16) formula which is iterative and thus less costly to implement.
Consequently, the computation of virtual clock performed by the virtual clock program (130) is initialized with a value of p, in number of user instructions which is the period of computing virtual clock deviation compensation. Then, during a sampling period a value of B which is the real system clock value is read when the virtualization container is started and an initial value of A which is the an average of the UIC (User Instruction Count) values given by the Performance Monitor Unit during the execution of the first user instructions executed during the first period of execution of the application.
At each new period pn, the real system clock Rn is read and a new value of the average duration of a user instruction ALPHAn−1 is computed according to formula (10) and the new value of virtual clock rate An is computed according to formula (16).
At each system clock access intercepted by the virtualization program, the uic is read (x) and the virtual clock is computed using the formula (8).
This value to be final is rounded as described later in the document in reference to
One other embodiment consist in logging at each period not only An but also the computed Bn=V1−1(np) value. In this case step, 330 consists in ‘Log An and Bn, transfer Log’. In this second embodiment, An and Bn values will be transferred to the replication machine and, in the replication machine, the two values An and Bn will be read from the log (
round(1.499)=1 in the operational machine and,
round(1.500)=2 in the replication machine.
This error of 1 unit of virtual time is not acceptable for deterministic replay. For this reason, if e is the absolute value of the maximal error of the PMC when a uic value x is in an uncertainty window such that
n+0.5−2e≦x≦n+0.5+2e
n being any integer,
(answer yes to test 400),
in this case, the rounding of the uic is performed in the operational machine only, and the virtual clock value is logged and transferred to the replication machine thus creating a non deterministic event. This event will be replayed in the replication machine without recomputing the virtual time from the uic, when the uic value y on the replication machine belongs to the interval
n+0.5−e≦y≦n+0.5+e
where n is an integer.
When y does not belong to the interval, the virtual time is calculated from the uic value y. The uncertainty window on the operational machine is the double of the uncertainty window on the replication machine, in order to guarantee the availability of the pre-calculated virtual time in case it is needed by secondary.
If we estimate the average duration of a user instruction to be 1 nanosecond, and the error of PMC to be e=250 instructions, then the uncertainty window on the operational machine will be 1 microsecond (half of it on the replication machine). The virtual clock unit being 1 microsecond, the probability of hitting the rounding uncertainty interval is 10−3 (1 per thousand). The overhead of having to transmit the virtual time from the operational machine to the secondary machine is therefore bounded by this very low probability.
It is noted that reexecution of code in the replication machine starts at each occurrence of a non deterministic event. In the operational machine the application code is executed until a non deterministic event occurs. When a non deterministic event occurs, the event information are sent to the replication machine which reexecutes the code of the application until the occurrence of the non deterministic event which is entirely replayed by checkpointing the application with the event data received from the operational machine. The process of virtual clock computation as illustrated in
It is noted that according to the second embodiment of the virtual clock computation program (130) in the operational machine, if the Bn value is read from the Log in step 630, there is no need to recompute Vn−1(np). In this case, step 630 is only read An and Bn from Log.
n+0.5−e≦x≦n+0.5+e
n being any integer,
(answer yes to test 400), the virtual clock is not computed but read from the Log (730). This value is sent to the application code (step 145 in the flowchart of
| Number | Date | Country | Kind |
|---|---|---|---|
| 06301273 | Dec 2006 | EP | regional |
| Number | Name | Date | Kind |
|---|---|---|---|
| 7334014 | Moser et al. | Feb 2008 | B2 |
| 7756697 | Nakamura | Jul 2010 | B2 |
| 20040205372 | Moser et al. | Oct 2004 | A1 |
| 20060259818 | Howell et al. | Nov 2006 | A1 |
| 20070010988 | Nakamura | Jan 2007 | A1 |
| Number | Date | Country |
|---|---|---|
| 2881244 | Jul 2006 | FR |
| Number | Date | Country | |
|---|---|---|---|
| 20080155299 A1 | Jun 2008 | US |
