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:
- Both sites run active workloads
- Over time, VM density becomes uneven
- Peak usage increases on one site
- A site failure occurs
- vSAN data remains available
- HA cannot restart all VMs
- 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.
