Preferred Owner, Possible Owner and Anti-Affinity Groups in Failover Cluster. Part 1

Oh my!

This is going to be a 5-part blog series.

  • Part 1 (this part) will cover some theory and GUI configuration.
  • Part 2 will focus on setting Preferred Owners with PowerShell.
  • Part 3 will explain logic behind Possible Owners in PowerShell function.
  • Part 4 will cover the last step – setting anti-affinity groups.
  • Part 5 will describe reporting of current configuration in the cluster.

Intro

What it is, why may I need those and how to configure it – in the context of Virtual Machine resources?

By default settings for all high available Hyper-V VMs are:

  • run on any available node in the cluster (possible owners)
  • VM likes all nodes the same (no preferred owner).
  • VM likes all other VMs the same (not a member of any anti-affinity group).

There are three advanced failover policies I can set up for my VMs. Let’s assume I have 4 nodes (Node1-4):

  • Preferred Owners – this is the preference of first node to run on – describes which node is the BEST for this particular VM. If I configure Node3-4 for my VM as preferred owner, any time the VM is on another node it will migrate back to Node 3 or Node 4. Fallback option configures if and when to fallback (see pics below).
  • Possible owners – this sets to which nodes a VM can failover. If I configure my VM with Node2-4 it won’t be able to migrate to Node1.
  • Anti-Affinity – this is the preference to keep similar VMs apart from each other. If I have my VM1 and VM2 hosting same role (think DC, or SQL cluster) I want to keep them off the same nodes. With this settings cluster will try to keep it that way. If VM1 is on Node1 and VM2 is Node3 and I will try to migrate VM1 to Best Possible Node, cluster service will try to migrate it first to Node2 or Node4 if possible. If not (i.e. lack of resources) it will be put on Node3

Possible owners is the ‘hard set’. It will restrain VM from running on any other node. To configure this, VM must be on one of ‘possible owner’ list first. I cannot set this to Node3 and Node4 if VM is on Node1 or Node2.

Let’s try to configure these options with GUI first.

The GUI

  • Preferred Owners
    • Right click on any VM and select Properties then I can check which nodes are considered ‘Preferred’

    • On the Failover tab I can set fallback policies

  • Possible owners
    • Select VM, on the Resources tab on the bottom right click on the Virtual Machine Name, select Properties:

    • On the Advanced Policies tab select which nodes are Possible. By default, all are selected:

  1. Anti-Affinity Groups
  • There’s no way to set it up through GUI! 😀

Summary

Let me give a few examples in which scenarios this can be useful:

  • If some VMs share common data, we can set them to similar nodes to lower network traffic (preferred owner).
  • If some VMs must be on specific nodes – i.e. External Connector licensing or SQL by CPU core (possible owner).
  • If some VMs shouldn’t be on the same nodes – guest clustering, Domain Controllers, DFSR partners.

Stay tuned for next parts coming soon:

Part 1 was a bit of theory and GUI way.

Part 2 will focus on setting Preferred Owners with PowerShell.

Part 3 will explain logic behind Possible Owners PowerShell function.

Part 4 will cover the last step – setting anti-affinity groups.

Part 5 will describe reporting of current configuration in the cluster.

Advertisements

5 thoughts on “Preferred Owner, Possible Owner and Anti-Affinity Groups in Failover Cluster. Part 1

  1. Hi,

    congrats to your blog.

    We are running a Windows Server 2016 cluster infrastructure with about 20 nodes and ~600 VM’s. All nodes are licencensed as Windows Srv 2016 DataCenter MAK C (SPLA). About 50 of the VM’s are running MS SQL services (standard/enterprise…). So now we plan to create a new cluster with 4 nodes to run all the MS SQL VM’s on it and license the 4 nodes with a MS SQL Enterprise OSE license (operating system environment).

    Questions: Do we have to build the new cluster or would it be officialy possible to use the option “Possible Owners” as you write above?

    Like

  2. Thanks!

    We did it like this – with possible owners. It is a little troublesome during whole cluster shutdown so we will be using preferred owner rather.
    The license states that if host is licensed – the vm is. There’s nothing about clusters;) the vm HAS to be on the host to stay licensed. It can be migrated only during failure!
    This setting + logs from migration and we got certified from MS auditor that this is ok.

    We have 6 nodes with 300+VMs on S2D 😉 awesome piece of work.

    I need to get the reporting out – little time to blog!

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s