If you deploy VxRail stretched clusters instead of a single-site cluster in order to meet availability requirements, be aware of the impact this decision has in planning the workload. A VxRail stretched cluster requires double the number of VxRail nodes to support any planned workload, as each site must be able to support that workload in the event of a site failure.

Figure 25.    Impact of VxRail stretched cluster on virtual machine workload

This is because every write operation by a virtual machine is synchronized on the vSAN datastore at both sites. This feature enables zero data loss in the event of a site-related failure.

There are several items of importance to consider when planning to use stretched clusters to support your Cloud Foundation workloads:

• If any of the applications targeted for the Cloud Foundation on VxRail instance are planned for a multi-availability architecture with VxRail stretched clusters, you must deploy a VxRail stretched cluster to support the management domain.
• With a VxRail stretched cluster, you must double the size of the physical storage positioned to support any planned workload.
• A feature in vSAN called ‘HCI Mesh’ supports the sharing of vSAN datastore resources between VxRail clusters. This is accomplished by a VxRail cluster mounting a remote vSAN datastore on another VxRail cluster and allocating those resources to local virtual machines. The ‘HCI Mesh’ feature is not supported with stretched clusters.

Deciding on local vs. remote workload domains

If you require support for workloads at multiple locations, you can choose a single-site deployment with a single point of management at each location, or have a centralized site designated to manage workloads at the local site and at remote sites.

Figure 26.    Remote workload domain WAN requirements

The decision whether to pursue a centralized site model must meet the following considerations:

• The number of nodes at the remote site to support the VI workload domain is limited to four nodes.
• The minimum network bandwidth between sites is 10 Mb per second.
• The maximum latency between sites is 50-millisecond round-trip time.
• Redundant WAN links between sites are strongly recommended to eliminate the WAN as a single point of failure.
• The management components on the management domain at the central site must be able to reach the workload domains at the remote sites.

Deciding on single region vs. multi-region

If your plans include expansion of Cloud Foundation on VxRail instances across regions using NSX Federation, consider both the latency and bandwidth of the physical network between regions. You can begin by deploying Cloud Foundation on VxRail in a single region, and decide to scale out into a multi-region architecture as a future expansion.

The maximum round-trip latency supported for NSX Federation is 150 milliseconds. Ideally, your latency between regions should fall within the performance threshold requirements set for the applications that are interconnected across regions. In addition, the network between sites must be configured to support NSX. The MTU size of the connecting network must be 1600 or larger.

Figure 27.    RTT latency for NSX Federation with Cloud Foundation on VxRail