Remember how Live Migration and HA are 2 different things? HA is when a clustered host fails. The that are hosted on VMs have to fail over to another host and boot up. What if you had some n-tier app running on that host? Take this example where:
- There is a web server VM that depends on the app server VM.
- The app server VM depends on the database server VM.
- There is a database server VM.
Now what if they all failover at the same time and the web server boots up first. It’ll go looking for the app server and the web app will break, requiring some manual intervention – how very un-cloud-like.
Windows Server 2012 Failover Clustering allows us to set 1 of 4 failover priorities to our VMs. They can be:
- High: VMs with this value will failover and start first
- Medium: Any VM with this priority will failover and start second
- Low: Any VM with this priority will failover and start after the the Medium VMs
- Do Not Failover: What it says on the tin, intended for non-production VMs that you don’t need – useful when relying on Dynamic Memory to compress virtual workloads on fewer hosts after drastic host failures and you need to conserve RAM for production services.
If you had 10 VMs with the high priority then they all failover and start at the same time. Then your 20 Medium VMs would start after that. And your 100 Low VMs would start after the Medium ones.
You cannot create new priorities for yourself. You must use these priority levels if you want to use this feature.
Note that the failover priority level has absolutely no impact on Live Migration. And that’s because Live Migration and Failover/HA are two very different things. Your app dependencies should not be impacted by Live Migration because the VMs’ services will stay online and responsive during the migration.
This blog post is the property of Aidan Finn (@joe_elway / http://www.aidanfinn.com) and may not be reused in any manner without prior consent of Aidan Finn. You may quote one paragraph from this blog post if you link to the original blog post.