Stretched Clusters and Multi-Site Hyper-V on Windows Server 2025

Article 12 in the Hyper-V Cluster Design Fundamentals for v2025 series, and the final article. This article covers stretched clusters and multi site Hyper-V: stretch cluster versus campus cluster versus cluster to cluster replication, S2D stretch with Storage Replica, SAN stretch, campus cluster requirements (new in WS2025), site awareness configuration, quorum considerations, IP address handling across sites, the WS2025 stretch cluster failover issue community members have actively reported with Microsoft, and the multi site mistakes that turn a DR architecture into a DR incident.

Multi site clustering is where Hyper-V design gets hard. Single site clusters tolerate node and drive failures gracefully because the cluster can communicate over fast LAN connections and storage replication is a non issue. Multi site adds latency, partitioning risk, more complex quorum, IP address mobility problems, and a much larger blast radius for any architectural mistake. The features Microsoft documents work, but they require clean configuration and they have caveats that catch people out.

This article covers the topologies Microsoft supports, what each one buys you, where the operational gotchas live, and what is genuinely new in 2025. The goal is to make a deliberate architecture choice rather than discovering you built the wrong topology after the first DR test.

The three multi site topologies Microsoft supports

Per Microsoft Learn (Failover Clustering topologies), the three patterns for multi site Hyper-V on Windows Server are stretch cluster, campus cluster, and cluster to cluster replication. Each has a different operational model.

Per Microsoft Learn Storage Replica FAQ, the stretch cluster topology is ideal when the workload requires automatic failover with orchestration (Hyper-V private cloud cluster, SQL Server FCI). Cluster to cluster is ideal when you want manual failover or when the second site is provisioned for disaster recovery and not for everyday use.

S2D stretch cluster

Per Microsoft Learn (Failover Clustering topologies), in a Storage Spaces Direct stretch cluster configuration, each site operates its own independent Storage Spaces Direct storage pool. Storage Replica handles replication between sites and can be configured as synchronous or asynchronous depending on the distance and latency between locations.

Network requirements

Per Microsoft Learn, synchronous replication requires less than 5 ms round trip latency over the WAN connection. This requirement ensures good performance. Asynchronous replication does not have a published latency recommendation per Microsoft Learn (Stretch Cluster Replication Using Shared Storage page); it tolerates higher latency at the cost of giving up zero data loss guarantees.

The 5 ms RTT is the constraint that drives most stretch cluster placement decisions. At roughly 5 microseconds per kilometer one way through fiber, 5 ms RTT gives a theoretical upper bound of about 500 km of fiber path. In real designs, switch hops, carrier routing, non straight fiber paths, congestion, encryption devices, and operational safety margin push the practical distance much lower. Treat synchronous stretch clustering as a metro area design, not a regional distance guarantee.

Synchronous versus asynchronous

Per Microsoft Learn (Storage Replica overview):

• Synchronous. Mirrors data within a low latency network site with crash consistent volumes to ensure zero data loss at the file system level during a failure. The write is acknowledged to the application only after both sites have committed it.
• Asynchronous. Mirrors data across sites beyond metropolitan ranges over network links with higher latencies, but without a guarantee that both sites have identical copies of the data at the time of a potential failure.

The decision is RPO (recovery point objective) versus performance and distance. Synchronous gives you zero RPO but caps the distance and adds the round trip to every write. Asynchronous tolerates distance but accepts an RPO equal to the replication lag at the moment of failure.

Edition requirement

Per Microsoft Learn, S2D stretch cluster requires Windows Server Datacenter edition for full Storage Replica functionality. Windows Server Standard supports limited Storage Replica scenarios on Windows Server 2019 or later: a single replicated volume up to 2 TB. Production S2D stretch cluster designs should use Datacenter.

SAN stretch cluster

Per Microsoft Learn, a SAN stretch cluster relies on the storage area network vendor's replication capabilities to maintain data synchronization between sites. The SAN handles replication at the storage layer, presenting replicated LUNs to cluster nodes at both sites.

The Microsoft side of the configuration is straightforward: it is just a multi site Failover Cluster with shared storage that happens to be replicated by the SAN. The complexity lives at the SAN layer.

What to verify with the SAN vendor:

• Is the SAN replication mode supported for active passive or active active stretch cluster scenarios with Microsoft Failover Clustering?
• What is the failover orchestration? Does the SAN automatically promote the secondary LUN, or does it require manual intervention?
• What is the network latency and bandwidth requirement for the SAN replication?
• What is the supported configuration matrix for the specific SAN product and the specific Windows Server version?

Per Microsoft Learn, ensure your SAN solution is validated for stretch cluster scenarios and meets your specific disaster recovery objectives. The SAN vendor's interoperability matrix is the document that matters; do not assume a SAN that supports stretch on one Windows Server version supports it on the next.

Campus cluster (new in WS2025)

Per Microsoft Community Hub (Announcing Support for S2D Campus Cluster on Windows Server 2025), the S2D Campus Cluster is a new configuration supported on Windows Server 2025 with the 2025-12 Security Update (KB5072033, OS Build 26100.7462) applied on each Failover Cluster node. The use case: rack level resiliency within a single physical location connected by LAN, rather than site level resiliency across geographic distance.

Per Microsoft Community Hub directly: the S2D Campus Cluster does not use Storage Replica. It uses S2D replication between the cluster nodes. This is the key distinction from S2D Stretch Cluster (which does use Storage Replica between two geographically separated sites).

Requirements per Microsoft

• Windows Server 2025 with the 2025-12 Security Update (KB5072033) installed on every node in the failover cluster
• "Flat" S2D storage: all capacity drives of the same type. Flash based SSD or NVMe is recommended for performance. Caching tiers and HDDs are not recommended.
• Exactly two RACK cluster fault domains, with the cluster nodes placed in these two racks
• Cluster quorum resource (File Share Witness, Disk Witness, Cloud Witness, or USB Witness) placed in a third room separate from the data rooms containing the racks
• Rack Level Nested Mirror (RLNM), included in KB5072033, distributing data copies across racks: two copy volumes place one copy in each rack (50% capacity efficiency), four copy volumes place two copies in each rack (25% capacity efficiency)

Per Microsoft Community Hub, supported configurations include 1+1, 2+2, 3+3, 4+4, and 5+5 (nodes per rack). A 2+2 configuration with four copy volumes provides "Rack + Node" resiliency: you can lose a rack and a node and still have one copy of the data. Microsoft describes this as "a good tradeoff between cost and performance for many applications."

When campus cluster is the right answer

Campus cluster is appropriate when:

• The DR risk you care about is rack level (a rack PDU failure, a rack switch failure, a rack level cooling event) rather than site level
• Both racks are in the same physical building and connected by LAN, not WAN
• Workload performance characteristics need single S2D pool rather than two pools with replication
• You can deploy on WS2025 with the December CU and the recommended flash based capacity drives for performance

Campus cluster is not a substitute for stretch cluster across geographic distance. The two solve different problems. If your DR requirement is to survive the loss of an entire datacenter site, you need stretch cluster (or cluster to cluster replication). If your requirement is to survive a single rack failure within a healthy datacenter, campus cluster is the more elegant answer.

Cluster to cluster replication

Per Microsoft Learn Storage Replica overview, in cluster to cluster replication, one cluster synchronously or asynchronously replicates with another cluster. The configuration uses Storage Replica between clusters and supports Storage Spaces Direct, Storage Spaces with shared SAS storage, SAN LUNs, and iSCSI attached LUNs.

Per Microsoft Learn, you manage cluster to cluster replication using Windows Admin Center and PowerShell. The configuration requires manual intervention for failover, in contrast to stretch cluster topology which supports automated workload failover.

What this means operationally:

• Two completely separate clusters, one at each site
• Storage Replica between them keeping data in sync
• If the primary site fails, an operator runs the failover procedure: Set-SRPartnership to flip the replication direction, bring the volumes online at the secondary site, restart the VMs there
• RTO is measured in minutes to hours depending on the procedure and how well it is documented

Cluster to cluster is the right answer for true geographic disaster recovery where:

• The two sites are far enough apart that synchronous replication is not viable
• Manual failover is acceptable (the DR site is for disasters, not for daily operations)
• You want clean separation between the production and DR clusters for change isolation

Hyper-V Replica is a different solution

Hyper-V Replica gets confused with stretch cluster all the time. It is not the same thing and the design tradeoffs are different. Per Microsoft Learn (Hyper-V Replica Feature Overview), Hyper-V Replica is the built in replication mechanism for virtual machines that asynchronously replicates a Hyper-V virtual machine in a primary site to a replica virtual machine in a secondary site.

What separates Hyper-V Replica from stretch cluster, per the Microsoft Learn overview:

• Asynchronous only. Hyper-V Replica does not provide synchronous replication. The replication interval is configurable: 30 seconds, 5 minutes, or 15 minutes (introduced in WS2012 R2). RPO equals the configured interval at minimum.
• No shared storage required. Per Microsoft Learn: "Storage: No need for shared storage or specific storage technologies." Each host has its own local storage. Replication runs at the VM level, not the volume level.
• Workload agnostic and storage agnostic. Per Microsoft Learn, Hyper-V Replica works with any server, network, or storage vendor. The VM itself is what gets replicated.
• Standalone or cluster. Per Microsoft Learn: "Standalone or cluster: Primary and secondary sites can be running a standalone Hyper-V host or a cluster." A mix of standalone and clustered environments is supported.
• Active Directory optional. Per Microsoft Learn: "The Hyper-V host servers don't need to be domain members. If they are domain members they don't need to be in the same domain." Useful for cross organization or cross trust scenarios.
• Manual failover by default. Hyper-V Replica failover is operator initiated. Azure Site Recovery integration provides orchestration, but the base feature is manual.

The decision matrix:

The right answer for true high availability with zero RPO is stretch cluster. The right answer for cost effective DR with operational simplicity and a small RPO is Hyper-V Replica. They are not interchangeable, and "I want both sites available with VMs at each site" is not enough information to choose between them; the RPO and RTO requirements drive the choice.

Site awareness

For stretch and campus clusters, the cluster needs to know which nodes are at which site. Per Microsoft documentation, this is configured via fault domains.

The PowerShell pattern:

What this gets you:

• The cluster places workloads at the preferred site by default and uses the other site for failover.
• S2D placement and Storage Replica direction follow the site definitions.
• Quorum decisions during partition events factor in the site awareness.

The PreferredSite setting is the deliberate choice of which site is the active primary. It does not prohibit running on the other site; it sets the default.

Quorum for multi site clusters

Quorum in multi site is the part where most operational mistakes happen. The general guidance across Microsoft documentation and Microsoft Q&A discussions is to place the witness outside both data sites so the failure of either site does not degrade quorum.

The witness options:

• Cloud Witness (Azure). Uses Azure Storage as the tiebreaker. Requires internet connectivity from the cluster nodes. The natural choice when you do not have a third datacenter to host a file share witness.
• File Share Witness in a third location. A traditional approach. Requires a third site with a file server that both primary sites can reach.
• Disk Witness. Not appropriate for stretch cluster because the disk has to live at one site, biasing quorum toward that site.

Why the third location matters: in a stretch cluster with witness at one of the two sites, the failure of the witness site degrades quorum exactly when you need it most. The Microsoft Community Hub Campus Cluster guidance applies the same pattern at the rack level: Microsoft recommends the cluster quorum resource (File Share Witness, Disk Witness, Cloud Witness, or USB Witness) be placed in a third room separate from the data rooms containing the racks. The same logic applies to stretch cluster across sites: keep the witness out of the failure domains it is supposed to arbitrate between.

IP address mobility across sites

VMs failing over to a different site present an IP address problem. The VM's IP address belonged to the network at site A; if site A is down, the VM cannot use that IP at site B unless the network is set up to support it.

The four common patterns:

Stretched VLAN

The same VLAN exists at both sites with appropriate L2 extension between the sites (VXLAN, OTV, EVPN, MPLS L2VPN, or similar). The VM keeps its IP address across sites. Conceptually clean but operationally expensive: you are extending L2 across the WAN with all the failure mode complexity that brings.

Different subnets per site, DHCP and DNS

Each site has its own subnet. VMs get new IP addresses when they fail over. DNS is updated to point to the new IP. Lower TTLs on critical records reduce client cache impact.

Per Microsoft Learn (Stretch Cluster Replication Using Shared Storage page), techniques to support faster DNS site failover include lowering DNS TTL and using common patterns to reduce client side caching. The Microsoft documented configuration also includes using (Get-Cluster).ResiliencyDefaultPeriod=10 to configure VM resiliency so guests do not pause for long during node failures.

Network abstraction devices

Microsoft Learn lists network abstraction devices among the common techniques for stretch cluster networking. In practice these are load balancers, application delivery controllers, or proxies that present a stable client facing IP that maps to whichever site is active. The application clients connect to the abstraction device IP; the device routes to the active site. Adds an infrastructure dependency but keeps client configuration stable.

Software defined networking

Hyper-V SDN provides network virtualization that decouples VM IP addresses from physical network locations. The VM keeps its IP across the failover; the SDN fabric handles the routing. Capable, complex to deploy correctly. Microsoft Learn's stretch cluster documentation lists "Hyper-V software defined networking" among the techniques to support faster site failover.

The right pattern depends on the application. Stateless web services often work fine with DHCP plus DNS plus low TTL. Database listeners and application services with hard coded IPs need stretched VLAN or a network abstraction device. Mixed environments end up using more than one pattern.

Active passive versus active active stretch

The two operational modes for stretch cluster:

• Active passive. All workloads run at the primary site. The secondary site is for failover only. Simpler to design and operate. The secondary site infrastructure is mostly idle in steady state, which has a cost.
• Active active. Workloads run at both sites in steady state. Each site is the failover target for the other. Better resource utilization. Requires careful capacity planning so each site can absorb the other's workload during failover. Network latency between sites becomes a steady state performance concern, not just a replication concern.

Active active is appealing on paper and harder in practice. The capacity headroom math from article 9 applies to each site independently: if you want either site to absorb the entire workload during failover, each site needs to operate at 50% or less in steady state. Active passive avoids the math at the cost of idle DR site capacity.

For most production stretch clusters, active passive is the right starting answer. Move to active active only if there is a clear workload reason (latency sensitive customers at both sites, regulatory requirement to keep data physically in specific regions) and the capacity model is genuinely sound.

VM resiliency settings

Per Microsoft Learn (Stretch Cluster Replication Using Shared Storage page), you can configure VM resiliency so guests do not pause for long during node failures. The cmdlet:

This sets the default time the VM stays in the unmonitored isolated state before the cluster declares it failed and triggers recovery actions. The default is longer; reducing to 10 seconds means VMs fail over to the new replication source storage faster after a node failure. The tradeoff is that transient network glitches that would have self healed inside the longer default window now trigger failover.

For stretch cluster scenarios where node failures are real and the goal is fast recovery, the lower setting is appropriate. For single site clusters with stable internal networking, the longer default is usually fine.

Backup considerations

This is where multi site Hyper-V is famous for confusing people: stretched cluster with Storage Replica is not a backup. Microsoft Learn frames Storage Replica as protecting against hardware failures, natural disasters, and planned maintenance. Partner documentation including the Dell EMC Azure Stack HCI stretched cluster reference makes the explicit point: stretched cluster is a disaster recovery solution that keeps a business running in the event of a site failure, but customers should still rely on application and infrastructure backup solutions to recover lost data due to user error, application corruption, or data corruption.

Storage Replica is data synchronization. If somebody deletes a critical file on the primary, that delete replicates to the secondary. If ransomware encrypts the primary, the encryption replicates. Storage Replica gives you a live copy at the other site, not a point in time recovery target.

The proper data protection layering for multi site Hyper-V:

• Stretch or cluster to cluster replication for site DR (covered in this article)
• VSS based backup product for point in time recovery (covered in article 7)
• Immutable backup repository (hardened repo, object lock storage) for ransomware recovery
• Tested restore procedures, not just tested backup procedures

All four layers belong in the design. None of them substitutes for the others.

The multi site mistakes that bite you later

Treating Storage Replica replication as backup

Replication propagates everything, including the bad things. You still need point in time backup with retention separate from the replication target.

Witness at one of the two sites

If the witness lives at site A and site A goes down, quorum degrades exactly when you need it most. Use Cloud Witness or a third location file share witness for stretch cluster.

No DR test

Stretch cluster designs that have not been failover tested do not work as expected. Schedule a real failover test in a controlled window. The mistakes the test reveals (witness configuration wrong, network paths assumed, DNS TTLs not lowered, runbook missing steps) are cheaper to fix in a planned test than in an actual incident.

Assuming WS2025 stretch cluster works the way WS2022 worked

Per the Microsoft Q&A reports, multiple users have observed that WS2025 stretch clusters do not come up automatically after failover the way WS2022 did. Verify the current Microsoft known issue status and the support guidance before committing a production stretch cluster to WS2025. This is the topology where the failover behavior is the entire point.

Active active without the capacity math

Each site needs to be able to absorb the other site's workload. That means 50% or less per site steady state for true active active. In practice, environments doing active active often run hotter than that, which means a real site failure produces resource contention at the surviving site exactly when the workload needs to be stable.

Stretched VLAN without understanding the failure modes

L2 extension across WAN is operationally complex and has its own failure modes (broadcast storm propagation across sites, MAC table corruption, MTU mismatches, control plane convergence problems). If you do not have networking expertise to operate stretched VLAN, use DHCP plus DNS or network abstraction devices instead.

No DNS TTL lowering on critical records

Long DNS TTLs and client side caching can still delay failover after a site move. Review the TTLs on critical records such as database listeners, application VIPs, mail records, and manually created service records. For site failover paths, use deliberately low TTLs such as 60 or 300 seconds where the workload supports it. Drop them in advance of any planned failover so existing cached entries have time to expire.

Asynchronous replication used where synchronous is required

If the workload requires zero RPO and the site distance allows synchronous (under 5 ms RTT per Microsoft Learn), use synchronous. If you use asynchronous you are accepting some data loss during a failover, and the moment that matters is the moment somebody asks "how much did we lose."

Forgetting that campus cluster solves a different problem than stretch cluster

Campus cluster is rack level resiliency within a building. Stretch cluster is site level resiliency across distance. They are not interchangeable. If your DR requirement is "the building burned down," campus cluster does not help.

Confusing Hyper-V Replica with stretch cluster

Per Microsoft Learn, Hyper-V Replica is asynchronous, VM level, manual failover, no shared storage required. Stretch cluster is volume level, optionally synchronous, with automatic orchestrated failover and shared or replicated storage. They solve different problems with different tradeoffs. Picking Hyper-V Replica when the workload requires zero RPO is wrong; picking stretch cluster when the requirement is cheap DR with a 5 minute RPO is wrong. Decide based on RPO, RTO, distance, and operational complexity, not by which feature is more familiar.

No documented failover runbook

The runbook for a stretch cluster failover should be specific: what command to run, what to check before declaring success, what to do if the automatic path does not work, who to escalate to. Discovering at 3 AM during an incident that nobody documented the failover procedure is the most expensive way to find out.