High availability via asynchronous virtual machine replication

1,634 views

Published on

Check my blog @ http://aknahs.wordpress.com/

Small resume of the paper High availability via asynchronous virtual machine replication.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,634
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
13
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

High availability via asynchronous virtual machine replication

  1. 1. High Availability viaAsynchronous VirtualMachine ReplicationReview by Mário Almeida (EMDC)SummaryHigh availability requires the usage of redundancy techniques that are capable of maintainingand switching to backups in case of failure. Commercial high availability systems generally usespecialized hardware and/or customized software to achieve this purpose.This paper describes a system called Remus. It provides OS and application agnostic highavailability on commodity hardware. It performs virtualization to migrate running VMs betweenphysical hosts, and extends the technique to replicate snapshots of an entire running OSinstance at very high frequencies between a pair of physical machines. It discretizes the systeminto a serie of replicated snapshots.Any transmitted network packets is not released until the system state that produced it has beenreplicated. It allows a single host to execute speculatively and then checkpoint and replicateits state asynchronously. System state is not made externally visible until the checkpoint iscommitted.Remus ensures that regardless of the moment at which the primary fails, no externally visiblestate is ever lost. It aims to make mission-critical availability accessible to mid- and low-endsystems.Remus goals: ● Generality - High availability should be provided as a low-level service, with common mechanisms that apply regardless of the application being protected or the hardware on which it runs. ● Transparency - High availability should not require that OS or application code be modified to support facilities such as failure detection or state recovery.
  2. 2. ● Seamless failure recovery - No externally visible state should ever be lost in the case of single-host failure. Failure recovery should be fast. Established TCP connections should not be lost or reset.Remus runs paired servers in an active-passive configuration. Speculative execution decouplesexternal output from synchronization points. Synchronization with the replicated server isperformed asynchronously. The basic stages of operation in Remus are the following:Some characteristics: ● VM-based whole-system replication. ● Speculative execution - Replication may be achieved either by copying the state of a system. The state of the replica is synchronized with the primary only when the output of the primary has become externally visible. It buffers output until a more convenient time, performing computation speculatively ahead of synchronization points. ● Asynchronous replication - due to buffering output at the primary server. The primary host can resume execution when its machine state has been captured, without waiting for an ack.Remus failure model provides the following properties: ● The fail-stop failure of any single host is tolerable.
  3. 3. ● Should both the primary and backup hosts fail concurrently, the protected system’s data will be left in a crash-consistent state. ● No output will be made externally visible until the associated system state has been committed to the replica.It uses a simple failure detector integrated in the checkpointing stream. A timeout of the backupresponding to commit requests will result in the primary assuming that the backup has crashedand disabling protection. Similarly, a timeout of new checkpoints being transmitted from theprimary will result in the backup assuming that the primary has crashed and resuming executionfrom the most recent checkpoint.Remus also has pipelined checkpoints since it uses an epoch-based system in which executionof the active VM is bounded by brief pauses in execution in which changed state is atomicallycaptured, and external output is released when that state has been propagated to the backup.LessonHigh availability is possible through virtual machine replication using existing software andrunning on commodity hardware. Remus performs frequent global checkpoints to replicate thestate of a single speculatively executing virtual machine.CritiqueIt comes with the price of introducing a small performance overhead due to the networkbuffering required to ensure consistent replication.

×