Architecting Admission Control in vSAN Stretched Clusters

Designing for FTT=1 and STT=1 Without Creating Hidden Risk

vSAN Stretched Clusters are often positioned as the pinnacle of on‑premises availability design: two active data centers, synchronous storage replication, and automated recovery. Yet in practice, many stretched clusters fail not because the technology is flawed, but because Admission Control is treated as optional or configured without regard to FTT=1 and STT=1 design assumptions.

Admission Control is not a tuning knob—it is the enforcement mechanism that determines whether a stretched cluster can actually survive a site failure.

This article walks through the architectural considerations for Admission Control in a vSAN Stretched Cluster configured with FTT=1 and STT=1, and why misalignment between storage policy and compute governance is one of the most common causes of partial outages.

Understanding the Design Intent: FTT=1 and STT=1

Before discussing Admission Control, we must clarify what FTT=1 and STT=1 actually mean in a stretched cluster context.

FTT=1 (Failures To Tolerate)

• Protects against one component failure
• Ensures data availability after:
  • A host failure
  • A disk group failure
• Achieved through mirrored or parity‑based replicas

STT=1 (Site Tolerance)

• Protects against loss of an entire site
• Ensures data availability when:
  • Site A or Site B becomes unavailable
• Implemented via:
  • One data replica per site
  • A witness to maintain quorum

Architectural takeaway:
FTT=1 + STT=1 ensures data survives a site failure.
It does not ensure that applications continue running.

That responsibility falls squarely on Admission Control.

Why Admission Control Is Critical in a Stretched Cluster

In a standard vSAN cluster, the failure domain is typically a host.
In a stretched cluster, the failure domain expands to an entire data center.

This fundamentally changes the admission control problem.

After a Site Failure:

• 50% (or more) of cluster compute capacity is lost
• 100% of surviving workloads must restart on the remaining site
• vSAN must simultaneously:
  • Maintain object quorum
  • Potentially resync or rebalance components

Admission Control is the only mechanism that prevents the cluster from consuming capacity required for this event.

Without it:

• VM placement drifts over time
• One site quietly becomes overutilized
• Failover becomes probabilistic instead of deterministic

Admission Control’s Role in Enforcing STT=1

When designing for STT=1, the architectural requirement is simple but strict:

Either site must be capable of running the entire VM population on its own.

Admission Control enforces this requirement by:

• Reserving sufficient CPU and memory headroom
• Blocking new VM power‑ons that would violate site‑loss survivability
• Preserving deterministic HA restart behavior

This is not about efficiency—it is about integrity of the design model.

The Most Common Anti‑Pattern: “We Have FTT=1, So We’re Covered”

One of the most dangerous misconceptions in stretched clusters is assuming that FTT=1 and STT=1 inherently imply availability.

What actually happens without Admission Control:

1. Both sites run active workloads
2. Over time, VM density becomes uneven
3. Peak usage increases on one site
4. A site failure occurs
5. vSAN data remains available
6. HA cannot restart all VMs
7. Business experiences a partial outage

From an architect’s viewpoint, this is a design failure, not an operational accident.

How Admission Control Should Be Designed for FTT=1 / STT=1

Percentage‑Based Admission Control Is Mandatory

Slot‑based admission control is unsuitable for stretched clusters.

Percentage‑based Admission Control allows you to:

• Reserve capacity relative to total cluster size
• Explicitly model site loss scenarios
• Adapt as hosts are added or removed

Architect guidance:
Set CPU and memory reservations so that losing one entire site still leaves sufficient capacity to restart all VMs.

---

Compute Must Be Over‑Reserved Beyond Simple Math

A common mistake is reserving exactly 50% capacity.

This ignores:

• vSAN resync overhead
• Memory overhead during VM restarts
• CPU contention from HA and storage services
• Temporary imbalance during recovery

Architect best practice:
Reserve additional headroom beyond theoretical site capacity—especially in:

• Manufacturing
• OT
• Regulated workloads
• Latency‑sensitive environments

Admission Control Must Align with Storage Policy

FTT=1 and STT=1 increase operational load during failures:

• More network traffic
• Higher CPU usage
• Increased memory pressure

Admission Control does not understand FTT or STT—but you must.

Design implication:

• Higher FTT/STT values require more conservative Admission Control
• Storage resilience without compute headroom results in degraded availability

What Happens If Admission Control Is Disabled

Disabling Admission Control in a stretched cluster is an explicit architectural choice—with consequences.

You Gain:

• Higher utilization
• Fewer power‑on denials
• Short‑term operational flexibility

You Lose:

• Guaranteed site failover
• Predictable recovery
• Audit defensibility
• Confidence in HA behavior

Disabling Admission Control converts a stretched cluster from a resilient system into a best‑effort platform.

That may be acceptable in dev/test. It is rarely acceptable in production.

Operational Considerations Architects Must Account For

Admission Control is not “set and forget.”

You must re‑evaluate it after:

• Host additions or removals
• Hardware refreshes
• Large VM onboarding
• Storage policy changes
• Workload behavior shifts

In stretched clusters, capacity planning is continuous governance, not an annual exercise.

Summary

• FTT=1 and STT=1 protect data
• Admission Control protects availability
• A stretched cluster must survive the loss of an entire site—not just store data through it

From an architect’s perspective, Admission Control is the enforcement layer that turns stretched‑cluster theory into operational reality.

If Admission Control is misconfigured or disabled, the cluster may survive a site failure—but the business may not.