Node layouts, failure protection and latency limits for each VCF Operations cluster model, and how a VVF platform reaches them.
From Ultra Transcenders 2V0-16.25 by Tony Rough (coming October 2026)
There are three availability models for the analytics cluster. For VVF the installer starts small, and the larger models are reached by converting the running cluster.
| Model | Nodes | Protects against | Recovery approach | Notes |
|---|---|---|---|---|
| Simple | One analytics node (primary) | ESX host failure only, through vSphere HA restarting the VM | Restore from backup | Smallest footprint; can be scaled out later |
| High Availability (HA) | Primary and replica (a data node promoted to replica), plus optional further data nodes; the design deploys a three-node cluster | Loss of one analytics node | Replica takes over; restore from backup for wider loss | Optional external load balancer for the UI; DRS anti-affinity rule recommended |
| Continuous Availability (CA) | Equal numbers of nodes in two fault domains (primary/data paired with replica/data), plus a witness in a third location | Loss of an entire fault domain | Degraded operation, then repair or replace the failed fault domain | Latency under 10 ms between fault domains (peaks to 20 ms for 20-second intervals); witness within 30 ms |
https://<primary-node>/admin: add a data node that has a static address, let the cluster return to Online, then choose Activate under High Availability and nominate the new data node as replica. Because a running cluster must restart for HA to take effect, turning HA on before the cluster is first started is less disruptive. Deactivating HA turns the replica back into an ordinary data node.persistence.properties on the replica to make it primary.The VCF Operations certificate must list the FQDNs of all analytics nodes in its subject alternative name (SAN); collector FQDNs need not be included. Before adding a node, the certificate must be reissued to include the new node, and if an external load balancer fronts the UI its FQDN must be in the SAN as well.
Common trap: Expecting HA to survive the loss of a whole site - HA tolerates a single node failure inside one location; only CA, with paired nodes in two fault domains and a witness in a third, tolerates losing a fault domain.
This note is one section of Ultra Transcenders 2V0-16.25: VMware vSphere Foundation 9.0 Administrator, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Broadcom TechDocs.
Due on Amazon in October 2026, in Kindle and paperback editions.
About the book · 2V0-16.25 terms in the glossary · All 2V0-16.25 study notes
What VVF 9.0 includes, what only VCF 9.0 adds, and where the two share a code base.
Storage pools or disk groups: the hardware, memory and network each vSAN architecture needs, and how failures differ.
The rules in a vSAN storage policy, their defaults, and how mirroring compares with erasure coding.
Per-host or vCenter-managed networking, and the features only a distributed switch brings.
Cluster resource percentage, slot policy and dedicated failover hosts compared, with what each reserves.
How each library type gets and shares its content, and when subscribers download items.
The two vSAN encryption services, the threat each addresses and which one needs a key provider.