Virtually Nifty, Thrifty and… Swifty

I was recently realized that web servers have encroached on just about every function of the infrastructure where I work. We have web applications to monitor services, web applications to inventory systems, even web servers to manage the documentation of the mess so we can understand it all easier. It seems more efficient and cost beneficial to consolidate web services, while segregating the applications such that they don’t trample on each other’s toes, so to speak.

A likely solution comes in the form of virtual machine hosting. Similar to the idea of Apache’s <VirtualHost>, but at a lower level so that <VirtualHost> isn’t really needed — the entire machine, albeit virtual, is dedicated to the web server and subordinate application. This seems to make it easier to migrate a web server around if needed, rather than provisioning a system, installing software and duplicating configuration such that an application can continue to function properly. Instead of starting from scratch, the entire set of operating system, configuration and specific local data migrates with the system, and launches in seconds rather than the testing associated with installing a new system. Granted, I’ve only just started with this concept, it seems quite sound.

I’ve created a few images to be used as virtual machine “templates”, which I use as a headstart when creating a virtual host. Sure, my images are pre-installed with web server functionality, but they could be just about anything really — any type of server, just about. A while back, I played around with VMware and the idea of using whimsically launched virtual machines to test things I wanted to try. Then, I got into downloading pre-installed images of software I wanted to try out, which by the way is a very handy way to test software without all the overhead of installing/configuring the software correctly just for a trial run. Now, I’m strung out on virtual machines running as part of providing a service.

The ability to manufacture machines at will is a very handy utility. However, I can see it easily getting out of control. Left unchecked, I can visualize a machine room with racks of physical machines with no real idea of what is actually running on any of them without digging into a bunch consoles. Documenting a dynamic environment like that seems insurmountable. The ability to easily locate a physical machine to diagnose a malfunctioning service seems to be replaced by easy replacement and/or migration. I’m still not sure which is better; knowing which physical hardware is running what specific software, or not caring which physical hardware is running which software such that if a service goes down a replacement set of software can be launched somewhere else.

I guess I’m just old school in that I like to know which is doing what, and where I can find it, so I can give it a technical tap with my 5 pound hammer. I have seen that there are automated utilities and tools that handle the installation, configuration and even migration if necessary, all through a handy web interface. Someone termed this concept Virtualization Management. (I’m glad its not called Virtual Management, ’cause that could get confusing really quickly.) While I’ve yet to actually try out Virtual Management, it still seems to not solve the problem of knowing which does what and where it is. It actually seems to make a sysadmin care less about location, because it relieves the admin of the task in having an intimate relationship with each system… It becomes a group of physical machines, with invisible virtual machines inside them, running all the services you need.

So, in the new virtualized world… we have new terms. Virtualized Management, which handles virtual machines such that the physical hardware doesn’t succumb to virtual server sprawl.

Server sprawl itself isn’t a new term. It has been around since headless PCs have been installed into racks, more or less.

Picture a room of computers in racks, running the same operating system, and each of them have a random set of software serving a specific purpose. A person would have some sort of inventory just to keep their sanity in making sense of it all, at the very least just to know where stuff is and what its connected to! If you discover a bug in the software on one of them, or someone reports a problem, you consult your inventory, locate the machine and apply the appropriate fix or update. Problem solved.

Now picture a room of computers in racks, running the same operating system, and each of them have multiple virtual machines running inside with specific software installed with the added ability to easily move a web server from one machine in a rack to a different machine on the other side of the room. If you discover a bug in the software or someone reports a problem, how do you attack the problem? Unless you have an ever changing list of virtual machines and a list of which physical machines they’re located, how is the problem service/system to be found? The answer seems to be “just use Virtualized Management”, since this is how virtualized infrastructure is constructed to begin with. I’m not sure that’s the right answer, since that seems to add complexity into the overall system — I used a relatively static list of systems/services/locations in a non-virtualized environment.

Virtualized Management seems to take my static list of systems/services/locations and turn it into a grey hazy cloud of services with no real notation about systems or locations.

I plan to test run a few Virtualized Management systems to determine if it solves my concerns. Some of them are:

• Enomalism
• BixData
• ganeti