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 28.    Impact of VxRail stretched cluster on virtual machine workload

The reason for this is because every write operation by a virtual machine is performed on the vSAN datastore at both sites. Therefore, the size of the physical storage positioned to support any planned workload must be doubled.

In addition, there are a couple of other items of importance to consider with using stretched cluster to support your Cloud Foundation workloads:

• You must use DHCP to assign IP addresses to each VxRail node to support the overlay network required by NSX-T if your plans include VxRail stretched clusters to support the Cloud Foundation workload domains. Assigning static IP addresses to support the overlay network is not supported with stretched clusters.
• A feature in vSAN called ‘HCI Mesh’ support the sharing of vSAN datastore resources between VxRail clusters. This is accomplished by a VxRail cluster mounting a remote vSAN datastore 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 29.    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. 

Deciding on single region vs. multi-region

If your plans include expansion of Cloud Foundation on VxRail instances across regions using NSX-T 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-T 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-T. The MTU size of the connecting network must be 1600 or larger.

Figure 30.    RTT latency for NSX-T Federation with Cloud Foundation on VxRail