VCF 9.1 Deployment · Part 19 of 24

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. In VCF 9.1 you drive the stretch operation through the SDDC Manager API, which you reach from the VCF Operations Developer Center, while host commissioning and the witness host are handled in the vSphere Client.

1. Log in to VCF Operations as an administrator.
2. Open the vSphere Client for that domain and select the cluster you will stretch.
3. Confirm the storage type reads vSAN and that every current host is healthy.
4. Note the exact host count, because the second zone must match it.
5. Confirm the round trip time between the two zones on the vSAN network is 5 ms or less before you go further, for example with vmkping from an ESX host.

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 the vSphere Client, open Global Inventory Lists and go to the network pools view, or use the SDDC Manager UI at its FQDN.
2. 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 the vSphere Client, open Global Inventory Lists, then Hosts, then Unassigned Hosts. You can also use the SDDC Manager UI at its FQDN.
2. Click Commission Hosts.
3. On the Checklist page, review the prerequisites and click Select All, then click Proceed.
4. Enter the FQDN of the first zone two host, set the storage type to vSAN, and select 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. Turn on the Confirm All Finger Prints toggle, click Validate All, and wait for each host to report Valid.
8. Click Next, then 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 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. Log in to VCF Operations and open Developer Center, then APIs & SDKs.
2. Click the API Explorer link for the SDDC Manager API, then select the VCF instance that holds the management domain.
3. Build a stretch specification for the management domain default cluster that lists the commissioned zone two hosts, the witness FQDN and its vSAN network, and the host to uplink mapping on the distributed switch.
4. Retrieve the cluster ID with GET /v1/clusters and the zone two host IDs with GET /v1/hosts, then paste them into the specification.
5. Validate the specification with POST /v1/clusters/{id}/validations and confirm the result reports SUCCEEDED.
6. Stretch the cluster with PATCH /v1/clusters/{id} and wait for the task in Fleet Management to report Successful. The operation sets the preferred and secondary fault domains for you.

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 drive the same operation through the SDDC Manager 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://<sddc_manager_fqdn>/v1/clusters/<cluster_id>/validations \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d @validate-spec.json

A stretch specification names the second zone hosts, the witness, and a network profile for zone two. The full specification also carries an NSX host overlay pool, an uplink profile, and the transport VLAN for zone two under networkSpec. See the SDDC Manager API Reference Guide for the complete schema. Keep the host count equal to zone one.

{
  "clusterStretchSpec": {
    "deployWithoutLicenseKeys": true,
    "witnessSpec": {
      "fqdn": "vsan-witness-01.example.local",
      "vsanIp": "10.20.30.5",
      "vsanCidr": "10.20.30.0/24"
    },
    "witnessTrafficSharedWithVsanTraffic": false,
    "isEdgeClusterConfiguredForMultiAZ": true,
    "hostSpecs": [
      {
        "id": "<host_az2_1>",
        "hostname": "esx-az2-01.example.local",
        "hostNetworkSpec": {
          "networkProfileName": "az2-network-profile",
          "vmNics": [
            { "id": "vmnic0", "uplink": "uplink1", "vdsName": "cl01-vds01" },
            { "id": "vmnic1", "uplink": "uplink2", "vdsName": "cl01-vds01" }
          ]
        }
      }
    ]
  }
}

1. Save the specification above as stretch-spec.json and edit every placeholder value.
2. Request an access token from the SDDC Manager API and store it in the token variable.
3. For the validation call, wrap the specification in a clusterUpdateSpec object and save it as validate-spec.json, then run the call shown above.
4. Check the result in the response and confirm it reports SUCCEEDED before you continue.
5. If the validation reports an error, fix the flagged field, for example an unequal host count or a missing transport 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://<sddc_manager_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 Fleet Management, then Tasks, 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. When you stretch the cluster, SDDC Manager already changes the default datastore policy to site mirroring, so this step verifies that policy or creates an extra one that keeps a 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 rules for vSAN storage and click Next.
4. Set Site disaster tolerance to Site mirroring – stretched cluster 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	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

VCF 9.1 Deployment · Part 19 of 24
« Previous: Part 18  |  Complete Guide  |  Next: Part 20 »