Chapter 7. Virtualization and High Availability
Various virtualization platforms are supported in conjunction with Red Hat Enterprise Linux 6 using the High Availability and Resilient Storage Add-Ons. There are two supported use cases for virtualization in conjunction with Red Hat Enterprise Linux High Availability Add-on.
- VMs as Highly Available Resources/Services
- Guest Clusters
7.1. VMs as Highly Available Resources/Services
This refers to Red Hat Enterprise Linux Cluster/HA running on bare metal hosts that are themselves usable as virtualization platforms. In this mode you can configure the cluster resource manager (RGManager) to manage virtual machines (guests) as highly available resources.
Both Red Hat Enterprise Linux HA and RHEV provide mechanisms to provide HA virtual machines. Given the overlap in functionality, care should be taken to chose the right product to fit your specific use case. Here are some guidelines to consider when choosing between Red Hat Enterprise Linux HA and RHEV for providing HA of VMs.
For virtual machine and physical host counts:
- If a large number of VMs are being made HA across a large number of physical hosts, using RHEV may be the better solution as it has more sophisticated algorithms for managing VM placement that take into consideration things like host CPU, memory, and load information.
- If a small number of VMs are being made HA across a small number of physical hosts, using Red Hat Enterprise Linux HA may be the better solution because less additional infrastructure is required. The smallest Red Hat Enterprise Linux HA VM solution needs two physical hosts for a 2 node cluster. The smallest RHEV solution requires 4 nodes: 2 to provide HA for the RHEVM server and 2 to act as VM hosts.
- There is no strict guideline for how many hosts or VMs would be considered a 'large number'. But keep in mind that the maximum number of hosts in a single Red Hat Enterprise Linux HA Cluster is 16, and that any Cluster with 8 or more hosts will need an architecture review from Red Hat to determine supportability.
Virtual machine usage:
- If your HA VMs are providing services that are using shared infrastructure, either Red Hat Enterprise Linux HA or RHEV can be used.
- If you need to provide HA for a small set of critical services that are running inside of VMs, Red Hat Enterprise Linux HA or RHEV can be used.
- If you are looking to provide infrastructure to allow rapid provisioning of VMs, RHEV should be used.
- RHEV VM HA is meant to be dynamic. Addition of new VMs to the RHEV 'cluster' can be done easily and is fully supported.
- Red Hat Enterprise Linux VM HA is not meant to be a highly dynamic environment. A cluster with a fixed set of VMs should be set up and then for the lifetime of the cluster it is not recommended to add or remove additional VMs
- Red Hat Enterprise Linux HA should not be used to provide infrastructure for creating cloud-like environments due to the static nature of cluster configuration as well as the relatively low physical node count maximum (16 nodes)
Red Hat Enterprise Linux 5 supports two virtualization platforms. Xen has been supported since Red Hat Enterprise Linux 5.0 release. In Red Hat Enterprise Linux 5.4 KVM was introduced.
Red Hat Enterprise Linux 6 only supports KVM as a virtualization platform.
Red Hat Enterprise Linux 5 AP Cluster supports both KVM and Xen for use in running virtual machines that are managed by the host cluster infrastructure.
Red Hat Enterprise Linux 6 HA supports KVM for use in running virtual machines that are managed by the host cluster infrastructure.
The following deployment scenarios are currently supporteddeployment scenarios are currently supported by Red Hat:
- Red Hat Enterprise Linux 5.0+ supports Xen in conjunction with Red Hat Enterprise Linux AP Cluster
- Red Hat Enterprise Linux 5.4 introduced support for KVM virtual machines as managed resources in Red Hat Enterprise Linux AP Cluster as a Technology Preview.
- Red Hat Enterprise Linux 5.5+ elevates support for KVM virtual machines to be fully supported.
- Red Hat Enterprise Linux 6.0+ supports KVM virtual machines as highly available resources in the Red Hat Enterprise Linux 6 High Availability Add-On.
- Red Hat Enterprise Linux 6.0+ does not support Xen virtual machines with the Red Hat Enterprise Linux 6 High Availability Add-On, since Red Hat Enterprise Linux 6 no longer supports Xen.
Note
For updated information and special notes regarding supported deployment scenarios, see the following Red Hat Knowledgebase entry:
The types of virtual machines that are run as managed resources does not matter. Any guest that is supported by either Xen or KVM in Red Hat Enterprise Linux can be used as a highly available guest. This includes variants of Red Hat Enterprise Linux (Red Hat Enterprise Linux, Red Hat Enterprise Linux, Red Het Enterprise Linux 5) and several variants of Microsoft Windows. Check the Red Hat Enterprise Linux documentation to find the latest list of supported guest operating systems under each hypervisor.
7.1.1. General Recommendations
- In Red Hat Enterprise Linux 5.3 and below, RGManager utilized the native Xen interfaces for managing Xen domU's (guests). In Red Hat Enterprise Linux 5.4 this was changed to use libvirt for both the Xen and KVM hypervisors to provide a consistent interface between both hypervisor types. In addition to this architecture change there were numerous bug fixes released in Red Hat Enterprise Linux 5.4 and 5.4.z, so it is advisable to upgrade your host clusters to at least the latest Red Hat Enterprise Linux 5.5 packages before configuring Xen managed services.
- For KVM managed services you must upgrade to Red Hat Enterprise Linux 5.5 as this is the first version of Red Hat Enterprise Linux where this functionality is fully supported.
- Always check the latest Red Hat Enterprise Linux errata before deploying a Cluster to make sure that you have the latest fixes for known issues or bugs.
- Mixing hosts of different hypervisor types is not supported. The host cluster must either be all Xen or all KVM based.
- Host hardware should be provisioned such that they are capable of absorbing relocated guests from multiple other failed hosts without causing a host to overcommit memory or severely overcommit virtual CPUs. If enough failures occur to cause overcommit of either memory or virtual CPUs this can lead to severe performance degradation and potentially cluster failure.
- Directly using the xm or libvirt tools (virsh, virt-manager) to manage (live migrate, stop, start) virtual machines that are under RGManager control is not supported or recommended since this would bypass the cluster management stack.
- Each VM name must be unique cluster wide, including local-only / non-cluster VMs. Libvirtd only enforces unique names on a per-host basis. If you clone a VM by hand, you must change the name in the clone's configuration file.
