Chapter 7. Virtualization and High Availability
- VMs as Highly Available Resources/Services
- Guest Clusters
7.1. VMs as Highly Available Resources/Services
- 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.
- 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.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.
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.