As virtual server technology has improved, virtualizing Exchange Server has become both a cheaper and less risky option. It’s no longer an experiment with your infrastructure but rather a sensible way to consolidate server costs. What’s less clear is what you stand to gain from moving Exchange Server to virtual machines.
Using virtual machine (VMs) to host Exchange in your organization -- as opposed to running it directly on physical machines -- opens up a range of new management options. For example, you can dynamically provision CPU and memory so that you can respond more quickly to changes in your Exchange environment.
That said, measuring the dollars-and-cents savings from virtualizing Exchange isn’t always clear. The following three aspects have the most serious economic implications for Exchange Server virtualization.
Table of contents:
Virtualizing Exchange: Power consumption
One commonly touted economic advantage of server virtualization is power savings. For example, if you have five servers, each of which each has an average utilization rate of 10% to 12%, consolidating them into one physical server provides a clear net savings. When it comes to Exchange Server, there’s always the possibility that some of your servers are underused, especially if you have multiple servers of one kind or another (such as a client access server array).
Analyze your infrastructure, and determine how much of it you are consolidating. Next, determine what else can be consolidated. The more that can be placed into VMs, the better justification there is for the entire virtualization project. If you are consolidating Exchange as part of an across-the-board project, you will save that much more energy.
Microsoft compared power usage between native-iron versus virtual environments, using a few different mix-and-match Exchange setups -- some client access, some hub transport and some mailbox server roles. In these scenarios, Microsoft cut power consumption by 50% on the servers alone, and by around 33% for power consumption of both servers and attached storage.
A good rule of thumb for consolidation: If you aren’t making gains of at least one-third in your power savings, it’s probably not worth the effort. One-fourth is acceptable, but with a one-third or more, it becomes that much easier to present management with a case for consolidation and to devote the initial outlay of budget for it.
It also helps to have numbers and concrete observations on hand to make intelligent projections. Back in 2008, Microsoft had an online tool for calculating energy savings in a virtualized data center (Hyper-Green.com), but it has since disappeared and been replaced with the Integrated Virtualization ROI Tool.
Virtualized Exchange: Server support
Microsoft has a fairly restrictive policy for which virtualized Exchange configurations it supports and which ones it doesn’t. This is partly so that Exchange shops don’t shoot themselves in the foot.
If a customer tries to set up virtualized Exchange Server in an infrastructure where Microsoft has explicitly stated that support will not be provided, the customer should at least know what it’s getting into. If an organization wants to take the risk, that’s another thing. Many admins will still prefer to let Microsoft bail them out if needed.
Virtualized Exchange commonly runs on Hyper-V and VMware. Of course, Hyper-V is a supported virtualization configuration, since Hyper-V is a Microsoft product and the company has taken pains to ensure that Exchange runs properly under it.
With VMware, Microsoft has a partner program called the Server Virtualization Validation Program (SVVP). This allows VMware users to obtain support from both Microsoft and VMware when virtualizing Exchange Server.
Many VM vendors are partners with this program, but Microsoft’s joint relationships for virtualization only go up to a certain point. For instance, VMware virtualization is supported for running Exchange, but VMware vMotion is not. This is because the latter product is not “application-aware” -- Microsoft’s words, not VMware’s.
Your mileage may vary, so do your homework before deploying virtualized Exchange. Also, make sure to read up on Microsoft’s policies regarding running its software in non-Microsoft VMs.
Economically speaking, the better you understand your support options before virtualizing, the less likely you’ll have to make a costly call to Microsoft or your VM provider. If you go with Microsoft, the cost comes directly out of your own pocket in the form of an incident report. If not, you may not be charged directly -- depending on your support contract -- but you may feel a pinch in the form of lost productivity.
Virtualizing Exchange: Examining your company’s usage profiles
Depending on your type of business and how Exchange is configured to support it, it may be cheaper to go with a virtualized environment -- but not always. Both Exchange Server and the virtual environments you can use to host it have a few behaviors that need to be taken into account:
- Licensing costs: Exchange Server licensing costs in a virtual environment can be tricky because of how Exchange is licensed, as well as how the virtual environment itself may be licensed.
If you reprovision Exchange to add new role servers, you'll have to figure in the license costs for those new Exchange role servers. If you have that new role server running on its own VM, it likely also means the cost of a license for a new instance of Windows Server as well.
- Capacity planning and overprovisioning. It’s easy to overprovision VM capacity. This can lead to serious financial waste from e-software licenses, extra electrical usage, etc. It’s even easier to do this with Exchange 2010 because of it its role-based server architecture.
The more statistics you have regarding actual Exchange usage in your organization -- even if it is information gathered from a physical deployment, not a virtual one -- the better idea you’ll have of how not to waste money. You may encounter pressure from other departments if you try to cut back from what you’ve originally provisioned, so the more numbers you have on your side, the better.
- Disk architectures: Planning disk pools for Exchange in a VM can be tricky because it’s not always clear where the money is going. For example, RAID 1+0 is recommended for hosting databases for large Exchange environments.
The cost of setting up RAID 1+0 can be problematic. Fifty percent of all disk space is purchased for the sake of redundancy. This looks like a waste, until you realize that this setup pays for itself in terms of the IOPS you gain, plus the protection that redundancy provides.
If redundancy and IOPS are important to you -- in a VM, they’re at least as important, if not more so, than on bare metal -- then the cost is more easily justified by a better-performing setup. Just make sure you can demonstrate that gain to the people who need convincing.
- Exchange Server role types: Some Exchange roles may perform better when run directly on bare metal, depending on the role type, its utilization and the virtual environment. Scott Lowe, CIO of Westminster College in Fulton, Mich., posted on TechProfile about situations where he would rather keep a physical server for Exchange than use a virtualized instance. Examples of such cases include real-time communication like unified messaging (UM) and Office Communications Server (OCS), where latency is a major concern.
Microsoft published a white paper about using Exchange Server 2010 with unified messaging in a virtualized environment. Microsoft recommends that UM be the only Exchange role for the virtualized machine it runs on. Microsoft also offers a white paper on Office Communications Server, which you should read if you plan to virtualize OCS.
Each passing year brings more reasons to consider virtualizing Exchange Server infrastructure. They include the growing pile of evidence for how it can reduce costs and increase efficiency. Virtualizing Exchange can also expand the functionality available to virtualized environments.
The trick is to know how and where the cost savings of virtualizing Exchange manifest in a world of VMs because they don’t always map directly back to the world of bare iron.
ABOUT THE AUTHOR
Serdar Yegulalp has been writing about computers and IT for more than 15 years for a variety of publications, includingInformationWeek and Windows Magazine.