From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anand Nande Subject: [fedora-virt] KFT feature proposal review for F17 Date: Thu, 15 Sep 2011 19:20:32 +0530 Message-ID: <4E7202A8.5060600@redhat.com> References: <20110914112552.GP12984@reaktio.net> Reply-To: anande@redhat.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9075311525305615881==" Return-path: In-Reply-To: <20110914112552.GP12984@reaktio.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virt-bounces@lists.fedoraproject.org Errors-To: virt-bounces@lists.fedoraproject.org To: Development discussions related to Fedora , fedora-virt@redhat.com Cc: xen@lists.fedoraproject.org, virt@lists.fedoraproject.org, xen-devel@lists.xensource.com, xen-users@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============9075311525305615881== Content-Type: multipart/alternative; boundary="------------000505070909080701090108" This is a multi-part message in MIME format. --------------000505070909080701090108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit KFT (KVM Faul Tolernace): ======================== How it works: ------------- * Provide Continuous availability to Mission Critical Applications with a 'Always Available' environment preventing any downtime or Data-loss in the event of server-failures. * RFT when enabled for a Virtual Machine creates a secondary copy of it on another physical server running KVM. * The two copies are continuously synchronized by replaying the contents of the Memory from the primary VM to the Secondary (copy) VM. The Primary and the Secondary VM access the same storage device (shared storage) between the 2 servers. * For example: If a user is playing a Youtube video on VM1, and the KVM Guest VM-1 crashes (due to some reason), The Secondary-slave copy becomes Active and promotes itself as Primary immediately when the vdsm-agent (communicating between the KVM-Host and the KVM-GuestVM-1) detects the server crash. This leads to creation of another secondary copy on the Next available physical server (obviously sharing the same storage with the now-active Primary-VM). * Thus the GuestVM-2 (which was the secondary copy before the crash) ---> is now known as VM-1 (and the new secondary copy on the newly available server is now known as VM-2). * This can be achieved over qemu+ssh connections being managed by a single virt-manager as well. Advantages: ----------- * Zero Downtime: Fault Tolerance provides absolutely no downtime as that comapred to HA wherein the VM restarts completely on a different server. * Immunity from Server crashes/panic/OOM situations. * Extremely Fast Disaster Recover Mechanism. Disadvantages: -------------- * If a panic/crash takes place on the GuestVM being hosted on the KVM, This will be replicated on its Secondary-Copy, which is being hosted on other KVM's. [ This can easily be avoided by having periodic snapshots of the Primary-VM ] Currently Available Technologies: --------------------------------- * Kemari: Fault Tolerance Xen source: http://www.xen.org/files/xensummitboston08/tamura_xen_summit_presentation_final.pdf KVM source: http://www.linux-kvm.org/wiki/images/0/0d/0.5.kemari-kvm-forum-2010.pdf Kemari Project: http://www.osrg.net/kemari/ Please leave your valuable feedback for this. Sincerely, Anand Nande --------------000505070909080701090108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit KFT (KVM Faul Tolernace):
========================

How it works:
-------------
* Provide Continuous availability to Mission Critical Applications with a 'Always Available' environment preventing any downtime or Data-loss in the event of server-failures.
* RFT when enabled for a Virtual Machine creates a secondary copy of it on another physical server running KVM.
* The two copies are continuously synchronized by replaying the contents of the Memory from the primary VM to the Secondary (copy) VM. The Primary and the Secondary VM access the same storage device (shared storage) between the 2 servers.
* For example: If a user is playing a Youtube video on VM1, and the KVM Guest VM-1 crashes (due to some reason), The Secondary-slave copy becomes Active and promotes itself as Primary immediately when the vdsm-agent (communicating between the KVM-Host and the KVM-GuestVM-1) detects the server crash. This leads to creation of another secondary copy on the Next available physical server (obviously sharing the same storage with the now-active Primary-VM).
* Thus the GuestVM-2 (which was the secondary copy before the crash) ---> is now known as VM-1 (and the new secondary copy on the newly available server is now known as VM-2).
* This can be achieved over qemu+ssh connections being managed by a single virt-manager as well.

Advantages:
-----------
* Zero Downtime: Fault Tolerance provides absolutely no downtime as that comapred to HA wherein the VM restarts completely on a different server.
* Immunity from Server crashes/panic/OOM situations.
* Extremely Fast Disaster Recover Mechanism.

Disadvantages:
--------------
* If a panic/crash takes place on the GuestVM being hosted on the KVM, This will be replicated on its Secondary-Copy, which is being hosted on other KVM's.
  [ This can easily be avoided by having periodic snapshots of the Primary-VM ]

Currently Available Technologies:
---------------------------------
* Kemari: Fault Tolerance

Xen source: http://www.xen.org/files/xensummitboston08/tamura_xen_summit_presentation_final.pdf
KVM source: http://www.linux-kvm.org/wiki/images/0/0d/0.5.kemari-kvm-forum-2010.pdf
Kemari Project: http://www.osrg.net/kemari/

Please leave your valuable feedback for this.
   
Sincerely,
Anand Nande
             
--------------000505070909080701090108-- --===============9075311525305615881== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ virt mailing list virt@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/virt --===============9075311525305615881==--