andy/fence-virt
1
0
Fork 0
forked from altcloud/fence-virt
Code Issues Pull Requests Releases Wiki Activity

Update README

Browse Source 
Signed-off-by: Lon Hohberger <lon@users.sourceforge.net>
This commit is contained in:
Lon Hohberger 2011-09-19 16:11:10 -04:00
parent b5e1bc6e5f
commit 2118df11fa
1 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
README
View File

@ -1,6 +1,6 @@
TODO: update TODO: update
I. Fence_xvm - the Xen virtual machine fencing agent I. Fence_xvm - Virtual machine fencing agent
Fence_xvm is an agent which establishes a communications link between Fence_xvm is an agent which establishes a communications link between
a cluster of virtual machines (VC) and a cluster of domain0/physical a cluster of virtual machines (VC) and a cluster of domain0/physical
@ -22,15 +22,15 @@ would hate to receive a false positive response from a node not in the
cluster!). cluster!).
II. Fence_xvmd - The Xen virtual machine fencing host II. Fence_virtd - Virtual machine fencing host
Fence_xvmd is a daemon which runs on physical hosts (e.g. in domain0) Fence_virtd is a daemon which runs on physical hosts (e.g. in domain0)
of the cluster hosting the Xen virtual cluster. It listens on a port of the cluster hosting the virtual cluster. It listens on a port
for multicast traffic from Xen virtual cluster(s), and takes actions. for multicast traffic from virtual cluster(s), and takes actions.
Multiple disjoint virtual clusters can coexist on a single physical Multiple disjoint virtual clusters can coexist on a single physical
host cluster, but this requires multiple instances of fence_xvmd. host cluster, but this requires multiple instances of fence_virtd.
NOTE: fence_xvmd *MUST* be run on ALL nodes in a given cluster which NOTE: fence_virtd *MUST* be run on ALL nodes in a given cluster which
will be hosting virtual machines if fence_xvm is to be used for will be hosting virtual machines if fence_xvm is to be used for
fencing! fencing!
@ -43,15 +43,15 @@ In order to be able to guarantee safe fencing of a VM even if the
last- known host is down, we must store the last-known locations of last- known host is down, we must store the last-known locations of
each virtual machine in some sort of cluster-wide way. For this, we each virtual machine in some sort of cluster-wide way. For this, we
use the AIS Checkpointing API, which is provided by OpenAIS. Every use the AIS Checkpointing API, which is provided by OpenAIS. Every
few seconds, fence_xvmd queries the Xen Hypervisor via libvirt and few seconds, fence_virtd queries the hypervisor via libvirt and
stores any local VM states in a checkpoint. In the event of a stores any local VM states in a checkpoint. In the event of a
physical node failure (which consequently causes the failure of one physical node failure (which consequently causes the failure of one
or more Xen guests), we can then read the checkpoint section or more guests), we can then read the checkpoint section corresponding
corresponding to the guest we need to fence to find out the previous to the guest we need to fence to find out the previous owner. With
owner. With that information, we can then check with CMAN to see if that information, we can then check with CMAN to see if the last-
the last-known host node has been fenced. If so, then the VM is known host node has been fenced. If so, then the VM is clean as well.
clean as well. The physical cluster must, therefore, have fencing The physical cluster must, therefore, have fencing in order for
in order for fence_xvmd to work. fence_virtd to work.
Operation of a node hosting a VM which needs to be fenced: Operation of a node hosting a VM which needs to be fenced:
@ -93,7 +93,7 @@ network, there are cases where it may not be.
fencing action is taken based solely on the information contained fencing action is taken based solely on the information contained
within the packet, this should not allow an attacker to maliciously within the packet, this should not allow an attacker to maliciously
fence a VM from outside the cluster, though it may be possible to fence a VM from outside the cluster, though it may be possible to
cause a DoS of fence_xvmd if enough multicast packets are sent. cause a DoS of fence_virtd if enough multicast packets are sent.
* The only currently supported authentication mechanisms are simple * The only currently supported authentication mechanisms are simple
challenge-response based on a shared private key and pseudorandom challenge-response based on a shared private key and pseudorandom
@ -104,7 +104,7 @@ known VM, even if they are not on a cluster node.
* Different shared keys should be used for different virtual * Different shared keys should be used for different virtual
clusters on the same subnet (whether in the same physical cluster clusters on the same subnet (whether in the same physical cluster
or not). Additionally, multiple fence_xvmd instances must be run or not). Additionally, multiple fence_virtd instances must be run
(each listening on a different multicast IP + port combination). (each listening on a different multicast IP + port combination).
IV. Configuration IV. Configuration
@ -118,7 +118,7 @@ as all dom0s which will be hosting that particular cluster of domUs.
The key should not be placed on shared file systems (because shared The key should not be placed on shared file systems (because shared
file systems require the cluster, which requires fencing...). file systems require the cluster, which requires fencing...).
Start fence_xvmd on all dom0s Start fence_virtd on all hosts
Configure fence_xvm on the domU cluster... Configure fence_xvm on the domU cluster...