Keep your balance with simple workload analysis and remember that not everything that can be virtualized, should be virtualized.
Which types of workloads both can be and should be virtualized? To answer this question, you have to examine your four primary bottlenecks for each type of workload: CPU, Memory, Network, and Disk I/O. Once you’ve figured out which type of workload your new VM is responsible for, you’ll then need to decide how to separate those workloads on different host systems.
When you begin creating VMs and assigning workloads to them, you’ll have to take an educated guess as to how much CPU power, number of CPUs, amount of physical RAM, disk space, network resources, and so on to allocate to that VM. I know this sounds like a bit of an easy out but there’s no definitive way to determine beforehand what a new system’s requirements will be. This is the reason why most physical systems purchased for a particular workload are “overkill” and most of the resources are wasted — which brings us to why we virtualize our workloads in the first place.
Once your VM exists and its workload active, you should begin assessing its performance right away. My favorite free tool for performance assessment is Orca. Using Orca, you can visually assess the performance of any Unix, Linux, or Windows system and make adjustments to your VMs over their entire life cycle.
The most popular workload to virtualize is the web (HTTP) server. Web servers require CPU and memory resources to power their services, therefore you should assign the highest amount of CPU (power not number) and physical memory possible for your virtualized web servers. As with all workloads, once you’ve assessed a system’s actual resource requirements, you can adjust its resources to more effectively handle its needs.
Mail service is another very popular workload to justify as virtual. Companies that have heavily loaded mail systems may opt for one or more incoming mail servers and a separate outgoing mail server. Typically Unix or Linux VMs live virtual lives better than their Windows counterparts do. Exchange can be run in a virtual infrastructure but you really have to know how to configure those services so that you don’t experience I/O bottlenecks and hence ruin your chances of further virtualization for other workloads.
Should you decide to use Exchange in a virtualized environment, every effort should be made to continuously monitor and adjust resources accordingly.
Database workloads are the topic of much debate these days in virtualization circles. I’ll go on record now as saying that database systems can be virtualized — often with no issues at all. The database system software (RDBMS) itself can reside within a VM and experience no performance issues. Problems generally arise when there are higher numbers of writes or very high numbers of large data reads. Virtual disk files just can’t respond fast enough to satisfy those requests without long waits. This becomes frustrating for users and for you as the administrator who has to listen to the complaints.
However, and this is a huge however, if your database is write intensive or you have high numbers of large data reads, you should either reconsider virtualizing that workload or house your database files on a SAN (Storage Area Network).
I have heard of some virtual Terminal Servers but in general I don’t think it’s a good idea to do so unless it is for a very limited number of users. Terminal services are generally thought of as a virtualization method and not as a service that can or should be virtualized itself. Performance of constant disk reads and writes can’t be made sufficiently fast to accommodate a virtualized terminal service.
Desktop virtualization is one of the most controversial subjects and is one method that should be done in moderation, if at all. Terminal services is a far better method of virtualizing desktops for performance, security, and overall satisfaction with the experience. Very little financial or administrative gain is made in fully virtualized desktops — at least in the way it’s currently being implemented.
File and print servers are prime candidates for virtualization as long as the file storage for a file server is handled by network attached storage (NAS) or a SAN. For print services, it is generally accepted practice to use a separate virtual disk for the print spool area. A separate disk helps ensure that performance or space constraints don’t hinder the handling of print jobs.
Network services such as time (NTP), domain name services (DNS), dynamic host control protocol (DHCP), and others are excellent choices for virtualization. These services generally require little resource overhead for internal networks and can be stacked into a single VM.
Next time, in Walking the Workload Tightrope Part Three, the final entry in this series, you’ll learn how to combine and separate virtualized workloads for optimal performance.