Building a Multi-Site vSphere Stretched Cluster for Disaster Recovery

A multi-site vSphere stretched cluster places ESXi hosts and virtual machines across two physical locations while presenting them as a coordinated VMware environment. The design can provide rapid recovery from a site outage because workloads remain protected by shared storage, vSphere High Availability (HA), and carefully engineered network connectivity.

The most common implementation uses VMware vSAN with two data sites and a third-site witness. This architecture differs from a conventional backup strategy: it is designed to keep services available or restart them quickly after a host, storage, network, or site failure. It does not eliminate the need for backups, application-level replication, or a documented recovery plan.

Successful deployment depends more on placement, latency, bandwidth, and failure-domain design than on simply adding hosts to a cluster. The stretched cluster must be engineered so that a site failure produces a predictable result rather than a split-brain condition or an avoidable storage outage.

Define The Failure Domain

Begin by documenting what the design must survive. A host failure, an entire rack outage, loss of a storage controller, and complete loss of a data center are different events with different recovery behavior. Establish recovery time objectives (RTOs), recovery point objectives (RPOs), and application dependencies before selecting the vSphere configuration.

A typical stretched vSAN cluster contains a preferred site, a secondary site, and a vSAN witness appliance or witness host in an independent third location. The witness does not store virtual machine data. It maintains metadata and contributes a third vote, helping the cluster determine which data site should remain active when communication between the primary locations is interrupted.

The two data sites should be separate failure domains with independent power, cooling, switching, and upstream connectivity. If both locations share a single building distribution frame, carrier circuit, or power source, the architecture may provide host-level resilience but not genuine site-level disaster recovery.

Validate Network And Platform Prerequisites

Latency between the data sites is a primary design constraint. vSAN traffic is synchronous, so every write must be acknowledged according to the storage policy and the health of the path. Verify supported round-trip latency, bandwidth, packet loss, and jitter against the exact vSphere and vSAN release. Vendor limits can change between versions and storage architectures, so the VMware Compatibility Guide and release documentation should be authoritative.

Use redundant Layer 3 paths where possible, with consistent MTU configuration across the entire route. Validate jumbo frames end to end rather than enabling them only on ESXi interfaces. vSAN, vMotion, management, and virtual machine traffic should be logically separated, and dedicated physical uplinks are preferred for storage and inter-site replication traffic.

Each host should meet the same CPU generation, memory, network adapter, disk controller, and vSAN device requirements. Confirm firmware interoperability, driver versions, vSphere licensing, and supported vSAN architecture before deployment. Inconsistent hardware can turn a site failure into a cluster-wide availability problem.

Build The Stretched Cluster

Create the vSphere cluster with HA and DRS enabled, then add hosts from both data sites using clear naming and inventory conventions. Configure vSAN fault domains so each host is assigned to the correct site. The witness must be placed outside the two data-site fault domains and should use a reliable, low-latency management path to both locations.

Storage policies determine how virtual machine components are distributed. A policy such as “Primary site” or “Secondary site” can influence preferred placement, while failures-to-tolerate and site-level protection settings determine whether data is mirrored across locations. Review the resulting object layout in the vSAN health and capacity views instead of assuming that a policy name guarantees the expected placement.

Site affinity is useful for keeping workloads near dependent services and reducing unnecessary cross-site traffic. However, it should be applied selectively. A database, application tier, and domain controller may require different placement rules, and hard-coding every virtual machine to one site can complicate recovery after a failure.

Compare Recovery Behavior

A stretched cluster provides several recovery modes. vSphere HA can restart virtual machines on surviving hosts after a host or site failure, while vMotion and DRS support planned maintenance when both sites are healthy. Storage policies continue to govern whether objects are available and compliant after a failure.

Failure Scenario	Expected Cluster Behavior	Administrator Focus
Single ESXi host failure	HA restarts affected virtual machines on another host	Confirm capacity and admission control
Disk or device failure	vSAN repairs or resynchronizes components according to policy	Check resync traffic and object compliance
Planned site maintenance	Evacuate workloads and place the site into maintenance mode	Validate evacuation and remaining-site capacity
Complete data-site outage	Cluster remains active from the surviving site when quorum is maintained	Verify witness connectivity and application startup order
Inter-site network partition	Witness voting determines the surviving partition	Avoid independent administrative actions on both sides
Witness outage	Data sites may continue operating, but site-failure protection is reduced	Restore witness service promptly

A site outage does not automatically mean every application is healthy. Virtual machines may restart successfully while databases, clustered services, licensing systems, or external dependencies remain unavailable. Define startup priorities, heartbeat behavior, DNS dependencies, and IP addressing requirements for each application stack.

Capacity planning must include the loss of one data site. The surviving site needs enough CPU, memory, network throughput, and storage performance to run critical workloads and handle vSAN resynchronization. Admission control should reflect the actual failure scenario rather than the normal operating state.

Configure Operations And Monitoring

Monitoring should cover vSAN health, object compliance, resync duration, congestion, latency, packet loss, witness reachability, and host hardware status. Configure alerts in vCenter and integrate them with the organization’s monitoring or incident-management platform. A green dashboard is not a substitute for testing, but a missing alert can delay response during a real outage.

Use vCenter identity, role-based access control, syslog, and time synchronization consistently across both locations. NTP or an equivalent time source is important for logs, certificates, authentication, and troubleshooting. Document the management-plane dependencies that could prevent administrators from controlling the cluster during a site event.

Backups remain essential. Stretched storage protects availability and synchronous data placement, but it does not protect against ransomware, accidental deletion, corrupted application data, or malicious administrative changes. Maintain isolated backups and test file-level, virtual-machine-level, and application-level restoration separately from cluster failover tests.

Test Failover Before Production

Testing should begin with non-disruptive validation. Confirm vSAN object health, witness participation, host isolation response, HA admission control, DRS rules, and application monitoring. Then perform controlled host failures, link failures, and planned site evacuation during an approved maintenance window.

A full site-failure exercise should verify the actual sequence: loss of site connectivity, witness arbitration, virtual machine restart, DNS and network availability, application dependency recovery, and user access. Measure RTO and compare it with the documented target. Record any services that require manual intervention.

After recovery, test failback just as carefully. Resynchronization can consume substantial bandwidth and storage resources, especially when many objects become noncompliant at once. Allow the cluster to return to a healthy state before moving workloads back, and review alarms, logs, and performance data after every exercise.

Apply Practical Design Controls

Use these controls to keep the stretched environment supportable:

• Keep the witness in a genuinely independent failure domain with reliable connectivity to both data sites.
• Validate latency, bandwidth, MTU, routing, and packet loss continuously rather than only during installation.
• Size each site to run critical workloads after losing the other site, including vSAN repair overhead.
• Use storage policies, VM-Host affinity, and DRS rules deliberately, then test their behavior during failures.
• Maintain immutable or offline backups and document application recovery steps outside vSphere.

A multi-site vSphere stretched cluster is most effective when treated as an engineered availability platform rather than a replacement for disaster recovery planning. Build the network and failure domains first, verify storage-policy behavior, and test real application recovery under controlled conditions.

Use the resulting design as a living runbook: record dependencies, ownership, escalation paths, and recovery evidence after each test. When the environment is built around measured failure behavior instead of assumptions, vSphere HA, vSAN, and the witness can provide dependable protection across data centers.