Another major benefit of server virtualization is the ability to shift running virtual servers between physical hosts to balance load and allow for maintenance windows. You can also use snapshots of virtual servers to keep a moment-in-time copy of a running server prior to making changes such as software updates. If something goes wrong, you can simply return to the snapshot, and the affected server will be running as if you had never touched anything. Clearly, this approach can save significant time and aggravation.
If you haven’t already moved down the virtualization road, fear not: More options are available now than ever before, and any time is the right time to get started.
1. Start Small on Your Desktop or Laptop
Although server virtualization has certainly taken the server room by storm, you also have many ways to bring virtualization into the office on a smaller scale–namely, on your desktop or laptop.
Generally, modern desktop and laptop PCs have a surprising amount of resources that go unused when the system is performing little tasks such as email reading or Web browsing. If you find that you have the need to run a different operating system from time to time (say, to support a legacy application), you could fire up a virtual desktop on your local system and forgo the physical installation.
2. Set Up a Small, Possibly Free, Lab
If you’ve retired servers recently, they may be a good platform for you to begin building a virtualization lab. The key is to make sure that they have several gigabit network interfaces, and as much RAM as you can fit in them. Virtualization tends to be lighter on CPU resources but heavier on RAM, especially if you use a virtualization method that doesn’t employ RAM page sharing to squeeze more space out of physical RAM.
If you don’t happen to have spare servers handy, you can pick up a new cheap server (again with plenty of RAM) to test with. If you’re feeling ambitious, you can even build one from spare parts you might have lying around. In a lab setting, this machine can serve as a proof of concept, but you shouldn’t run it in production.
As for the choice of virtualization software, you can try them all out on a lab system. Armed with several hard drives, you can install VMware ESXi, Microsoft Hyper-V, Citrix XenServer, or Red Hat RHEV on one disk apiece, and simply boot to one disk at a time to see which software fits your needs the best. All of these packages are available either as free instances or as trials with evaluation periods of 30 or more days.
3. Build Your Own Shared Storage
Some virtualization arrangements can address a variety of storage protocols, such as NFS, iSCSI, and Fibre-Channel. For lab or testing purposes, you can simply add several hard drives to a Windows or Linux system, share them with NFS or iSCSI, and bind your lab servers to that storage. If you want a more complete “homegrown” approach, give open-source storage options, such as FreeNAS, a try. This software offers a simple way to add a variety of storage to a lab or production network, using cheap hardware.
4. Spend Time in the Lab
Armed with some form of shared storage and at least two physical host servers, you have the basis of a full virtualization platform ready to go. If you’re evaluating several different packages, try each of them out for a week or so. Make sure to step through all of the features important to your needs, such as live virtual server migrations, snapshots, virtual server cloning and deployment, and high availability.
You may also have the ability to try out production workloads in the lab to get a feel for how the setup will perform in the real world. You might build a database server and use a backup of a real data set to run some reports, or use a Web server benchmarking tool to measure the performance of a Web application server. This practice will not only familiarize you with the day-to-day functions of the virtualization platform but also give you some insight as to what resources your virtual servers may need when they enter production.
5. Keep the Lab, Even When You Begin Production
After all this, you’ve likely settled on the arrangement you want to use in production. You’ve gotten a feel for the management tools, and you’ve mapped out how you want to proceed with the real deal. Now is not the time to dismantle the lab, however.
Once you’ve started procuring new hardware for the production infrastructure, you’ll want to reference settings you’ve made in the lab to ensure that the virtual servers you plan to deploy will be able to handle the tasks assigned to them.
Furthermore, after you’ve completed the production build, you can use the lab to test new functionality, updates, and beyond, which will only bolster the stability and reliability of the production platform.
Next page: Moving into production
6. Use an Existing-Infrastructure Profiling Tool
These tools employ constant performance profiling to gauge the resources that each server on your network consumes, generally over a period of time from 30 to 60 days. They see the peak utilization of CPU, RAM, disk, and network I/O resources, and mix all of that data together to produce a guide to the CPU, RAM, storage, and network requirements you’ll need to shift the infrastructure into the virtual world. In some cases you can even define the brand and model of the servers you’re considering, and the tool will tell you how many you need. Playing with the numbers here can save you plenty of money down the road.
7. Spec and Purchase the Production Hardware
Based on the results from your lab testing and capacity planning, you should have a good idea as to what resources each of your physical host servers will require in production–at least to a point.
As far as storage goes, you’ll get more bang for your buck with iSCSI or NFS storage than with Fibre-Channel at this point, especially in lower-scale projects. Regardless, make sure that your storage vendor is approved for use with the virtualization software you’ve chosen, and that you find some best-practices guides to tune your network, servers, and storage devices for optimal performance. In many cases tuning is as simple as enabling jumbo frames or using link aggregation protocols to increase the bandwidth available to the storage device.
8. Choose the First Movers
Once you’ve built up your brand-spanking-new virtualization solution and tested it with a few new virtual servers, it’s time to start putting a production load on it. Start slow here, and plan an orderly transition from physical to virtual.
Pick a few smaller-scale physical servers, such as a lightly used application server, or even an Active Directory domain controller (assuming that you have multiple physical domain controllers) and either build them fresh on the virtual infrastructure or use P2V (physical-to-virtual) tools to move the server instance in its entirety. In the case of domain controllers, it’s always best to build them fresh; but you can easily transition application servers and other types to a virtual server with P2V tools, saving time and aggravation. However, you may encounter instances where these tools cannot successfully move a server, in which case you will have to rebuild it.
By starting with smaller servers first, you can flush out any problems that the new virtualized infrastructure may have before you move highly visible services over. Once you’re satisfied with the stability of the new arrangement, you can begin moving the heavier-duty servers over.
9. Watch Carefully
Once you’ve started the transition process, keep a close eye on the performance, on a virtual-server, physical-host, and storage level. If your setup has automated load leveling, make sure that it’s enabled and functional, and confirm that your original resource-utilization forecasts aren’t being eclipsed. It’s best if you can see possible resource problems on the horizon before you get there.
10. Enjoy All the New Capabilities
Now you can take advantage of all the goodies that virtualization has to offer. Use snapshots to preserve system states prior to updating sensitive code. Use cloning to quickly and easily spin up new server instances when you need them. Use live migrations to transition virtual servers from one host to another without downtime should you need to take down a physical server for maintenance. All that and more is now available, and if you’ve done everything right, it will save you time and money.