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, because each site must be able to support that workload in the event of a site failure.
That 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 important items to consider when planning to use stretched clusters to support your Cloud Foundation workloads:
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.
The decision whether to pursue a centralized site model must meet the following considerations:
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.