Powering The Shell

Building a Windows Server Failover Cluster (WSFC) that spans two geographically separate datacenters is one of the more demanding infrastructure exercises you will face. Done right, it delivers synchronous replication with zero data loss (RPO = 0) and automatic failover. Done wrong, you get split-brain, stale quorum, and storage that disappears at the worst possible moment.

This guide walks through the complete architecture and deployment of a two-site WSFC on Nutanix AHV, using Nutanix Volume Groups over iSCSI as shared storage and Nutanix Metro Availability for synchronous replication between sites. Every step is production-tested, including the gotchas.

Architecture Overview

The topology is two Nutanix AHV clusters in separate datacenters, four Windows Server 2022 nodes (two per site), and a single logical failover cluster spanning both. Shared storage is provided by Nutanix Volume Groups (VGs) exposed over iSCSI — not Nutanix Files, which lacks SCSI-3 Persistent Reservation support required by WSFC.

Site A (Primary DC)                     Site B (Secondary DC)
┌──────────────────────────┐            ┌──────────────────────────┐
│  Nutanix Cluster A       │◄──Sync────►│  Nutanix Cluster B       │
│                          │  Metro     │                          │
│  WSFC Node A1            │            │  WSFC Node B1            │
│  WSFC Node A2            │            │  WSFC Node B2            │
│  iSCSI Data Svc IP (A)   │            │  iSCSI Data Svc IP (B)   │
└──────────────────────────┘            └──────────────────────────┘
           │                                        │
           └─────────────┬──────────────────────────┘
                         │
                  Nutanix Witness VM
                  (Metro split-brain arbiter)
WSFC Quorum: Disk Witness (quorum VG disk)

Why Volume Groups over iSCSI?

• SCSI-3 Persistent Reservations: Required by WSFC for shared disk access control. Nutanix VGs support this; Nutanix Files (SMB/NFS) does not.
• Metro Availability support: VGs can be included in a Metro protection domain for synchronous replication.
• Shared access mode: A single VG can be attached to multiple initiators simultaneously — essential for WSFC.

Key Components

Network Requirements

• Inter-site latency: RTT ≤ 5ms. Metro Availability is synchronous — every write must be acknowledged by both sites before completing.
• Replication VLAN: Dedicated VLAN between sites for Metro replication traffic, separate from VM and management traffic.
• iSCSI network: Separate from VM traffic. MTU 9000 (jumbo frames) recommended.
• WSFC heartbeat: Dedicated NIC or VLAN for node-to-node cluster communication.
• Witness VM connectivity: Must reach both clusters on port 2020.

Phase 1 — Nutanix Storage Preparation

Step 1.1 — Configure iSCSI Data Services IP

Each Nutanix cluster needs a dedicated iSCSI Data Services IP — a virtual IP shared across all CVMs that Windows nodes use as the iSCSI portal address. Configure in Prism Element on each site:

PE → Settings → Cluster Details → iSCSI Data Services IP → Save

Verify via CVM CLI:

ncli cluster info | grep -i iscsi

Step 1.2 — Create Volume Groups

Create two VGs in Prism Element → Storage → Volume Groups: a quorum disk (2 GB) and a data disk sized for your workload. Enable Shared Access and SCSI-3 Persistent Reservations on both. Note the IQN for each:

ncli vg ls | grep -A 15 'WSFC'

Step 1.3 — Register Windows Node IQNs on VGs

Get the initiator IQN from each Windows node:

(Get-InitiatorPort).NodeAddress

Register all four node IQNs on both VGs:

ncli vg attach-iscsi-client vg-name=VG-WSFC-Quorum client-address=<NODE-IQN>
ncli vg attach-iscsi-client vg-name=VG-WSFC-Data client-address=<NODE-IQN>

Phase 2 — Metro Availability Configuration

Step 2.1 — Create Metro Protection Domain

In Prism Central → Data Protection → Metro Availability → Create Protection Domain. Set primary cluster to Site A, secondary to Site B, preferred site to Site A. Add both VGs under Entities → Add Volume Groups.

Step 2.2 — Deploy and Register the Witness VM

Use the dedicated Nutanix Witness Appliance OVA — not a standard AOS image. Deploy with Legacy BIOS (not UEFI). The Witness appliance is BIOS-based; using UEFI causes boot failure.

VM → Update → Boot Configuration → Legacy BIOS → Save → Power On

Register in Prism Central → Data Protection → Witness. The Witness VM must reach both clusters on port 2020. If you have no third site, deploying the Witness VM on the Site A CVM VLAN works — it provides arbitration for link failures while remaining reachable from Site B.

Step 2.3 — Verify Metro Status

Wait for status to reach In-sync before proceeding. Large VGs may take several hours to complete initial seeding. Do not attach WSFC nodes until confirmed.

Phase 3 — Windows iSCSI Connectivity

Step 3.1 — Enable MSiSCSI Service (all four nodes)

Start-Service MSiSCSI
Set-Service MSiSCSI -StartupType Automatic

Step 3.2 — Add Portals and Connect

# Site A nodes → Site A iSCSI Data Services IP
New-IscsiTargetPortal -TargetPortalAddress <SITE-A-ISCSI-IP> -TargetPortalPortNumber 3260
# Site B nodes → Site B iSCSI Data Services IP
New-IscsiTargetPortal -TargetPortalAddress <SITE-B-ISCSI-IP> -TargetPortalPortNumber 3260
Update-IscsiTarget
Get-IscsiTarget   # Both VG IQNs must appear
Connect-IscsiTarget -NodeAddress <VG-WSFC-QUORUM-IQN> -IsPersistent $true
Connect-IscsiTarget -NodeAddress <VG-WSFC-DATA-IQN> -IsPersistent $true
Get-IscsiSession | Select TargetNodeAddress, IsConnected

Common issue: If Get-IscsiTarget returns no output, the iSCSI Data Services IP is most likely not configured on the target cluster. Verify with ncli cluster info | grep -i iscsi on the CVM.

Phase 4 — WSFC Cluster Creation

Step 4.1 — Initialize Disks (Site A, Node 1 only)

Get-Disk | Where-Object {$_.PartitionStyle -eq 'RAW'} | Initialize-Disk -PartitionStyle GPT
New-Partition -DiskNumber <QUORUM-DISK-NUM> -UseMaximumSize -AssignDriveLetter
Format-Volume -DriveLetter Q -FileSystem NTFS -NewFileSystemLabel 'WSFC-Quorum' -Confirm:$false
New-Partition -DiskNumber <DATA-DISK-NUM> -UseMaximumSize -AssignDriveLetter
Format-Volume -DriveLetter D -FileSystem NTFS -NewFileSystemLabel 'WSFC-Data' -Confirm:$false

Step 4.2 — Create the Cluster

Test-Cluster -Node Node-A1,Node-A2,Node-B1,Node-B2 -Include "Storage","Network","Inventory"
New-Cluster -Name WSFC-PROD `
            -Node Node-A1,Node-A2,Node-B1,Node-B2 `
            -StaticAddress <CLUSTER-IP> `
            -NoStorage
Get-ClusterAvailableDisk | Add-ClusterDisk

Step 4.3 — Configure Quorum and Node Weights

Set-ClusterQuorum -DiskWitness 'Cluster Disk 1'
Get-ClusterQuorum   # Expect: NodeAndDiskMajority
# Verify all nodes have NodeWeight = 1
Get-ClusterNode | Select Name, NodeWeight, State
# Correct if any show 0
(Get-ClusterNode 'Node-B1').NodeWeight = 1
(Get-ClusterNode 'Node-B2').NodeWeight = 1

With four nodes (×1 vote each) + disk witness = 5 total votes. Majority = 3. Either site can independently maintain quorum with the disk witness.

Post-Deployment Validation Checklist

# Cluster health
Get-ClusterNode | Select Name, State, NodeWeight
Get-ClusterResource | Select Name, State, ResourceType
Get-IscsiSession | Select TargetNodeAddress, IsConnected
Get-ClusterNetwork | Select Name, State, Role

Mandatory planned failover test: Before production sign-off, execute a planned Metro failover via Prism Central → Protection Domain → Migrate. Confirm WSFC cluster roles move to Site B, then fail back. Only sign off after both directions are validated.

Common Issues and Resolutions

Steady-State Operations

Daily Health Check

# Quick cluster health
Get-ClusterNode | Select Name, State
Get-ClusterResource | Where-Object {$_.State -ne 'Online'}
Get-IscsiSession | Where-Object {$_.IsConnected -eq $false}

In Prism Central, verify Metro protection domain shows In-sync and Witness Connected daily.

Monitoring Thresholds

Planned Maintenance Sequence

1. Confirm Metro replication is In-sync
2. Migrate WSFC cluster roles to the non-maintenance site
3. Place Nutanix node(s) into maintenance mode in Prism
4. Perform maintenance
5. Exit maintenance mode
6. Verify Metro returns to In-sync
7. Fail back cluster roles to primary site

Summary

A two-site WSFC on Nutanix AHV with Metro Availability delivers enterprise-grade HA with RPO = 0 using native Nutanix capabilities — no external SAN required. The five decisions that make it work reliably:

1. Nutanix Volume Groups over iSCSI (not Files) for SCSI-3 PR compliance
2. Dedicated Nutanix Witness Appliance OVA with Legacy BIOS
3. iSCSI Data Services IP on both clusters before any Windows connectivity
4. Metro In-sync confirmed before WSFC node attachment
5. Disk Witness quorum with NodeWeight = 1 on all nodes

With these in place, the cluster withstands site failures, link failures, and planned maintenance windows without data loss and with minimal manual intervention.