If you’re thinking of virtualising Exchange 2010 on VMware, you might want to consider your options…
Update: VMware have since changed their licencing slightly in response to customer outrage (in fact, this post was intented to help that along). vRAM allowances have been increased, but the fact still remains - Virtualizing Exchange on VMware can cost thanks to these changes.
It’s not often I commentate on news, let along licensing changes - but upcoming changes to the licensing model for VMware will have significant implications for organisations looking to virtualise Exchange on the vSphere platform.
Yesterday, with the announcement of the latest incarnation of their virtualisation platform, VMware have introduced a new licensing model that makes major changes to the costs involved with virtualising memory intensive servers.
VMware’s upcoming changes still split features into different editions, and still license customers on a per-CPU basis, but in addition to this, vSphere is now licenced on the memory allocated to virtual machines, known as vRAM.
What is vRAM?
With vRAM each CPU licence comes with an allocation of memory that is assigned to a number of pools and shared amongst the virtual infrastructure. For each edition of ESX, you get the following vRAM amounts included:
- Standard Edition – 24GB per CPU licence
- Enterprise Edition – 32GB per CPU licence
- Enterprise Plus Edition – 48GB per CPU licence
If you need more vRAM, you need to buy more CPU licences for the same edition used on your hosts, and pools of vRAM cannot be shared among editions. So if you’ve got excess Standard Edition vRAM, you can’t offer it to your Enterprise Plus hosts and vice-versa. And just to be clear – this isn’t utilised RAM, it’s allocated RAM. You’re charged for it whether or not particular virtual machines need to use it it’s full allocation right now.
How does this affect virtual Exchange 2010?
Although many VMware employees and bloggers are talking about about how they don’t think people are right-sizing VMs (making sure VMs don’t have more memory than they really need), their thinking ultimately seems to be really be about how you should be sizing for the vSphere licencing, not the application. Exchange performance, especially for the mailbox role benefits from large memory allocations and these are easy to calculate using the Exchange team’s tools and guidance on TechNet. For many installations this may result in a number of Client Access Servers with 8GB RAM, Hub Transport with 4GB, Mailbox servers with upward of 32GB RAM and 16GB RAM for Unified Messaging servers.
These high RAM allocations mattered little, because memory is relatively cheap, especially in a high-density virtual environment. No longer so – as RAM will be need to be purchased a second time in a VMware environment, there is a direct cost associated with each virtual Exchange instance you deploy in addition to your hardware, and possibly in addition to existing VMware licensing:
| Exchange Role and RAM | vSphere Standard Cost | vSphere Enterprise Cost | vSphere Enterprise+ Cost |
| Client Access Server, 8GB RAM | $331.66 | $718.75 | $582.50 |
| Hub Transport Server, 4GB RAM | $165.83 | $359.38 | $291.25 |
| Mailbox Server, 48GB RAM | $1990 | $4312.50 | $3495 |
| Unified Messaging Server, 16GB RAM | $683.33 | $1437.50 | $1165 |
If you’re wondering where these RAM sizes come from – they are Exchange best practises and the sizing quotes come directly from VMware’s own sample guidance - VMware Exchange 2010 on VMware - Best Practices Guide with the exception of the Unified Messaging role RAM size which comes from Microsoft Best Practices for Virtualizing Exchange Server 2010 with Windows Server 2008 R2 Hyper-V. The pricing comes from VMware’s vSphere 5.0 Licensing, Pricing and Packaging document.
For each of the above VMs, don’t forget you’ll need to multiply these by the number of Exchange VMs you need; so VMware’s example of a clustered environment (in the above whitepaper, page 61) with a couple of UM VMs on Enterprise Edition (320GB RAM allocated in total), this would come in at $28,750 in VMware licensing alone – a minimum increase of $5,750 against 8 CPUs worth of Enterprise Licensing and the full amount if you need to go out and buy the whole 10 CPUs worth of licencing to cover your existing environment
Of course there is an argument that if you’ve already licensed vSphere, you’ll probably be OK - you might have tons of vRAM spare! Maybe, but maybe not according to VMware. As VMware’s own John Troyer says in this VMware forum thread, “we expect almost everybody to come out a little ahead (i.e., some excess vRAM capacity) just from their regular SnS upgrade from vSphere 4”.
So even VMware expect that as you embark on your next project, such as virtualising Exchange, your existing VMware licensing probably won’t cover the kind of requirements outlined above you’ll need to buy a fair bit of additional VMware licensing, even if you current physical infrastructure has enough capacity.
What’s the alternative?
As a VMware advocate who’s been virtualising mission-critical applications on ESX since version 2.1, in 2004, it pains me to say this – but in my opinion, Hyper-V is suddenly looking even more attractive. If you’re got vSphere, you have probably already invested a lot of money in your environment and the maintenance costs were the biggest expense – not enough to dump the investment in money, time and sheer energy to go to another product.
But, things change – if you’ve been in IT longer than 10 years then you’ll remember what happened to Novell in similar circumstances. You already have to licence Windows on your virtual infrastructure, so you have already paid for Hyper-V, and the time and costs to deploy SCVMM may be significantly less than the costs associated with VMware’s new licensing model. If you’re looking for a good pilot project for Hyper-V to prove it is good enough for your needs, Exchange 2010 may well be that project.
VMware release Exchange 2010 "Best Practices Guide" [Updated]
I recently read via Virtualization.info that VMware have released their "Best Practices Guide" for Exchange 2010. It transpires this was actually released a couple of months ago, however it's the first time I've seen it and I certainly think if you run VMware vSphere and plan on running Exchange 2010 it's worth a read.
VMware say in the best practices guide that "Exchange Server 2010 is proving to be an even better candidate for virtualization than its predecessors.", "The Exchange 2010 Mailbox Server role is lightweight, fast, and ready for virtualization." and "performance for a virtualized Exchange server is comparable to a non-virtualized server running on the same hardware".
So from VMware, it's no surprise to hear that Exchange is a perfect workload to virtualize on their platform. If you're currently running vSphere, and considering virtualizing Exchange 2010, VMware will definitely support this on their ESX platform. However, there are a few caveats…
If you're currently running an Enterprise vSphere deployment, shared storage will most likely be your number one platform for all your VMs running in your virtual environment. Without it, the key VMware features like vMotion, DRS and VMware HA don't work and you're left with your eggs in a number of delicate baskets. So it won't be shock that VMware say "It is preferable to deploy virtual machine files on shared storage ".. "This is considered a best practice for mission-critical Exchange deployments, which are often installed on third-party, shared-storage management solutions.". While I agree with the first part of that, I certainly don't agree that it's still best practice to use shared storage for Exchange - for starters Exchange 2010 no longer supports single copy clusters and CR based clusters such as DAG and CCR really excel when using DAS. Understandably, for VMware this is the main issue. vSphere in the Enterprise == Shared Storage, so to maintain this model they need to recommend shared storage for any application running atop the platform.
So, you've really got to use shared storage for Exchange on vSphere.. But that's OK, isn't it? NFS is getting wider acceptance for running VMs on and of course iSCSI is a great middle ground between F/C and NFS for using traditional storage protocols at a decent price… Well, iSCSI is supported for standalone Mailbox servers, but "For Mailbox servers that belong to a Database Availability Group, only Fibre Channel is currently supported".
According to VMware, though, only supporting DAG on F/C may not be a major problem, though. Instead of using DAG to have multiple database copies, VMware say "The building block approach is a recommended best practice for creating a standalone Exchange Mailbox Servers running on vSphere using pre-sized virtual machine configurations. Exchange servers that have been divided into virtual machine building blocks (as opposed to larger, monolithic Exchange servers) can simplify server sizing during the initial deployment and create a highly scalable solution using virtual machines with predictable performance patterns.". So if you don't mind only having one database copy (or copying it at the array level), the the combination of iSCSI+VMware+Exchange 2010 may be for you.
It's fair to say although there are a few disappointments in the document - like the focus on shared storage, gentle push to avoid DAG and the use of F/C disks in RAID 10s instead of large, dense SATA disks, it's still a worthwhile read (so long as you follow Microsoft's own best practices) and will help with small and large Exchange deployments on vSphere alike.
Download Exchange 2010 on VMWare - Best Practices Guide
Update 1: Microsoft have recently posted (a few hours after this post, taking into account the time difference) a response to the Best Practices guide: Answering Exchange Virtualization Questions and Addressing Misleading VMware Guidance
Update 2: VMware have responded to Microsoft's above post, addressing why VMware HA is a great compliment for DAGs: Virtualizing Exchange on VMware Provides More Recovery and Availability Options
Most useful VMware vSphere storage posts of the last year
I’m on training this week with my team, on the vSphere Fast Track 4.0 course as a pre-requisite for the VCP 4 exam (I missed the upgrade window… !) and conversations with the trainer led me to dig out a number of posts I’ve found very useful since vSphere’s release:
From the Official VMware Performance Blog - Performance Study of VMware vStorage Thin Provisioning – straight from the horses mouth a good doc on comparing thin vs thick vs eagerzero. Spoiler - Eagerzero wins!
Chad Sakac, VP of the VMware Tech Alliance at EMC is someone who has a lot of good contacts and seems to be able to get the best information on a subject concatenated into a single (albeit long post). Some interesting posts of his are Where should you thin provision and the Multivendor iSCSI post (which is by EMC, VMWare, HP, Netapp and Dell; there are NFS and VI3 ones also).
There’s also a couple of Thin Provisioning posts I’d found interesting over a VCritical - Responsible Thin Provisioning in VMware vSphere and The Last Resort - PowerShell Prevents Datastore Emergencies. Though to be honest, I don’t see why one would need to worry about this at the Datastore level if they don’t overallocate at the vSphere layer and instead manage at the SAN instead.


