Virtual servers can do just about anything that physical servers can do, and that's precisely the idea. One function that virtual servers can fulfill, albeit in a limited way, is clustering. Microsoft Virtual Server 2005 supports a two-node failover cluster between instances of Windows Server 2003 Enterprise Edition. In this article, I'll talk about the reasons for running a cluster in Virtual Server, the difficulties you might face in doing so and the way Virtual Server handles clustering.
The how and why of the problem
A common question that's asked about running clusters in Virtual Server is, "If one of the benefits of clustering is failover and redundancy between different physical machines, why run a virtual cluster at all?" The answer is twofold. First, to lessen the effects of any one piece of hardware failing, virtual clusters should probably not be used to replace physical clusters in situations where the load is distributed between two physical nodes. It's best to use virtual clusters in an educational fashion and not as production-level substitutes for real two-node clusters.
Second, virtual clusters provide an easier way to learn about how clustering works. They can also provide a user with some practice in working with cluster setups without having to devote more than one computer to the job. This includes developing or working with applications that require a clustered environment. If you're writing such an application or responsible for testing it out, you can use Virtual Server as a staging environment to see how well it works in a provisional way.
As an aside, Microsoft likes to draw distinctions between high-availability clustering (i.e., what's being described here) and fault-tolerant clustering. Fault-tolerant clustering usually involves a vendor supplying you with highly redundant hardware and specially crafted software to insure that your services can survive a major hardware failure of some kind. High availability is a step down from that, but it still guarantees a high degree of continued availability for a given application. Obviously, it's a little hard to do fault-tolerant clustering when both nodes of the cluster are running on the same piece of physical hardware!
A big difference
One key technology that comes in handy to create clusters in Virtual Server is differencing. Normally, when you create a computer in Virtual Server, it uses its own independent disk image (which in turn contains its own OS image), which runs in a standalone fashion. But if you're going to create a number of machines that are all based on the same basic installation, Virtual Server lets you save some time and disk space by creating a parent disk. This is a single disk (say, a bare Windows 2003 Server installation) that is set as read-only and used by each virtual computer as a basis for what their own individual hard drive will be. Each virtual computer also gets a difference disk, which records only the changes made to that particular machine. This way, you can strike and reload a given virtual machine very quickly, use less disk space overall for multiple virtual computers (since you're not storing much of the same data redundantly) and guarantee a high degree of consistency between nodes. The last is most important here.
Pieces of the puzzle
The basic requirements for setting up a cluster in Virtual Server are not all that different from those for creating a more conventional two-node cluster:
- Multiple copies of Windows 2003 Server Enterprise Edition, which supports up to four-node clustering (although Virtual Server only supports two-node clusters), for the nodes themselves.
- Licenses for the virtual cluster nodes.
- SYSPREP for Windows Server 2003. This tool is freely available from Microsoft and is needed to create the read-only parent disk.
- Any clustered applications you plan to run (optional), plus any server licenses needed for same (such as SQL Server).
But you'll need some additional pieces for the sake of the virtualization:
- An installation of Virtual Server 2005, which can run on Windows Server 2003 or Windows XP Professional Edition (Windows Server 2003 is recommended).
- Sufficient hardware to run Virtual Server as the host and the two cluster nodes and a domain controller as guests (unless a virtual domain controller already exists).
A full list of what you will need is available in a Microsoft document that also describes, step-by-step, how to set up the nodes in the cluster on Virtual Server. If you're not familiar with how to create a cluster, pay careful attention to the steps involved; it's not the same as simply setting up two instances of Windows Server and having them talk to each other over a network connection!
Another issue to consider is how much hardware you have to throw at the problem. The server used to run a virtual cluster should have at least 512 MB of physical memory to devote to each cluster in the node. Microsoft recommends a minimum of one gigabyte for the system as a whole. My recommendation is to use two gigabytes or better whenever possible, because this allows 512 MB to 768 MB to be devoted to each cluster node; 256 MB or so for the domain controller, unless you can use one that's already on the virtual server; and 512 MB to a gigabyte for the host operating system. In theory, you can go as low as 256 MB for the host OS, provided the host is not doing anything else other than provisioning virtual servers.
This sort of thing works best if you have a large machine (say, something with 16 GB and multiple processors) already devoted to running virtual servers in your organization. In such a setting, it becomes a lot easier to add the two nodes needed to run a cluster. If you're not capable of dedicating those kinds of resources for a virtual server, a virtual cluster may not work out well for you at all.
Processing power is another consideration for many of the same reasons, even if you're not intending to run a virtual cluster at the same speed as its physical counterpart. If you plan on using the cluster to test or stage applications that require clustering, you should have sufficient CPU and memory on each cluster node to run the app itself. Cluster nodes should also run at the same weight (i.e., priority) whenever possible; if one of the nodes is idling, the host OS will understand that.
A license for free enterprise
One tricky aspect of creating a cluster in Virtual Server is figuring out how to handle the software licenses for the nodes in the cluster and the domain controller, if you're creating one specifically for the cluster. You can deal with the software licensing situation in a few ways:
- Use full licenses for Windows Server 2003 Enterprise Edition in each cluster node. This is the most expensive and least practical way to do it, because server licenses are not cheap and you will probably not even be running these servers in a production environment.
- Use the conventional version of Windows Server 2003 Enterprise Edition without running Product Activation. Because the software will only run 14 days at most in this fashion, this is extremely limited.
- Download and use the Windows Server 2003 Enterprise Edition trial software for the nodes, which runs for 180 days without restrictions. This is probably the easiest way to deal with the problem, especially if (again) you're not using the server in a production environment.
Note that the trial version of the software will still require a license key and product activation, but this will at least free you from having to buy an entirely separate license key for each node if all you're doing is staging and testing. If you wind up using the cluster nodes in some kind of production environment, you can always reinstall the full edition of Windows Server over the trial version and preserve the existing settings.
Serdar Yegulalp wrote for Windows Magazine from 1994 through 2001, covering a wide range of technology topics. He now plies his expertise in Windows NT, Windows 2000 and Windows XP as publisher of The Windows 2000 Power Users Newsletter and writes technology columns for TechTarget.