VxRail provides high availability through VMware vSphere HA and vSAN fault tolerance policies. When a node fails, workloads automatically restart on surviving nodes within the same cluster. The number of simultaneous failures a cluster can tolerate depends on the vSAN storage policy configured, typically one or two failures. Disaster recovery is a separate layer. VxRail supports stretched clusters, asynchronous replication through vSphere Replication, and integration with third-party backup tools, but HA alone does not protect against site-wide outages or data loss.
Most VxRail conversations about availability start with the wrong question. Teams ask “what happens when a node fails” when the question they actually need to answer is “what level of failure can this cluster survive, under what conditions, and what does recovery look like when those conditions are not met.”
HA and DR are not the same capability. Conflating them produces environments that are protected against hardware failures but exposed to everything else. This article separates the two, explains what VxRail actually provides at each layer, and addresses where the gaps are.
High Availability vs. Disaster Recovery: Why the Distinction Matters
High availability is local. It keeps workloads running through hardware failures within a single cluster. When a node goes offline, HA detects the failure and restarts affected VMs on the nodes that are still up. The cluster absorbs the failure and continues operating. No human intervention required, no secondary site involved.
Disaster recovery addresses a different threat. DR is what determines whether the business can recover when an entire site fails, when the storage layer is corrupted, when ransomware has encrypted production data, or when a recovery plan that looked good on paper encounters reality. DR requires deliberate design, secondary infrastructure, tested runbooks, and a clear answer to the question: how long can the business be down, and how much data can it afford to lose?
VxRail has strong HA capabilities built in. DR requires decisions that go well beyond the platform. Understanding which layer covers which failure scenario is the foundation for designing an environment that is actually protected.
The Practical Difference
HA answers: will workloads keep running if this node fails? DR answers: will the business recover if this site is gone? Those are different questions with different answers, different costs, and different engineering requirements.
How vSphere HA Protects Workloads in a VxRail Cluster
vSphere HA runs continuously in the background across every node in the cluster. Each host sends heartbeats to the others. When a host stops responding, HA declares it failed and begins restarting the VMs that were running on it on the surviving hosts.
The restart process is not instantaneous. VMs experience an outage during the failure detection and restart window, which typically runs 30 to 120 seconds depending on cluster configuration and workload. This is a brief restart, not zero downtime. Applications that cannot tolerate any interruption need vSphere Fault Tolerance, which mirrors a VM’s state in real time to a secondary host. FT carries a performance cost and is designed for a small number of mission-critical workloads, not general cluster protection.
HA restart behavior is controlled by restart priority. Critical VMs are restarted first. Lower-priority workloads follow. The cluster’s admission control policy determines how much capacity is reserved to ensure HA can actually restart workloads when a host fails. Without proper admission control configuration, HA may not have enough headroom to restart everything after a failure.
This is a configuration issue that surfaces regularly in environments that have grown organically. The cluster was sized for HA when it was first deployed. Over time, workloads were added, capacity grew tighter, and the admission control buffer that made HA reliable at deployment is no longer adequate.
What Happens When a VxRail Node Goes Offline?
The sequence of events after a node failure is worth walking through specifically, because two things happen simultaneously and both matter.
On the compute side: vSphere HA detects the host failure through heartbeat loss, waits for the configured isolation response timeout, then begins restarting VMs on surviving hosts. Workloads move. The surviving nodes absorb the additional load.
On the storage side: vSAN checks whether all storage objects that were on the failed node are still accessible from the remaining nodes. Objects that were using the failed node as a component may now be in a “reduced availability” state, meaning they are accessible but no longer have their full configured redundancy. vSAN then begins a rebuild process to restore the configured fault tolerance level by creating new copies of the affected components on other nodes.
That rebuild consumes I/O on the surviving nodes. It runs in the background, but it is not invisible. In a cluster running near capacity, a rebuild after a node failure can noticeably affect workload performance. And during the rebuild window, the cluster is running with reduced fault tolerance. If a second failure occurs before the rebuild completes, the outcome depends on whether the storage policy has enough surviving copies to keep data accessible.
This is why the period immediately after a node failure is the highest-risk window in a VxRail cluster’s operation. HA has restarted the workloads. But the cluster is not back to its designed protection level until vSAN finishes rebuilding.
Understanding vSAN Fault Domains and Failure Tolerance
How many simultaneous failures a VxRail cluster can tolerate is not a cluster-wide setting. It is a per-VM storage policy.
vSAN uses a Failures To Tolerate (FTT) value to define how many simultaneous component failures a VM’s storage can survive while remaining accessible. The two primary protection methods are RAID-1 (mirroring) and RAID-5/6 (erasure coding). Each FTT level has a minimum node requirement:
| FTT Level | Simultaneous Failures Tolerated | Minimum Nodes Required | Protection Method |
|---|---|---|---|
| FTT=1 | 1 | 3 nodes | RAID-1 mirroring |
| FTT=1 | 1 | 4 nodes | RAID-5 erasure coding |
| FTT=2 | 2 | 5 nodes | RAID-1 mirroring |
| FTT=2 | 2 | 6 nodes minimum / 7 nodes recommended | RAID-6 erasure coding |
| FTT=3 | 3 | 7 nodes | RAID-1 mirroring |
A VM running with FTT=1 can survive one node failure without losing access to its storage. A second simultaneous failure makes that VM’s storage inaccessible. This is the design boundary, not a bug.
Fault domains extend this further. A fault domain groups nodes that share a physical failure boundary, such as a rack, a power circuit, or a top-of-rack switch. When fault domains are configured, vSAN places data components in different fault domains rather than different nodes. This means the cluster can tolerate losing an entire rack, not just a single node, without data loss, provided the FTT policy and fault domain count are configured correctly.
Most organizations deploying VxRail at smaller scale do not configure fault domains. For clusters spanning multiple racks or power feeds, not configuring them is a design gap worth addressing.
Single Node Failure vs. Multiple Simultaneous Failures
A single node failure in a healthy VxRail cluster configured with FTT=1 is a routine event. HA restarts the workloads, vSAN begins rebuilding, and the cluster continues operating in a degraded but functional state.
The scenario that creates real risk is a second failure during the rebuild window. vSAN rebuilds are not instant. In a cluster with large storage objects or limited spare capacity, a rebuild can take hours. During that time, the cluster is running with one fewer copy of the data than the policy requires. A second node failure in that window, depending on which node fails, can push objects below their accessible threshold.
This is not a theoretical edge case. It is a documented failure pattern in production HCI environments. The practical implication is straightforward: when a node fails in production, the priority is resolving it quickly. Not because HA cannot handle the restart, but because every hour the cluster runs in a degraded rebuild state is an hour of elevated risk.
For environments where two simultaneous failures must be tolerated, FTT=2 with a minimum five-node cluster is the correct configuration. FTT=2 doubles the storage overhead compared to FTT=1, which affects usable capacity calculations. That is a cost, not a reason to skip the protection.
How VxRail Stretched Clusters Provide Active-Active DR
A VxRail stretched cluster extends the cluster across two physical sites with a vSAN witness at a third location. vSAN synchronously replicates data between the two primary sites. If one site fails completely, the other site continues running with full access to all storage objects. The witness handles tie-breaking to prevent split-brain scenarios.
This configuration provides active-active operation. Both sites are running workloads under normal conditions. Workloads are distributed across both sites, and vSAN keeps storage synchronized between them in real time.
The infrastructure requirements are significant. Network latency between the two primary sites must stay under 5ms round-trip. The inter-site bandwidth needs to support the full vSAN write I/O of the cluster in both directions, because every write to either site is synchronously committed to the other before it is acknowledged. A stretched cluster with high write workloads on a stretched network link will perform poorly and may affect application latency.
The witness node at the third site has minimal storage and compute requirements, but it must be reachable from both primary sites at all times. Loss of the witness node during a site failure removes the tie-breaking capability and can prevent automatic failover.
Stretched clusters are the right answer for organizations with two active sites, adequate network infrastructure between them, and workloads that require the lowest possible RTO. They are not the right answer for organizations looking for a lower-cost DR option. The infrastructure, licensing, and operational complexity are all higher than asynchronous replication approaches.
Disaster Recovery Options for VxRail Environments
Stretched clusters are one DR option. For organizations that cannot meet the network requirements or do not need active-active operations, there are two other primary approaches.
vSphere Replication (Asynchronous)
vSphere Replication provides host-based asynchronous replication between two VxRail clusters at different sites. Because it runs at the hypervisor layer, it works independently of the underlying storage. Recovery point objective (RPO) is configurable, typically from five minutes to several hours. When a failure occurs at the primary site, the secondary cluster has a recent copy of the data and can resume workloads after a planned or unplanned failover.
This approach requires a second VxRail cluster at the secondary site, but it does not require the low-latency network connection that stretched clusters need. Replication runs asynchronously over a standard WAN link. The tradeoff is that some data written to the primary site after the last replication cycle is lost on failover. The RPO reflects that gap.
Newer vSAN ESA clusters running VMware Cloud Foundation 9.0 also support native vSAN-to-vSAN asynchronous replication built on vSAN snapshots. It requires an add-on license and is not yet common in production VxRail environments, but it is worth knowing as an option as clusters move to ESA.
Third-Party Backup and Replication Tools
Tools like Veeam, Zerto, and Commvault integrate with vSphere and vSAN to provide backup, replication, and recovery capabilities that run independently of Dell’s native LCM and vSAN replication. These tools offer more granular recovery options, including file-level and application-level recovery, and they handle failure scenarios that vSAN replication does not, such as data corruption and ransomware.
Most production VxRail environments use a combination of vSAN-level protection for infrastructure resilience and a third-party tool for backup and point-in-time recovery. Neither replaces the other.
| DR Approach | RTO | RPO | Network Requirement | Secondary Site Required |
|---|---|---|---|---|
| Stretched Cluster | Seconds to minutes |
Zero (synchronous) |
Sub-5ms latency between sites | Yes, active |
| vSAN Native Replication |
Minutes to hours (manual failover) |
5 min to hours (configurable) |
Standard WAN | Yes, VxRail cluster |
|
Third-Party Replication (e.g., Zerto) |
Minutes | Seconds to minutes | Standard WAN | Yes, any VMware target |
| Backup Only | Hours | Last backup interval | Standard WAN or local | Optional |
Do You Still Need Backup Software with VxRail HA and DR?
Yes. HA and DR address hardware failures and site failures. They do not address data loss.
vSphere HA keeps workloads running when a host fails. Replication keeps data available when a site fails. Neither protects against a user deleting a database table, an application bug that corrupts data silently over several days, or ransomware that encrypts production data and then replicates that encryption to the secondary site.
Backup software addresses a different failure category: the failure of the data itself rather than the infrastructure holding it. Point-in-time recovery, file-level restore, and application-consistent snapshots are capabilities that HA and DR replication do not provide.
Running VxRail without backup software because “HA handles failures” is a common and expensive misunderstanding. HA is not backup. Replication is not backup. They are infrastructure resilience features, and they work alongside a backup strategy, not instead of one.
Common Recovery Mistakes in VxRail Environments
These are the mistakes that show up consistently in environments that have been running for a few years without a structured review of their HA and DR configuration.
Running in a Degraded State Without Treating It as Urgent
A vSAN alert that a disk group is degraded or that objects are below their configured redundancy level is not a background notification. It is the cluster telling you that the next failure will be worse than the last one. Teams that acknowledge the alert and defer the fix are shortening the window between “manageable failure” and “data at risk.” Degraded vSAN states should be treated as active incidents, not scheduled maintenance items.
Admission Control Configured for Day-One Capacity, Not Current Load
Admission control reserves cluster capacity for HA restarts. It is typically configured at deployment and not revisited as workloads are added. An environment that has doubled its VM count since initial deployment may have an admission control policy that no longer reserves enough capacity to restart everything if a host fails. The policy shows green. The protection it provides is not what it appears to be.
Stretched Cluster Network Latency Creep
Stretched cluster performance depends on the network between sites staying within the latency threshold. Network changes, increased traffic, or infrastructure degradation between sites can push latency above 5ms without triggering an obvious alert. vSAN will continue replicating, but synchronous writes will begin to affect application latency. This tends to be discovered during performance troubleshooting rather than during proactive monitoring.
Assuming DR Replication Handles Ransomware
Ransomware that encrypts production data will replicate to the secondary site. The replication is working correctly. It is replicating exactly what it is designed to replicate: the current state of storage. If the current state of storage is encrypted, the secondary site will contain encrypted data. Recovery from ransomware requires a backup with a clean restore point that predates the infection, not a replica of the infected state.
Never Testing the Recovery Plan
A DR plan that has not been tested under real conditions is a hypothesis. Stretched cluster failover, vSAN replication cutover, and third-party replication failover all have operational steps, dependencies, and edge cases that only become visible when they are exercised. Organizations that have never run a DR test are not protected by their DR design. They are protected by the assumption that the design works.
If your environment is running with any of these conditions, the hidden cost of data center downtime article covers what organizations typically underestimate about unplanned outages. The VxRail lifecycle management article addresses a related risk: the period during and after a failed upgrade when the cluster is in an inconsistent state and HA behavior may not be what you expect.
For environments where the HA and DR architecture needs a review or where a degraded cluster state needs engineering attention, Maven’s VxRail support team handles both proactive assessments and active recovery situations. Direct Level 3 and Level 4 engineers, under-15-minute response, no escalation chain.
FAQ: VxRail High Availability and Disaster Recovery
Does VxRail provide disaster recovery?
VxRail supports DR through vSAN stretched clusters, asynchronous replication via vSphere Replication, and integration with third-party backup and replication tools. HA handles local hardware failures and is not the same as disaster recovery. Organizations should treat HA and DR as separate layers with different requirements, costs, and RTO/RPO targets.
What happens when a VxRail node fails?
When a VxRail node fails, vSphere HA detects the failure through heartbeat monitoring and restarts workloads on surviving nodes. vSAN simultaneously checks storage object accessibility and begins rebuilding data to restore the configured fault tolerance level. Workloads experience a brief restart period, not zero downtime, and the cluster runs with reduced fault tolerance during the rebuild window.
How many node failures can VxRail tolerate?
Failure tolerance depends on the vSAN storage policy applied to each VM. FTT=1 tolerates one simultaneous failure and requires a minimum of three nodes. FTT=2 tolerates two simultaneous failures and requires a minimum of five nodes. Tolerance is a per-VM policy, not a cluster-wide setting, and it applies to storage availability, not just compute restart.
What is a VxRail stretched cluster?
A VxRail stretched cluster spans two physical sites with a vSAN witness at a third location. vSAN synchronously replicates data across both sites. If one site fails completely, workloads continue running on the other. Stretched clusters require low-latency network connectivity between primary sites, typically under 5ms round-trip, and carry higher infrastructure and operational costs than asynchronous replication alternatives.
Does VxRail replace backup software?
No. vSphere HA and replication protect against hardware and site failures. They do not protect against accidental deletion, data corruption, or ransomware, which replicates encrypted data to secondary sites. Organizations running VxRail still require a backup strategy. HA and DR address infrastructure resilience. Backup addresses data recovery. They are separate capabilities that serve different failure scenarios.
What is the difference between VxRail HA and disaster recovery?
HA keeps workloads running through hardware failures within a single cluster. DR addresses what happens when an entire site or significant portion of infrastructure fails. HA is automatic and built into VxRail. DR requires deliberate design, secondary site infrastructure, and a tested recovery plan. Both are necessary. Neither substitutes for the other.
Related VxRail Resources
- VxRail Lifecycle Management: Firmware Updates, Automation, and Rollback
- VxRail Support: What Dell Covers vs. What You Need a Partner For
- What Is Dell VxRail? Architecture, Components, and How It Works
- VxRail Total Cost of Ownership
- Dell VxRail EOL 2025: Models, Dates, and Your Options
- Understanding EOL vs. EOSL in IT Hardware
- Why OEM Support Breaks Down During Critical IT Outage Recovery
- OEM vs. TPM Support Comparison
- The Hidden Cost of Data Center Downtime
Running a VxRail cluster in a degraded state, or need a second opinion on your HA and DR design?
Maven provides direct Level 3 and Level 4 VxRail engineering support for both proactive architecture reviews and active recovery situations. See our Dell VxRail support services or contact us directly.
