Cloud Foundation on VxRail supports two types of VxRail clusters: one where all nodes are in a single site and a stretched cluster where the nodes are equally distributed between two sites. VxRail stretched cluster is targeted specifically for situations with very high RPO and RTO requirements, and as such includes additional requirements to those for a cluster in a single location.

For full details about VxRail stretched cluster and its requirements, see the ‘Dell EMC VxRail vSAN Stretched Cluster Planning Guide’. It can be found under the ‘Deploy’ heading on the Dell EMC VxRail product site: Dell EMC VxRail Stretched Cluster Planning Guide.

The foundation for VxRail stretched cluster is based on vSphere vSAN stretched cluster. The basic guidelines for a vSphere vSAN stretched cluster are:

• You must have three physical site locations
• The nodes that consist of the stretched cluster instance are spread evenly over two physical sites
• The third site supports the witness that monitors (using heartbeat) the health of the vSAN datastore that is positioned between the two sites. The required witness is a VMware virtual appliance, so the third site must have a vSphere platform at a supported VCF on VxRail version to support the witness

Figure 26            VxRail stretched cluster network requirements

The network between the sites must meet strict latency and bandwidth requirements, since it must support synchronous I/O to vSAN for the running virtual machines in the stretched cluster.

• 5 millisecond RTT between data node sites
• 200 millisecond RTT between data node sites and the Witness site

Figure 27            Network latency requirements for VxRail stretched cluster

Cloud Foundation on VxRail is supported on a vSphere vSAN stretched cluster as the underlying foundation, and the basic tenets for vSphere stretched cluster are applicable. There are additional networking requirements specific to Cloud Foundation on VxRail.

Figure 28            VCF on VxRail Networking Requirements

The network requirements differ based on whether the VI workload domain is based on NSX-V or NSX-T.

If you deploy Cloud Foundation on VxRail with VxRail stretched clusters as the underlying foundation, the cluster supporting the management workload domain must also be deployed as a VxRail stretched cluster. If at some point in the future there is the possibility of a VI workload domain being configured with VxRail stretched clusters, it is best practice to deploy the management workload domain as a stretched cluster. Converting an operational single site VxRail cluster instance to a stretched cluster is not supported. The only option is to reset the configured VxRail cluster back to its factory default state and rebuild the VxRail nodes into a supported stretched cluster.

Figure 29            One-to-one mapping of witness to VxRail stretched cluster

In addition to providing a third site to support the stretched cluster witnesses, note that a witness can monitor and support only one VxRail stretched cluster. This means that for every VxRail stretched cluster deployed for Cloud Foundation for VxRail, a witness virtual appliance must be deployed.

To support virtual machine network traffic between Cloud Foundation domains, the MTU size must be set to a minimum of 1600 at each site. The MTU size selected must also be configured for traffic destined for the witness site.