On Wednesday, I had the honor to speak about virtualization management in a Webcast for Enterprise Networking Planet. If you didn't get a chance to tune in to hear, "Managing Your Virtualization Infrastructure: Tools for Success," it's now available in an on-demand version. The Webcast is free, but registration is required.
One of the most rewarding aspects of the Webcast format is the direct link it provides to what's on people's minds. Listeners lobbed many questions my way. Unfortunately, time constraints made it impossible to answer all of them. The questions that were asked didn't always received the fleshed-out answers they warranted. Therefore, this week in a break from the usual format, Virtually Speaking is opening the virtual reader mailbag and providing answers.
After all, if one person out there has a question there's a good chance he or she isn't the only one.
Is it viable to have a virtual environment for testing, even if production is a dedicated server?
Absolutely. In fact, the majority of deployments are currently in test (and dev), so that is the reality for many data centers right now. There's certainly nothing wrong with planning to not go past test and dev, and you can be up and running within such an environment at minimal cost. Many of the free offerings from virtualization vendors are designed for uses such as this. Bear in mind, however, that 500 haphazardly installed and configured virtual servers in a test and dev environment will be almost as much of a strain on your infrastructure and as much of a headache to manage as they would be in a production environment. They just won't be directly impacting your mission-critical applications.
Does each application need to have its own virtual machine (VM)?
Not at all. Just as not every application requires its own box, not every application requires its own VM. And just as proliferation of physical servers results in server sprawl, so too will proliferation of virtual servers. Server sprawl in a virtual environment is equally difficult to wrangle, perhaps even more so due to its intangible nature. Mission-critical applications will generally merit their own VM, and in some cases a dedicated box, but applications that complement each other can certainly reside on the same VM. A perfect example would be back-office applications that always run at different times.
When performance testing our VM, the test results we get are not that same as a regular server on the same operating system. Is virtualization still the right choice?
Maybe. It depends on what you're trying to achieve with virtualization. One downside of virtualization is that it's almost a given that performance will take a hit. If what you're virtualizing doesn't have high I/O requirements it may not be an issue. A performance hit for an individual server may be a gain for the overall infrastructure. Before making a final decision, be sure your hardware is up to the task, workloads aren't in conflict and the box isn't expected to function beyond its capacity. Sometimes simply shuffling server workloads around is enough to get you the performance you need. This is one area where knowing your network really pays off. What additional security concerns should be considered with a virtual infrastructure?
What additional security concerns should be considered with a virtual infrastructure?
Each VM is a server and thus an entry point to your network. You must keep each operating system up to date, and, in some cases, it may be best to keep the VM isolated. That means it must be patched and privileges and permissions assigned on a per-VM basis. Awareness in this area is just starting to build, and a growing number of security products are coming to market that address security concerns with VMs in mind. No doubt as the number of virtualization deployments on production systems grow, security issues and the products that resolve them will proliferate.
The same redundancy that you have in place for your physical servers is even more vital for your virtual servers. It's a case of more eggs in fewer baskets, so it's critical that the baskets be even more cushioned and locked down, because 16 servers, not one, must be protected. Also, a VM with failover to another VM on the box works fine, and is an ideal failover solution, should the VM itself go down. But if the entire box goes down, you must be prepared to failover to another box, and that box must be just as capable as the one that went down.If you enjoyed this virtualization Webcast, be sure to catch the next one. "Two Roads to Mainstream Virtualization" will be presented on May 1.
Amy Newman is the managing editor of ServerWatch. She has been following the virtualization space since 2001.