Stretching GeoClusters Further

Bruce Mackenzie-Low
MASTER TECHNOLOGIST

Bruce.Mackenzie@q.com
 Module
Overview Cloud Witness
Storage Replica
Site-aware Clusters
Implementing Sites
Preferred Sites
 Cloud Witness

New quorum option in Built-in Cloud Witness

Windows Server 2016 resource type

Used for stretched multi- Used for multi-domain

site clusters without and workgroup clusters
shared storage without shared storage
 Utilizes Microsoft’s Azure Cloud
Same as File Share Avoids having a 3rd Same Azure Storage
Witness, but uses datacenter to arbitrate Account can be used
Azure Blob Storage any quorum issues for multiple clusters

Use Failover Cluster

Very low ongoing cost
Manager or
since very little data is
PowerShell cmdlet
written to the blob file
Set-ClusterQuorum

For more details: https://technet.microsoft.com/en-us/windows-server-

docs/compute/failover-clustering/deploy-a-cloud-witness-for-a-failover-cluster
 Storage Replica

Storage-agnostic
Block-level replication
Synchronous or asynchronous
Works with site-aware failover clusters
 Storage Replica Details
Windows Feature installed via Server Manager or PowerShell
Supported in Stretch Clusters, Cluster to Cluster, or Server to Server
Source volume (data and log) are replicated to destination volumes
Destination volumes are dismounted during replication (i.e. no access)

Data Center 1 Data Center 2

Volume 1 Volume 2 Volume 1’ Volume 2’

Offline
Data Data Data Data
Replicates

Log Log Log Log

 System Requirements

 At least 2 servers with Windows Server 2016 Datacenter Edition

 At least 2GB of RAM and two cores per server
 Two sets of shared storage:
 SAS JBODs
 Fibre Channel SAN
 Shared VHDX
 iSCSI Target
 Storage must support Persistent Reservations
 At least one 1GbE network connection with < 5ms round trip latency
 Use Test-SRTopology cmdlet to check requirements

For more details: https://technet.microsoft.com/en-us/windows-server-

docs/storage/storage-replica/storage-replica-windows-server-2016
 Site-aware Clusters

Group cluster nodes according to physical location (site)

Identify a “Preferred Site” for the cluster and/or roles

Site awareness effects:

Failover behavior
Storage placement
Quorum behavior
Heartbeat thresholds
 Failover Behavior

Failover Affinity:
• Roles failover to a node within the same site before
failing over to a different site

• During Node Drain, VMs are moved to a node within

the same site before across sites

• CSV Load Balancer redistributes coordinate nodes

within the same site during CSV failover and when
nodes rejoin the cluster
 Storage Placement

Storage Affinity:
Virtual Machines will follow their CSV storage by being
placed in the same site with their storage
VMs will live migrate to the same site as their storage
after 1 minute of the storage being moved
 Quorum Behavior

Dynamic Quorum is reduced from the non-preferred site (DR site) to

ensure the Preferred Site survives if all things are equal

Node pruning occurs first in the DR site during regroup operations

Split Brain (even split between sites with no witness) favors the
Preferred Site
Nodes in the DR site drop out of cluster membership
Allows the cluster to survive a simultaneous 50% loss of votes
LowerQuorumPriorityNodeID property is deprecated in Windows
Server 2016
 Cross-site Heartbeat Thresholds

Configure heartbeat thresholds for cross site communication:

Property Default Value Description

CrossSiteDelay 1000 Amount of time between each
(milliseconds) heartbeat sent to nodes on dissimilar
sites
CrossSiteThreshold 20 Number of missed heartbeats before
the interface is considered down to
nodes on dissimilar sites

Use PowerShell to configure:

(Get-Cluster).CrossSiteDelay = <value>
(Get-Cluster).CrossSiteThreshold = <value>
 Heartbeat Rules

Cross-Site thresholds Cross-Site thresholds

override Cross-Subnet override Same-Subnet

Cross-Subnet thresholds Same-Subnet thresholds

used within same site used within same site
with different subnets and subnet
 Implementing Sites

Use PowerShell to create, view, and remove Sites

(aka Cluster Fault Domains)

PowerShell cmdlets:
 New-ClusterFaultDomain
 Get-ClusterFaultDomain
 Set-ClusterFaultDomain
 Remove-ClusterFaultDomain
 Creating Cluster Fault Domains
Two step process
1. Create the cluster fault domain
2. Assign fault domain membership

Create primary site and add Node1:

PS C:\> new-clusterfaultdomain -name Primary -faultdomaintype site -location “New York”
PS C:\> set-clusterfaultdomain -name Node1 -parent Primary

Create secondary site and add Node2:

PS C:\> new-clusterfaultdomain -name Secondary -faultdomaintype site -location “Denver”
PS C:\> set-clusterfaultdomain -name Node2 -parent Secondary
 Viewing Cluster Fault Domains

PS C:\> Get-ClusterFaultDomain | format-list –property *

Key fields:
Name – name of the fault domain (e.g. Primary, Secondary)

Type – type of fault domain (site, rack, enclosure, node)

Parent – parent fault domain (allows nesting)

Children – members of fault domain

Location – where the site exists

 Removing Cluster Fault Domains
Two step process
1. Remove all members from fault domain
2. Remove the cluster fault domain

Remove Node1 from Primary site and then remove site

PS C:\> set-clusterfaultdomain –name Node1 –Parent “”
PS C:\> remove-clusterfaultdomain –name Primary

Note:
 You must remove all fault domain members before removing the site
 Do not remove the “Node” fault domain type
Demo
Demonstrate implementing sites
(Cluster Fault Domains)
Establishing Cluster Preferred Site

Use PowerShell to identify the preferred site for the cluster

During a cold start, VMs are placed on the preferred site

(Get-Cluster).PreferredSite = <Site assigned to a set of cluster nodes>

For example:
(Get-Cluster).PreferredSite = Primary
Establishing Cluster Group Preferred Site

Use PowerShell to identify whether a group (role) is preferred by a site

Allows multi-master datacenters active for their preferred groups

(Get-ClusterGroup –Name <group-name>).PreferredSite = <site>

For example:
(Get-ClusterGroup –Name VM1).PreferredSite = Primary
(Get-ClusterGroup –Name VM2).PreferredSite = Secondary
 Placement Priority
Groups in a cluster are placed based on the following priority:
1. Traditional “Preferred Owners” takes precedence
2. Storage affinity site (group/role follows storage)
3. Group preferred site (prefer group sites over cluster site)
4. Cluster preferred site

Note:
Microsoft does not recommend using both Preferred Owners and Preferred Sites
(use one or the other)

For more details:

https://blogs.msdn.microsoft.com/clustering/2015/08/19/site-aware-failover-
clusters-in-windows-server-2016/
Demo
Demonstrate configuring the
preferred cluster site
 Leverage Azure to provide a cloud
witness for stretch clusters
Summary Storage Replica keeps data
consistent between data centers
Windows Server 2016 recognizes
sites (physical locations) to control
failover behavior
Use PowerShell to configure sites
and establish a preferred site for the
cluster and failover groups
 Windows Server 2016 provides significant
new functionality
- Hyper-V workloads
Course - Troubleshooting
Summary - Stretch clusters

Two new fundamental concepts

- Startup ordering (Sets)
- Site-awareness (cluster fault domains)

If you’ve enjoyed this course, check out:

Windows Failover Clustering Fundamentals
http://www.pluralsight.com/courses/windows-failover-clustering-fundamentals

Windows Performance Monitoring Fundamentals

https://www.pluralsight.com/courses/windows-performance-monitoring-fundamentals

Windows Kernel Debugging Fundamentals

http://www.pluralsight.com/courses/windows-debugging-fundamentals