Do You Know How to Make High Availability with Create a XenServer virtualization cluster

High availability used to be expensive, requiring both specialized software and redundant hardware. Today it almost grows on trees, but you need two key ingredients: virtualization and network storage. By creating a virtual server farm across multiple physical servers, and storing all of your virtual machines on a central SAN or NAS, you can ensure that the failure of any given piece of physical hardware will not bring down your virtual environment.

We recently created a highly available virtual server cluster based on the free edition of Citrix XenServer; this article outlines the process step by step. Although the obvious choice for any enterprise-grade virtualization deployment is VMware vSphere, I chose XenServer for two reasons. First, we're cheap. We don't like spending money on things that we can get for free. Second, and more important, the licensing of VMware is extremely confusing; we're never sure what exactly is required to be properly licensed. (I guess this also amounts to being cheap. We always feel that we are being overcharged for items we aren't fully utilizing.)

It should be mentioned that there are many different flavors of Xen available. Just about any version of Linux includes a Xen implementation. The version discussed here is not "pure" open source Xen, but XenServer, the commercial bare-metal hypervisor originally developed by XenSource, which was subsequently purchased by Citrix. The version of XenServer we used was the latest available at the time, 5.6.0.

Virtualization ABCs

Aside from the cost and licensing issues, the primary reasons to implement a virtual server farm on XenServer are the same as for using any other virtualization suite:

Consolidation. Because virtualization allows us to squeeze multiple servers into a much smaller hardware footprint, we can provide the same level of functionality as before, with fewer servers, allowing for a much smaller server farm footprint. Fewer servers equals less power consumption, lower overall hardware cost, and lower manpower requirements.

Isolation of services. With the ability to quickly create virtual servers instead of standing up physical servers, there is no longer a need to consolidate services on one server. Need a new service? Instead of adding yet another service to an existing server, create a new virtual server. This allows for much simpler troubleshooting. When each service is completely isolated in its own virtual machine, there is no more second-guessing about whether service X conflicts with service Y.

Multiple-OS environment. Services that are best handled by one operating system can run side-by-side with services that are best handled by another. Most of us have an OS preference for specific applications. You like your service X to run on Windows, and your service Y to run on Linux? You no longer need two physical servers to do so. Simply stand up two virtual servers, and away you go.

Easy hardware upgrades. A system that is performing as desired need not be entirely rebuilt in the inevitable event of a hardware failure. All of us know the familiar scenario in which a service runs exactly the way we want it, and yet the physical hardware hosting this service is nearing the end of its life. With virtual servers, upgrading hardware no longer means having to rebuild the entire system from scratch. The hardware abstraction layer is standardized, and the hard drives are simple flat files. Copying these flat files to new hardware is a snap. With the proper preparation, the downtime for hardware upgrades can be reduced from potentially days to minutes.