In the second model, vCloud Director is installed in a single location, but with managed resources under the control of a single vCenter Server, typically co-located within the same management environment as vCloud Director. In this model, the single vCenter server controls resources in both the local and remote sites. Where in the dual vCenter Server model, the factor limiting the distance between sites is the network latency tolerance of vCloud Director, in this model, the limit is the network latency tolerance between vCenter Server and the resource hosts under its management. The following figure shows a representation of the relationships between the elements in this model.

 

Although this model appears less complex than the dual vCenter Server model, the decrease in complexity due to the elimination of the second vCenter Server instance is more than made up for in the operational overheads in managing a stretched vCenter Server. Although beyond the scope of this document, there are considerations with regard to VMware vSphere design, storage design, and both virtual and physical network design. As with the previous model, vCloud Director is installed in a single site and Cloud Providers must once again rely on a DR plan to recover the platform to the secondary site in the event of a failure at the primary site. Unlike the previous model, if the primary site becomes unavailable, so too will the vCenter Server which manages the resources at both sites. Instead of needing to recover only the vCloud Director instance, in this model, the Cloud Provider must first recover the vCenter Server to the remote location. Recovering both vCenter Server and vCloud Director is shown in the following figure.

 

This model requires an even more complex recovery plan to restore vCloud Director and vCenter Server as well as the supporting infrastructure and network configuration. In addition, the topology which the vCenter Server manages (and the associated vCloud Director Provider VDC) has also changed, so accommodation must also be made while the platform is operating in “DR mode” so that customers cannot provision workloads to the failed or inaccessible resources.