Private VCF as-a-Service - 3-AZ Stretched Cluster concepts
Discover the Private VCF as-a-Service Stretched Cluster 3-AZ architecture, how data is replicated across Availability Zones and how it handles failures
Objective
This guide presents the architecture of Private VCF as-a-Service Stretched Cluster 3-AZ: how the cluster is spread across three Availability Zones, how your data is replicated and how the platform reacts when a component fails.
Private VCF as-a-Service Stretched Cluster 3-AZ is in Beta. The Beta opens in December 2026 to a limited number of Enterprise customers. Find out more on the OVHcloud Labs page.
The stretched cluster principle
Private VCF as-a-Service is a VMware Cloud Foundation (VCF) 9.1 platform built on hardware dedicated to you and operated by OVHcloud.
In its Stretched Cluster 3-AZ form, your Workload Domain runs a single vSphere cluster whose hosts are spread across two Availability Zones (AZs) of the Paris 3-AZ region. These are the data AZs: both run your virtual machines and both hold a complete copy of your data. A third AZ hosts a witness, which takes part in the quorum only.
Storage relies on vSAN ESA, configured by OVHcloud. vSAN replicates your data synchronously between the two data AZs: a write is acknowledged only once it is stored in both. Both AZs therefore always hold the same data, and losing one of them loses no data: RPO = 0 by design, handled by the infrastructure.
RPO 0 requires mirroring between the two data AZs. Keep your VMs on a vSAN storage policy that mirrors their data across both sites: a VM placed on a policy that keeps its data in a single AZ is not replicated, and is not protected against the loss of that AZ.
When a data AZ fails, vSphere HA automatically restarts its virtual machines in the surviving AZ, with no intervention on your side.
Architecture
Your Workload Domain runs a single vSphere cluster, stretched over the two data AZs of the Paris 3-AZ region. The witness sits in the third AZ.
OVHcloud assigns the AZs: you get two distinct data AZs and a witness in the third AZ, but you do not choose which AZ plays which role.
What happens when something fails
The stretched cluster reacts on its own to the loss of a host, a data AZ, the witness or the link between the data AZs.
These are the standard behaviours of a vSAN stretched cluster, as documented by Broadcom.
A VM restarted by vSphere HA is not moved live: it boots again in the surviving AZ, and its applications start again with it. Each application's recovery time depends on its operating system and configuration.
Plan capacity for the loss of an AZ
For the VMs of a failed data AZ to restart, the surviving AZ needs enough free CPU and memory to run them. Size your workloads so that a single data AZ can run all the VMs that must keep running.
What the stretched cluster does not replace
The stretched cluster protects your workloads against the loss of infrastructure. It is not a backup and not a disaster recovery plan:
- synchronous replication copies everything to both data AZs at once, including a deleted file, corrupted data or files encrypted by ransomware;
- your workloads run in one single cluster: if that cluster is compromised, there is no second copy of it to restart from.
Keep a backup and, if your business needs it, a disaster recovery solution outside the cluster. The Beta does not include a managed backup service.
What is included around the cluster
Go further
Private VCF as-a-Service 3-AZ product page
Private VCF as-a-Service Stretched Cluster 3-AZ on OVHcloud Labs
For training or technical assistance implementing our solutions, contact your sales representative or visit our Professional Services page to request a quote and have your project analysed by our experts.
Join our community of users.