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.

Note: For full details about VxRail stretched cluster and its requirements, see the Dell 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 VxRail 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.
• 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 48.    VxRail stretched cluster network requirements

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.

To ensure connectivity in the event of a site outage, the Cloud Foundation on VxRail networks must be extended across the two sites, and must adhere to specific connectivity requirements.

• Only Layer 2 is supported for the external management network between sites to prevent the need to re-IP the management components at the surviving site.
• Reserve a routable IP subnet for the vSAN network.
• vMotion can be either Layer 2 or Layer 3. A routable IP subnet is recommended for expansive virtual machine mobility.
• The NSX host overlay network must be routed between sites over a Layer 3 network.
• If the Application Virtual Network is deployed during Cloud Foundation on VxRail, the NSX edge overlay network and NSX node uplinks must be configured between sites. Layer 2 is supported for these networks.
• For Cloud Foundation on VxRail domains, Layer 3 is required between the sites housing the VxRail nodes and the witness site.

The witness site should be geographically dispersed from the stretched cluster sites in a separate failure domain, and therefore require routing services to enable connectivity. Having the witness in a separate failure domain enables it to distinguish a site failure from a network interruption between the stretched cluster sites. There might be limited instances where the stretched cluster is confined to a campus, but this model does not offer the same level of protection as a separate failure domain.

Figure 49.    Mapping of witnesses to VxRail stretched cluster sites

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.

If you deploy any Cloud Foundation on VxRail workload domains with stretched clusters as the underlying foundation, the VxRail cluster supporting the management workload domain must also be configured as a 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 configure the management workload domain on a VxRail stretched cluster at initial deployment. Converting an operational single site VxRail cluster instance to a stretched cluster requires additional planning and preparation as outlined in this section, as well as additional deployment work. The milestones for consideration include:

• Identify a second data center site to host the VxRail nodes to support the stretched cluster.
• Identify a third data center location for the stretched cluster witness.
• Configure the supporting networks in all sites to support VxRail stretched cluster requirements.
• Deploy the witness at the third data center site.
• Deploy additional VxRail nodes in the second data center site to balance with the VxRail nodes in the first data center site.
• Add the additional nodes into the existing VxRail cluster supporting the management workload domain.
• Convert the single site VxRail cluster to a stretched cluster.