Ako funguje VMware Fault Tolerance v momente vypadku primarneho servera?

Otazka:
What exactly happens on level of application in virtualized VM when there is big latency vLockstep interval and suddently primary crash? How this execution lag is replayed on secondary when primary is suddently down? Is it like even there is big vLockstep execution lag secondary host got logs locally everytime prepared for execution but it is waiting locally on secondary for real execution of logs on its CPU, is it like that?

Odpoved:
"If the primary VM fails, the backup VM should similarly go live, but the process is a bit more complex. Because of its lag in execution, the backup VM will likely have a number of log entries that it has received and acknowledged, but have not yet been consumed because the backup VM hasn’t reached the appropriate point in its execution yet. The backup VM must continue replaying its execution from the log entries until it has consumed the last log entry. At that point, the backup VM will stop replaying mode and start executing as a normal VM."

"Since it is no longer a backup VM, the new primary VM will now produce output to the external world when the guest OS does output operations. During the transition to normal mode, there may be some device-specific operations needed to allow this output to occur properly. In particular, for the purposes of networking, VMware FT automatically advertises the MAC address of the new primary VM on the network, so that physical network switches will know on what server the new primary VM is located. In addition, the newly promoted primary VM may need to reissue some disk IOs."

Este pripajam vysvetlenie od Krishna Raj Raja, Senior MTS, Performance Group
VMware Inc :

The vLockstep protocol ensures that the secondary always "at the least" has all the information to continue from the point where the primary made its last externally visible I/O (i.e. the last network transmit or disk write). This is accomplished by delaying (i.e. holding) network transmit and disk write operating at the primary until the the primary gets an acknowledgement from the secondary that it has recieved events preceding to the I/O (Note this doesnt mean that the secondary's execution has to be current, secondary still be could lagging in execution and could running from the log buffer)

So if primary dies at any point, the secondary will continue to run in replay mode until the log buffer becomes empty and then it will go live. From that point onwards the secondary will have its own non-deterministic execution. All of this is transparent to the guest OS and applications running on top of it. From the Application and operating system perspective nothing is changed, its always running and it wouldnt know if the execution has changed from determinstic mode to non-dterministic mode. From the client (the machine that is communicating with the VM) perspective, there would be a slight delay when the failover happens while the secondary catches up to the golive point (because secondary doesnt do any external I/O when it is not live). This delay is what we term as vLockstep interval. It would appear to the client that the VM is taking more time to respond. To avoid excessive delays we always make sure that the vLockstep interval never exceeds 1 sec. If it exceeds one sec, we throttle the primary to slowdown so that the secondary can catch up.