The two multisite stretched vCloud Director models both introduce complexity in day-to-day operations and in a business continuity disaster recovery (BCDR) planning. If Cloud Providers have gone to the trouble of implementing one or other of these models (and sometimes both), there must be a benefit to doing so either for the provider or their customer.

The dual vCenter Server model allows the provider to offer services to their customers across multiple physical locations which, subject to the network latency restriction, allows the customer to benefit from a degree of protection from a loss of service or access at a single provider data center. Depending upon the design of the network interconnectivity between them, customers can treat the two sites as two halves of a single solution, distributing elements of their service to each of the provider locations. With a DNS-based traffic management or load balancing solution in front, a customer solution can be designed to tolerate the loss of a single site without noticeable downtime, while taking advantage of synchronous replication of data between the two sites.

The single vCenter Server model offers similar benefits to those outlined above, with the advantage that, with resources managed from a single vCenter Server, Cloud Providers can offer enhanced replication, migration, or recovery services between sites through, for example, the deployment of a workload stretched metro-cluster. Because both the virtual machines and the virtual infrastructure which underpins them are under the control of a single vCenter Server, workloads moved between sites do so without the need to be “exported” from one vCenter Server and “imported” into another. Even so, careful consideration is required to make sure that the workloads can still be managed through vCloud Director after any migration or recovery.

The advantage that both models offer, beyond what has already been discussed, center on the ability of the customer to manage their vCloud Director Organization and services from a single portal. Separate vCloud Director instances at each provider location are independent of each other, requiring the provider to establish organizations and users and to carry out other administrative tasks at each site. The customer then logs in separately to each vCloud Director instance to manage services at that site. Similarly, automation tasks directed at the vCloud Director API must target the API endpoint at each location.

Despite the fact that Cloud Providers could offer these enhanced services with vCloud Director v8.20 and earlier, it forced a compromise in which the Cloud Provider had to trade a more convenient, simplified, and improved user experience offering for a more complex, difficult to deploy, manage, and support provider platform.