Deja vu. Well, almost. I sat in on a simliar session last year and I wondered what has now changed with vSphere being available and what new expectations could be had for virtualizing Exchange and I found answers. First of all, as the speaker put it – VMware has eaten their own dogfood and virtualized Exchange 2007 for their internal consumption. With approximately 55,000 mailboxes, that is an impressive feat itself.
Beyond internal consumption, all data points to Exchange evolving into a better workload to run within virtualization. Much of that can probably be attributed to Microsoft’s own virtualization technology, but Exchange on ESX benefits just the same. Performance gains out of ESX 4 make for a good combination with the improved I/O for Exchange 2007. Initial data for Exchange 2010 continues the trend of making Exchange a better workload in general and making it more appropriate to virtualize.
Primarily, the session was a presentation of lab work dones to measure the work loads using load generators and test environments. Those numbers are good to create best practice documents, but sometimes real world experience trumps these experiments. So by ‘eating their own dogfood’, I think VMware is endorsing the solution whole heartedly. No more, yes it should work with no problems.
But in the real world, we all realize there will be problems from time to time, and so support is a big issue. Microsoft, for its part, does not endorse running much of anything in a virtual machine. Of course, we all know it works – just look at Microsoft education services – all of their coursework is done in VirtualPC.
The session also covered support options, wisely, as that is a major barrier for adoption. Avenues for support include a Microsoft Premier support contract, which gets you support in any configuration; Microsoft support via the SVVP (Microsoft Server Virtualization Validation Program) with ESX 3.5 U2, Win 2008 and Exchange 2007; or support through an OEM like HP, etc., who are large enough to be able to offer their own support based on experience.
The session also focused on ways to establish resiliency and failover. This discussion covered Single Copy or Failover Clusters – the traditional MCSC clustering technique, Cluster Continuous Replication (CCR) for Exchange, VMware Fault Tolerence and protection utilizing VMware HA. I have a chart below that outlines some of the benefits and drawbacks from each method:
| Microsoft SCC | Microsoft CCR | VMware FT | VMware HA | |
|---|---|---|---|---|
| Pro’s | ||||
| Application Aware | Yes | Yes | No | No |
| Zero Downtime Failover | No | Yes | Yes | No |
| Automatic replication direction change on failure | No | Yes | No | No |
| Con’s | ||||
| Limited to 1 CPU | No | No | Yes | No |
| Requires Windows Enterprise | Yes | Yes | No | No |
| Requires Exchange Enterprise | Yes | Yes | No | No |
| Requires double the storage | No | Yes | No | No |
Ultimately, though, of the many solutions offered, there is no one correct way to implement this. It ultimately depends on your needs and which configuration most benefits your scenario. But the session provided lots of practical information for helping make those determinations for your real-world deployment.
