VCF 9.1 Deployment · Part 14 of 17

Status in a VCF 9.1 deployment: Optional. A stretched cluster is a topology choice you make only when you need one cluster to survive the loss of a whole site.
What it does: It spreads a single vSAN cluster across two availability zones in one region, with a witness at a third location, so virtual machines keep running if either data site goes down.
Depends on: A healthy VCF 9.1 management domain on vSAN, equal host counts in both availability zones, stretched Layer 2 networks between the zones, and a vSAN witness appliance at a third site.

TL;DR

• Prerequisites: VCF 9.1 on vSAN, an even and equal number of ESX hosts per availability zone, a stretched VM management network, stretched uplink and Edge overlay networks, and a witness host at a third site.
• Latency floors: 5 ms round trip or less between the two data sites, 200 ms round trip or less between each data site and the witness.
• Bandwidth floors: 10 Gbps or more between the data sites, 25 Gbps recommended, and 100 Mbps to the witness.
• Witness appliance sizes: Medium at 4 vCPU and 16 GB, Large at 4 vCPU and 32 GB, Extra Large at 8 vCPU and 64 GB. The witness runs no virtual machines and is not part of the vSAN cluster.
• Key steps: create a network pool for the second zone, commission its hosts, deploy and add the witness, stretch the management domain cluster first, then validate and run the stretch operation.
• Verify two fault domains with equal hosts, a healthy witness, and a site mirroring storage policy on the stretched cluster.

This part shows you how to configure a stretched cluster in VCF 9.1. You will prepare a second availability zone, deploy a vSAN witness appliance at a third site, and run the stretch operation so a single cluster spans two rooms or two buildings. When you finish, the cluster carries two fault domains with equal hosts and can lose a full site while your virtual machines restart in the surviving zone.

A stretched cluster is optional in a VCF 9.1 deployment. You add it when you need site level availability inside one region, not merely host level availability inside one room. Before you begin, confirm that your management domain is deployed on vSAN and healthy, that both zones have the same number of hosts, and that your network team has stretched the required Layer 2 segments between the two zones. VCF 9.1 stretches the management domain cluster first, then lets you stretch any VI workload domain cluster afterward.

Confirm every item below before you commission a single host in the second zone. A latency breach or an odd host count stops the stretch operation partway through and leaves the cluster in a mixed state.

Requirement	Value or version	Notes
VCF release	VCF 9.1	Management domain on vSAN, SDDC lifecycle green.
Host count per zone	Equal and even, 3 or more each	Both zones must hold the same number of hosts for balanced failover.
Site to site latency	5 ms round trip or less	Measured on the vSAN network between the two data sites.
Site to site bandwidth	10 Gbps or more	25 Gbps recommended for production write traffic.
Witness latency	200 ms round trip or less	From each data site to the witness at the third location.
Witness bandwidth	100 Mbps or more	Carries only metadata and heartbeat traffic.
Stretched networks	VM management, Uplink 01, Uplink 02, Edge overlay	Stretched at Layer 2 so NSX Edge appliances can fail over between zones.
Witness appliance version	Same ESX build as the cluster hosts	Runs no virtual machines and needs no vSAN data disks.

Note: If you stretch the VLAN backing a segment between the two zones, you must also stretch the Layer 3 gateway for that subnet, otherwise return traffic breaks after a failover.

Start by confirming that the cluster you plan to stretch runs on vSAN and that its current hosts all sit in what will become the first zone. VCF 9.1 moves stretch operations into VCF Operations and the vSphere Client, since the standalone SDDC Manager interface is retired in the 9.x line.

1. Log in to VCF Operations as an administrator.
2. Click the Inventory tab, then click Detailed View.
3. Select the VCF instance, expand the target domain, and select the cluster you will stretch.
4. Confirm the storage type reads vSAN and that every current host is healthy.
5. Note the exact host count, because the second zone must match it.
6. Open a browser tab to the vSAN network and confirm the round trip time to the second zone is 5 ms or less before you go further.

Hosts in the second zone need their own vSAN and vMotion IP ranges. Create a network pool that carries the zone two subnets so the commissioning step can hand each host the right addresses.

1. In VCF Operations, open the Fleet Management area and click Network Settings.
2. Click Network Pools, then click Create Network Pool.
3. Enter a name such as az2-pool so it is clear which zone it serves.
4. Add a vSAN network entry with the zone two VLAN, subnet, gateway, and an IP range that does not overlap zone one.
5. Add a vMotion network entry with the zone two VLAN, subnet, gateway, and IP range.
6. Click Save and confirm the new pool appears in the list.

Commissioning adds the zone two hosts to the global inventory so the stretch operation can claim them. Attach each host to the pool you just created.

1. In VCF Operations, open Fleet Management and click Hosts.
2. Click Commission Hosts.
3. Read the checklist, tick each confirmation box, and click Proceed.
4. Enter the FQDN of the first zone two host, set the storage type to vSAN, and select the az2-pool network pool.
5. Enter the host root user name and password, then click Add.
6. Repeat for every zone two host so the count matches zone one exactly.
7. Select all added hosts and click Validate All, then wait for each row to report a green result.
8. Click Commission and wait for the task to report Successful.

Download the vSAN witness appliance OVA that matches your ESX build and deploy it at the third site. Pick an appliance size from the table below based on how many components the cluster will hold.

Witness size	vCPU	Memory	Use when
Medium	4	16 GB	Typical stretched cluster with a moderate object count.
Large	4	32 GB	Higher object count or a larger host count per zone.
Extra Large	8	64 GB	Maximum scale with the largest component counts.

1. Download the vSAN witness appliance OVA for your ESX build from the Broadcom support portal.
2. Log in to a vSphere Client at the third site, right click a host or cluster, and click Deploy OVF Template.
3. Select the OVA file and click Next.
4. Enter a name such as vsan-witness-01, choose the third site host, and click Next.
5. Select the appliance size, for example Medium, and click Next.
6. Select the datastore at the third site and click Next.
7. Map the Management network and the Witness network to their port groups and click Next.
8. Set the appliance root password on the customize screen and click Next.
9. Review the summary and click Finish, then power on the appliance when the deployment completes.

Add the witness to the same vCenter that manages the cluster, but keep it outside the vSAN cluster object. It acts as a dedicated witness host, so it lives in its own place in the inventory.

1. Open the witness appliance console and set a management IP, subnet mask, gateway, and DNS through the direct console interface.
2. Create a forward and reverse DNS record for the witness FQDN and confirm both resolve.
3. In the vSphere Client, right click the datacenter object and click Add Host.
4. Enter the witness FQDN, click Next, and accept the host certificate.
5. Enter the witness root credentials and click Next.
6. Step through the remaining screens and click Finish, then confirm the witness appears with its light blue witness host icon.
7. Confirm the witness is not a member of the vSAN cluster and runs no virtual machines.

VCF 9.1 requires the management domain default cluster to be stretched before any workload domain cluster. This keeps VCF Operations and the management components reachable if the primary zone fails.

1. In VCF Operations, open the Inventory Detailed View and select the management domain default cluster.
2. Click Actions, then click Stretch Cluster.
3. Select the commissioned zone two hosts that belong to the management zone.
4. Select the witness host you added and enter the witness vSAN network details.
5. Enter a preferred fault domain name for zone one and a secondary fault domain name for zone two, using names with no spaces such as AZ1 and AZ2.
6. Map each zone two host to Uplink 01 and Uplink 02 on the distributed switch.
7. Click Validate, wait for a green result, then click Finish and wait for the workflow to report Successful.

If you have not yet placed NSX Edge clusters across both zones, plan that work alongside this step, because the Edge overlay and uplink networks must be stretched for the Edges to fail over cleanly.

For a workload domain cluster, you can drive the same operation through the VCF API. Build a stretch specification that lists the zone two hosts, the witness, and the uplink mapping, then validate it before you apply it. Replace the placeholder values with your own.

curl -k -X POST https://<vcf_ops_fqdn>/v1/clusters/<cluster_id>/validations \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d @stretch-spec.json

A minimal stretch specification names the second zone hosts, the witness, and the overlay VLAN for zone two. Keep the host count equal to zone one.

{
  "clusterStretchSpec": {
    "witnessSpec": {
      "fqdn": "vsan-witness-01.example.local",
      "vsanIp": "10.20.30.5",
      "vsanCidr": "10.20.30.0/24"
    },
    "secondaryAzOverlayVlanId": 1642,
    "hostSpecs": [
      { "id": "<host_az2_1>", "licenseKey": "<key>" },
      { "id": "<host_az2_2>", "licenseKey": "<key>" }
    ]
  }
}

1. Save the specification above as stretch-spec.json and edit every placeholder value.
2. Request an access token from the VCF API and store it in the token variable.
3. Run the validation call shown above and read the returned executionStatus field.
4. If the status is COMPLETED and the resultStatus is SUCCEEDED, continue to the next step.
5. If the validation reports an error, fix the flagged field, for example an unequal host count or a missing overlay VLAN, and run the call again.

Once validation succeeds, apply the same specification to the cluster. The operation configures two fault domains, adds the witness, and rebuilds the vSAN object layout across both zones.

curl -k -X PATCH https://<vcf_ops_fqdn>/v1/clusters/<cluster_id> \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d @stretch-spec.json

1. Run the PATCH call above to start the stretch task.
2. In VCF Operations, open the Tasks view and watch the stretch task advance through its subtasks.
3. Confirm the Configure Fault Domains subtask completes without error.
4. Wait for the whole task to report Successful, which can take a while while vSAN resynchronizes objects.
5. Open the vSphere Client, select the cluster, and click Configure, then vSAN Fault Domains to confirm two named domains with equal hosts.

A stretched cluster protects data by mirroring each object across both zones. Set a storage policy that keeps one copy in each zone and, if you have room, a second copy inside each zone.

1. In the vSphere Client, open Policies and Profiles, then click VM Storage Policies.
2. Click Create, enter a name such as stretched-mirror, and click Next.
3. Enable host based rules for vSAN storage and click Next.
4. Set Site disaster tolerance to Dual site mirroring so a full copy sits in each zone.
5. Set Failures to tolerate to 1 failure with RAID 1 mirroring inside each zone if the host count allows it.
6. Click Next, review the compatible datastore, and click Finish.
7. Apply the policy to the cluster default and to any virtual machines that need site level protection.

Run these checks in order. Each one confirms a different layer, from fault domain layout to a real site failover test.

Check	Where	Expected result
Fault domains	vSphere Client, vSAN Fault Domains	Two named domains with an equal number of hosts each.
Witness health	vSAN Skyline Health	Witness host green, no metadata or heartbeat alarms.
Object resync	vSAN Resyncing Objects	Resync count drops to zero after the stretch completes.
Storage policy	VM Storage Policies	Dual site mirroring policy compliant on the cluster datastore.
Site latency	vSAN performance service	Site to site round trip stays at or under 5 ms.
Failover test	Maintenance window	Powering off a zone restarts its VMs in the surviving zone.

For the final check, schedule a maintenance window, place every host in one zone into maintenance mode with the ensure accessibility option, and confirm that vSphere HA restarts the affected virtual machines in the surviving zone.

Four failures account for most stalled stretch operations. Each has a clear cause and fix.

Symptom	Cause	Fix
Configure Fault Domains task fails	Unequal host count between the two zones	Commission more hosts so both zones hold the same number, then rerun the stretch.
Validation rejects the witness	Witness build does not match the cluster ESX build	Redeploy the witness OVA that matches the cluster build and add it again.
Objects will not resync	Site to site latency above 5 ms round trip	Work with the network team to bring the vSAN link within budget, then retry.
Edges do not fail over	Uplink or Edge overlay network not stretched at Layer 2	Stretch the uplink and overlay segments, and the Layer 3 gateway if the VLAN is stretched.

Is a stretched cluster mandatory in VCF 9.1. No. It is an optional topology that you configure only when you need one cluster to survive the loss of a whole site inside a single region.

How many hosts do you need in each zone. An equal and even count, with at least 3 hosts per zone, so vSAN can mirror objects and keep quorum after a site failure.

Do you need a physical witness host. No. The vSAN witness appliance runs as a virtual machine at the third site, needs no dedicated license, and holds only metadata, so it uses no data disks.

Why must you stretch the management domain first. Because it keeps VCF Operations and the management components online if the primary zone fails, which is what lets you manage the rest of the stretched estate.

What latency can the witness link tolerate. Up to 200 ms round trip between each data site and the witness, which is far looser than the 5 ms budget between the two data sites.

• Stretching vSAN Clusters in VMware Cloud Foundation, TechDocs 9.1
• Deploying the vSAN Witness Appliance, TechDocs 9.1
• SDDC Manager Workflows in VMware Cloud Foundation 9.1, TechDocs
• Stretched Topologies using vSAN Storage Clusters in VCF, VCF Blog

« Previous: How to Deploy Private AI Foundation with NVIDIA on VCF 9.1 (Part 13)
★ VCF 9.1 Deployment Complete Guide
Next: How to Converge an Existing vSphere Environment to VCF 9.1 (Part 15) »