Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

A friend of mine's shop is considering virtualizing several of their servers, including their Exchange servers (2007) and their BlackBerry-Exchange gateway systems.

The systems support roughly 150 mailboxes now, with limited growth projected over the next few years. The servers are not currently heavily utilized, but the company is investing in upgrades for other portions of their infrastructure, so this is an appropriate time to upgrade the exchange box as well. Storage space seems to be their biggest issue now; they'll be moving to a SAN for their storage if they go this way.

What guidelines would you use when considering whether a virtualized environment makes sense for exchange? Are there significant issues around Microsoft's support policies? At what sort of load levels does it no longer make sense to virtualize?

share|improve this question
2  
What version of Exchange is it? 2003 has a totally different IO profile from 2007, and 2003 is an exceedingly bad candidate for virtualization. It's IO-starved. Clarifying the version will help get you better answers. Hope that helps! –  Brent Ozar May 26 '09 at 19:12
    
Good point, thanks! I updated (it's 2007). –  Tim Howland May 26 '09 at 20:44
    
One thing to note, Unified Messaging is not supported when deciding to virtualize. –  Bigbio2002 Mar 15 '12 at 15:56

7 Answers 7

up vote 6 down vote accepted

We're running virtualized exchange 2007 right now, and we have a BES. Though we're not to that level of users. Though we're running on VMWare ESX, we haven't had a problem with Microsoft support policies, and have been able to get support when we need it. Works for us.

The biggest factors of any VM project are memory and (in my opinion) disk infrastructure. If these mailbox servers really are low utilization, then using disk-backed virtual disks should be just fine. If they do have some high utilization message-stores, those should probably go on NPIV enabled fibre channel and have those LUNs direct-presented to the VM. Our Exchange 2007 servers take a lot of RAM, which can make them a hard fit in a VM environment. In my opinion, if your RAM needs are close to or over 16GB, then physical hardware is a better fit.

share|improve this answer

VMware has a great page of resources with white papers on virtualizing Exchange: www.vmware.com/solutions/business-critical-apps/exchange/resources.html

We also did a nice podcast with community members asking questions to the VMware experts on this. blogs.vmware.com/vmtn/2009/01/virtualizing-exchange-roundtable-podcast-32.html sysadmin1138 is right -- getting your storage right is critical.

Because you can scale out with more VMs instead of scaling up with one big machine, we've put 16,000 Exchange mailboxes on one server -- so you should still have a bit of headroom with 150!

share|improve this answer

I would agree also with sysadmin1138. Memory and disk are your most critical points to consider in an implementation of that size. The system I administer has about 300 users with Exchange 2007 and BES virtualized with just about every other server in our environment as well on a pair of ESX servers. While memory is easily managed, estimated, and utilized, disk can be more challenging. Avoid SATA disk systems for Exchange due to the I/O limitations. Stick with SAS or FiberChannel disk. We use a NetApp 3020 system and have had great success with it in a VMware environment. That may be too much of an investment for your project though.

And as Mr. Troyer mentioned, VMware has some great information for virtualizing key applications like Exchange. I've managed two different shops where I've virtualized nearly 100% of my systems and have yet to have any kind of performance issues when using quality disk systems. Memory, as I said, is easy to manage and even overcommitting my host's memory still gives me a 12:1 virtual to physical ratio with great performance. Disk is far more critical and easier to get yourself in trouble by buying too little in terms of performance.

share|improve this answer

I just completed one such implementation. In this implementation, - I placed VM/VHD on a RAID 1 created using the inbox hard drives (SAS 15K 400GB) - I have a iSCSI target on the HOST and then used it as a pass-through drive for the VM. - Installed Exchange 2007 SP1 on the pass-thru drive - Allocated 4 virtual processors and 8GB RAM to the VM - Using VSS for backup of exchange data

So, here in this implementation, pass-thru disk provides the best possible IO performance for exchange VM. Being an iSCSI target, I can expand it whenever there is a need for more hard drive space. Hope this helps.

share|improve this answer
    
How many mailboxes does this support, about what level of usage? –  Matt Everson Jun 10 '09 at 20:47

Tim,

I went through a P2V early this year on an Exchange 2K3 system with a scale similar to yours. I did a short blog about it. Exchange is 90%+ about IO and RAM when it comes to performance. Take some performance monitor numbers in the current environment and make sure those same numbers and better are available to the VM. My VM sits on NFS with a few other VMs, the datastores sit out on (software)iscsi Raid10 15kSAS backed storage.

share|improve this answer

Don't forget Xen Server. It's free and really easy to setup. We're running 300 users on Xen using a Promise iSCSI SAN as storage. Link to a blog post here.

share|improve this answer

Microsoft has a good resource to Virtualizing on Hyper-V.

1) http://social.technet.microsoft.com/wiki/contents/articles/exchange-server-virtualization-resources.aspx

2) http://www.microsoft.com/download/en/details.aspx?id=2428

We're in the process of planning a similar deployment. We'll be using iSCSI to an external/fast RAID array for the mailbox storage. We've virtualized the mailbox on a VM, and put the CAS and hub transport roles on their own VM.

VMWare also has good resources for virtualizing Exchange. Even though we are using Hyper-V, we used their documents to read about different things we could do with DAGs (Database availability groups) and disaster recovery options. Most of these are possible to implement with either Hyper-V or VMWare running across two or more beefy (CPU and ram) boxes.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.