This refers to RHEL Cluster/HA running inside of virtualized guests on a variety of virtualization platforms. In this use-case RHEL Clustering/HA is primarily used to make the applications running inside of the guests highly available. This use-case is similar to how RHEL Clustering/HA has always been used in traditional bare-metal hosts. The difference is that Clustering runs inside of guests instead.
The following is a list of virtualization platforms and the level of support currently available for running guest clusters using RHEL Cluster/HA. In the below list, RHEL 6 Guests encompass both the High Availability (core clustering) and Resilient Storage Add-Ons (GFS2, clvmd and cmirror).
RHEL 5.3+ Xen hosts fully supports running guest clusters where the guest operating systems are also RHEL 5.3 or above:
Xen guest clusters can use either fence_xvm or fence_scsi for guest fencing.
Usage of fence_xvm/fence_xvmd requires a host cluster to be running to support fence_xvmd and fence_xvm must be used as the guest fencing agent on all clustered guests.
Shared storage can be provided by either iSCSI or Xen shared block devices backed by either host block storage or by file backed storage (raw images).
RHEL 5.4+ KVM hosts support running guest clusters where the guest operating systems are also RHEL 5.4 or above as Technology Preview.
KVM guest clusters can use either fence_xvm or fence_scsi for guest fencing.
Usage of fence_xvm/fence_xvmd requires a host cluster to be running to support fence_xvmd and fence_xvm must be used as the guest fencing agent on all clustered guests.
Shared storage can be provided by either iSCSI or KVM shared block devices backed by either host block storage or by file backed storage (raw images).
Usage of RHEL 5.4+ KVM hosts to run guest clusters is considered Technology Preview at this time. There are currently no plans to bring this functionality out of Technology Preview, as testing focus is being placed on using RHEL 6 KVM hosts for running RHEL Guest Clusters.
RHEL 6.0+ KVM hosts support running guest clusters where the guest operating systems are either RHEL 6.0+ or RHEL 5.5+ as Technology Preview.
Guest clusters must be homogeneous (either all RHEL 5.5+ guests or all RHEL 6.0+ guests).
Mixing bare metal cluster nodes with cluster nodes that are virtualized is permitted.
RHEL 5.5+ guest clusters can use either fence_xvm or fence_scsi for guest fencing.
RHEL 6.0+ guest clusters can use either fence_virt or fence_scsi for guest fencing.
The RHEL 6.0+ KVM Hosts must use fence_virtd if the guest cluster is using fence_virt or fence_xvm as the fence agent. If the guest cluster is using fence_scsi then fence_virtd on the hosts is not required.
fence_virtd can operate in three modes:
Standalone mode where the host to guest mapping is hard coded and live migration of guests is not allowed
Using the Openais Checkpoint service to track live-migrations of clustered guests. This requires a host cluster to be running.
Using the Qpid Management Framework (QMF) provided by the libvirt-qpid package. This utilizes QMF to track guest migrations without requiring a full host cluster to be present.
Shared storage can be provided by either iSCSI or KVM shared block devices backed by either host block storage or by file backed storage (raw images).
Usage of RHEL 6.0+ KVM hosts to run guest clusters is considered Technology Preview at this time. Work is underway to bring full support to this functionality.
Red Hat Enterprise Virtualization Management (RHEV-M) does not currently support running RHEL 5.5+ or RHEL 6.0+ clustered guests.
Guest clusters must be homogeneous (either all RHEL 5.5+ guests or all RHEL 6.0+ guests).
Mixing bare metal cluster nodes with cluster nodes that are virtualized is permitted.
When support is provided for RHEV guests to run RHEL Clusters/HA, the fencing device will be provided by fence_rhev (shipped in RHEL 5.6).
Alternatively, fence_scsi can be used to provide fencing as described below.
RHEV will not initially support collocation or anti-collocation policies for guests. This would be needed to prevent migration of guests in the same cluster onto the same host (which would reduce availability). In order to work around this, the clustered guests must be pinned via the RHEVM administrative interface to specific hosts.
RHEV will not initially support direct shared block storage between guests. iSCSI based storage and fence_scsi must be used if shared storage is needed in the cluster.
Support for running guest clusters on RHEV guests is planned for the near future, but it is not supported presently.
VMware ESX 4.0+ supports running guest clusters where the guest operating systems are RHEL 5.4+ or RHEL 6.0+ as Technology Preview.
Guest clusters must be homogeneous (either all RHEL 5.4+ guests or all RHEL 6.0+ guests).
Mixing bare metal cluster nodes with cluster nodes that are virtualized is permitted.
ESX 4.0+ as standalone hosts are supported as Technology Preview.
ESX 4.0+ managed by either vSphere or Virtual Center management servers are also supported as Technology Preview.
The fence_vmware agent requires the 3rd party VMware perl APIs. This software package must be downloaded from VMware's web site and installed onto the RHEL clustered guests.
Alternatively, fence_scsi can be used to provide fencing as described below.
Shared storage can be provided by either iSCSI or VMware raw shared block devices.
Usage of VMware ESX guest clusters is considered Technology Preview at this time when used with either fence_vmware or fence_scsi.
The versions of VMware that are supported as Technology Preview are:
VMware ESX/ESXi 4.0+
VMware vCenter 4.0+
Hyper-V is supported for running RHEL 5.3+ or RHEL 6.0+ as guest operating systems. However, there is no Hyper-V fencing agent.
Though no native Hyper-V fence agent exists, fence_scsi can be used as a fence agent as described below.
Shared storage can be provided by iSCSI.
Usage of Hyper-V guest clusters is unsupported at this time.
7.2.1. Using fence_scsi and iSCSI Shared Storage
In all of the above virtualization environments, fence_scsi and iSCSI storage can be used in place of native shared storage and the native fence devices.
fence_scsi can be used to provide I/O fencing for shared storage provided over iSCSI if the iSCSI target properly supports SCSI 3 persistent reservations and the preempt and abort command. Check with your storage vendor to determine if your iSCSI solution supports the above functionality.
The iSCSI server software shipped with RHEL does not support SCSI 3 persistent reservations, therefore it cannot be used with fence_scsi. It is suitable for use as a shared storage solution in conjunction with other fence devices like fence_vmware or fence_rhevm, however.
If using fence_scsi on all guests, a host cluster is not required (in the RHEL 5 Xen/KVM and RHEL 6 KVM Host use cases)
If fence_scsi is used as the fence agent, all shared storage must be over iSCSI. Mixing of iSCSI and native shared storage is not permitted.
