A few weeks ago social media lit up with news of support for running Exchange 2010 DAG members on virtualised clusters, e.g. a vSphere farm or a Hyper-V failover cluster. That much is true. Some of the chatter implied that Live Migration was supported.
I’ve downloaded and started reading a Microsoft whitepaper called Best Practices for Virtualizing Exchange Server 2010 with Windows Server 2008 R2 Hyper V.
On page 15, under the heading of Live Migration you can see:
Exchange server virtual machines, including Exchange Mailbox virtual machines that are part of a Database Availability Group (DAG), can be combined with host-based failover clustering and migration technology as long as the virtual machines are configured such that they will not save and restore state on disk when moved or taken offline.
OK. That says to me that Live Migration = good and Quick Migration = bad. That’s fine with me.
Now move on to page 28 to the heading of Hyper-V Failover Clustering.
“All failover activity must result in a cold start when the virtual machine is activated on the target node. All planned migration must either result in shut down and a cold start or an online migration that utilizes a technology such as Hyper-V live migration”.
That confirms it. Quick Migration was a process where a VM’s state was written to disk, the VM resource was moved to a target node, and the state was read from disk to start the VM. The Exchange product group do not like that. One might be forgiven for thinking that Quick Migration was a thing of the past but there are scenarios where one can build a Hyper-V failover cluster using software based replication solutions over sub 1 Gbps WAN connections. They still use Quick Migration.
If you are in that scenario then you need to be aware that a DAG member will be evicted if it is offline for 5 seconds. See page 29 for some instructions and PowerShell cmdlets for that situation.
On the other hand, the above text confirms that Live Migration is fine for DAG members running Exchange 2010 SP1 (the text that follows in the document specifies that version). Interestingly, the Exchange and Hyper-V groups found that CSV was much better than passthrough disks (page 29) in a Hyper-V failover cluster. Page 29 gives a bunch of guidance on things like bandwidth, jump frames, and receive side buffer.
Aidan,
Are there any guides or information out there regarding what specific items within Hyper-V we much configure to ensure that our “virtual machines are configured such that they will not save and restore state on disk when moved or taken offline.” Going through the properties and settings for one of my clustered resources, i found the following settings and was wondering if i could get your feedback?
Within the VM Settings:
Automatic Stop Action: Turn off or Shutdown (Not Save)
From the cluster resource Properties:
Cluster-controlled offline action: Turn off or Shutdown (Not Save)
Just wondering if i missed anything or need to change anything else. Your advice would be greatly appriciated!
#1 What you just specified – that hadn’t even occurred to me.
#2 Don’t use quick migration. Use Live Migration.
This is an old article, but timely! I currently have an Exchange 2010 server on a stand-alone 2012 R2 server. It’s configured as two servers, one with mailbox, the other with the CAS, HUB, etc roles. I’m concerned the old server will run out of space, so I’ve configured a second server and planned a live migration of my Exchange group over a weekend while traffic is low. I’ve successfully performed live migrations of other servers, but have not tried Exchange. Sounds like it’s supported by Microsoft. Has anyone successfully done this without shutting down the VMs first? They are both identical servers and the virtual switch names are the same on each box.