{"id":7022,"date":"2016-02-01T07:45:54","date_gmt":"2016-02-01T06:45:54","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/windows-server-2016-new-site-awareness-feature\/"},"modified":"2016-02-01T07:45:54","modified_gmt":"2016-02-01T06:45:54","slug":"windows-server-2016-new-site-awareness-feature","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/windows-server-2016-new-site-awareness-feature\/","title":{"rendered":"Windows failover cluster 2016 : new site awareness feature"},"content":{"rendered":"

After my first two blogs about cloud witness<\/a> and domain-less dependencies<\/a> features shipped with Windows Server 2016, it\u2019s time to talk about another pretty cool feature of the WSFC : site awareness that will also benefit to our SQL Server FCIs and availability groups.<\/p>\n

But before to talk further about the potential benefits of this new feature, let\u2019s go back to the previous and current version of Windows Server that is 2012 R2. Firstly, let\u2019s assume we have a Windows failover cluster environment that includes 4 nodes spread evenly across two data centers and a FSW on a third datacenter as well.<\/p>\n

\"blog<\/a><\/p>\n

Assuming we use the dynamic quorum feature, all the node members and the FSW as well will get a vote in this specific context. If we lose the FSW, the system is intended to reevaluate dynamically the situation and it has to drop weight for a cluster node. We are able to influence its behaviour by configuring the LowerQuorumPriorityNodeID <\/em><\/strong>property (please refer the end of my blog here<\/a>). For example, if we want to maximize the availability of the Windows failover cluster on the first datacenter (on the left), we have to change the quorum priority of one of the cluster node on the second datacenter (on the right) as shown below:<\/p>\n

\"blog<\/a><\/p>\n

Now, with Windows Server 2016, this property is deprecated and the site awareness feature will replace it. We will able to define and group cluster member nodes into sites. So let\u2019s assume we want to achieve the same design than previously. To meet the same requirements, we have to define two sites and give the priority to the first site (on the left).<\/p>\n

\"blog<\/a><\/p>\n

Actually, sites and site preference may be configured only by using PowerShell and the new property site by using the following syntax:<\/p>\n

(Get-ClusterNode \u2013Name <node>).Site=<site number><\/pre>\n
For example, on my test lab, I have configured two sites at the cluster node level to reflect the situation shown on the above.<\/p>\n
\"blog<\/a><\/p>\n
Then, I have configured my preferred site at the cluster level in order to prioritize my first datacenter to survive to the 50\/50 failure scenario (by changing the PreferredSite<\/em><\/strong> property):<\/p>\n
(Get-Cluster).PreferredSite=<site number><\/pre>\n
 <\/p>\n
\"blog<\/a><\/p>\n
Now let\u2019s simulate we face a failure of the FSW and let\u2019s take a look at the new node weight configuration<\/p>\n