As an active consultant in the virtualization world, one of the most frequent questions I get from my clients is whether or not they should virtualize Exchange. Moreover, there's an increasing interest in the virtualization of this tier-1 application in regard to availability and performance in an existing vSphere environment. VMware's policy with Exchange (and many other core service apps) is to virtualize first. But what about support? With Microsoft's SVVP (Server Virtualization Validation Program), we're seeing first release apps like Exchange 2010 with full support out of the gate on VMware's vSphere 4 platform. So if Microsoft is saying it's okay, VMware is saying go for it, and your organization is in need of better performance and increased availability for your Exchange email environment, then the only thing you need to know now is what sort of catches, gotchas, and best practice recommendations you need under your belt before you take on the mighty Exchange application¦
Enter this blog series. I've hosted many seminars on Exchange 2007 virtualization, however with Exchange 2010 I wanted to take some time to give Microsoft and VMware administrators a reference point based on what I've experienced and learned with Exchange on VMware environments. So without further adieu, part 1:
Exchange 2010 Virtualization
RULE #1 - Size up your opponent
This isn't about distancing yourself from the bigger guy at the end of the bar; this is about getting nice and close with your user base and Exchange is all about your user base. The key here is to know what your expected CPU, memory, and, most importantly, your disk IOPs per user load, look like. Most organizations have several classes of users, so this isn't always a cut and dried answer. While I'd like to say that I wrote the book on figuring out MHz, MB, and IOPs requirements for users in an Exchange environment, I must admit that I look to Microsoft for ultimate guidance. Bookmark the following links for your sizing pleasure:
CPU - Calculate Megacycles Per User http://technet.microsoft.com/en-us/library/dd298109.aspx
RAM - Understanding Memory Configurations and Exchange Performance http://technet.microsoft.com/en-us/library/dd346700.aspx
IOPs - Exchange 2010 Mailbox Server Role Requirements Calculator http://msexchangeteam.com/files/12/attachments/entry453145.aspx
In order to keep this simple, I'll summarize the first two resource calculators, CPU and RAM:
When calculating CPU, Microsoft tells us that a moderate to heavy Exchange 2010 user (about 20 sent and 80 received emails a day), you need to provide about 1.85 MHz of CPU. I've heard this number debated several times, and ultimately you have to take into account IOP lag and active vs. passive database state, but for CPU requirements, I've never had any issues with this rule of thumb.
As far as RAM, Microsoft has a much simpler approach - for every CPU core, you need 2GB of RAM (at a minimum). The caveat is that for support, every role requires a minimum of 4GB of RAM. I'm of the mindset that you build out, not up, in a VMware environment, so I scale 2 vCPU and 4GB RAM CAS and Hub Transport servers as standard practice. In solutions where you've got fewer than 2,000 users, you can absolutely co-mingle CAS and Hub Transport roles. For organizations with fewer than 500 users, a basic configuration with Mailbox, CAS, and Hub Transport servers can easily be utilized. Mailbox servers are extremely capable at 4 vCPU 8GB of RAM, but again, use the above references for a clear picture of your environment.
Now when it comes to disk IOPs, this is where it becomes extremely important to utilize the Exchange 2010 Mailbox Server Role Requirements Calculator. Effectively this is a Microsoft Excel Workbook that walks through the profiling of up to 3 tiers of user mailboxes. It addresses database copy requirements, backup, link bandwidth for lagged copy databases, cached mode vs. online clients, etc, etc, etc; Take your time with this one and follow the directions on the Input tab. The Storage Design tab lays out disk requirements based on your expected IOP load. Keep in mind that Microsoft is NOT a storage company, so IOPs requirements can be interpreted and designed around without adhering to Microsoft's disk layout recommendation. The key is to understand disk write and disk read aggregate requirements, as well as total storage requirements per database. These numbers are found on the Role Requirement tab.
The Exchange 2010 Mailbox Server Role Requirements Calculator
So you should now have a clear view of the hardware requirements for your Exchange 2010 environment. Keep in mind that with Exchange virtualization, we follow hardware requirements in a virtual datacenter the same way we follow them in a physical one. So sizing up the hardware in terms of CPU, memory, and disk directly relates to resources allocated as vCPU, vRAM, and vStorage to Virtual Machines. Remember too that building out, not up, is a key factor to scale and performance with VMware. If youredesign is scaling out to VM's with 8 vCPU and 32GB of RAM, then you may want to consider chopping down your User-to-Mailbox Server ratio. With ESX servers, the goal is to commoditize your hardware, not dedicate it to one specific task. So the more dispersed your load can be, the better performance you see overall. To emphasize this point, take a look at the following case study by VMware on a 16k user environment: http://www.vmware.com/files/pdf/resources/16000_exchange_on_vmware.pdf
That's it for part 1 folks. In part 2, we'll dive into VMware's best practices as they relate to your vSphere environment and preparation for your new Exchange 2010 Virtual Machines.