When the brilliant Denny Valliant and I were running the NewMexicoKids.org website for the State of New Mexico, it was a Coldfusion operation comprising a huge body of resources. And it was a vast resource hog. Keeping a single server instance up and running proved eventually to be impossible, particularly since numerous Chinese IP addresses seemed intent on penetrating by any possible means, nonstop, day and night.
We implemented a failover system using a Heartbeat script operation and a bastion host pair, turning one machine into five, including the data store server. It was nuts.
So we moved to a VMware implementation, ESX 3 at that time, and turned three strong 2U rack servers into virtual hosts. Each host proved capable of handling up to six virtual machines at a time, which was truly impressive. And this let us take advantage of some Java/Coldfusion clustering applications. It was an eye-opening experience. Suddenly a server failure simply was not such a big deal. Apache sticky sessions kept login sessions on one server, but if it failed, the user could simply log in again and be back up and running with no data loss. MySQL replication kept two data stores (at least) on line at all times. The physical hosts proved to be made of cast iron in this scenario, since the simple hypervisor they were running hardly ever needed attention.
Since them I and that site have moved on, but I am still deeply involved in cloud and virtualized computing. Recently I’ve been building out a set of machines to serve as a lab for a potential virtualization seminar — which hasn’t been easy.
First, I needed a 64-bit host machine with lots of RAM, one that was capable of running VMware ESXi 4, the latest version. This is no trivial requirement: several machines I tried simply could not run ESXi (which, by the way, my wife took one look at and promptly dubbed “E-sexy”). Finally, after careful consulting of the HCL, I bought an older AMD 64 dual-core, dual-processor 1U rackmount server with 8 GB RAM. Voila, my ESXi host. With only 8 GB RAM on the server, I wanted to reserve it exclusively for VMs for vCenter and vSphere to manage.
Then, for a very simple management interface, I needed a Windows machine to run the vSphere Client, available from VMware on a trial basis. This is no problem, though support for other OSs is slim to none. This machine, a Windows XP or 7 workstation with vCenter Client installed, is optional but very handy.
For more complex management, a domain controller is mandatory. The domain controller is a resource hog, so I wanted it to be a physical machine. Essentially any current version of Windows Server will do the trick. It must run AD and DNS, of course. I put together an AMD 64 machine with 4 GB RAM, and loaded it with Win Server 2008 and VMware Player so I could run other VMs, such as BackTrack.
Next, for the big management operation, I downloaded vCenter Server, which is the management operation that can move VMs between hosts to balance loads, as well as applying policies and reinstantiating VMs if they fail. And the vCenter Server also devours 3 GB RAM, so likewise I wanted it to be a separate physical host. This became a game of Catch-22: You must install on a 64-bit version of Windows, but not Vista. XP and 7 are OK. Also, vCenter Server won’t install on a domain controller, so this must be a different machine from the one above. But finally, I put together a Win Server 2003 Enterprise machine, AMD 64 again, 4 GB RAM again, and downloaded and installed vCenter Server. Done!
I’ll be moving forward with building out the lab and a curriculum for basic virtualization implementation. Beyond that, I’ll start working on a VMware View virtual desktop infrastructure, and a class for that as well.
Interested? Got questions? Want something different, like virtualization on your workstation? Drop me a line using the Contact Me link on the left.