Deployment models for vSphere Content Library

When talking to customers about vSphere Content Library deployments, one question I normally get is how best deploy Content Library for optimal workload deployment, especially in scenarios where remote or branch offices are involved? There are two main deployment models for vSphere Content Library as the title has alluded to. The main difference between the two is whether you have a single vCenter Server or if you have multiple vCenter Servers, with each managing its own vSphere infrastructure?

Lets refer to the single vCenter Server case as Scenario 1 and the multi-vCenter Server case as Scenario 2 and below are the two scenarios outlined with additional details.

Scenario 1 (Single vCenter Server):

In this scenario, which is a fairly common deployment for many smaller to mid-size organizations, where you only have a single or very few vCenter Server(s). They are used to manage several remote locations which only consists of ESXi hosts running at each of the locations and storage local to the site is available. In addition, there are several expected behaviors of the content itself which I have formulated into the following table below:

For this type of an environment, you would first setup a published library which stores all the content that you wish to distribute across your remote sites. Next, you would create subscriber library(s) consuming the published library, but instead of storing the replicated content locally, it is actually stored at each of the remote locations and their respective vSphere Datastore(s). This ensures that content is synchronized from our published library out to each of the remote locations, but when content is requested for deployment, the traffic is local to the site rather than going across the WAN.

In the above scenario, since there is only a single vCenter Server, if it ever becomes unavailable then provisioning and management to the remote location will also be unavailable. This is the expected behavior regardless if Content Library is configured.

Scenario 2 (Multi-vCenter Server):

In this scenario, each location has its own vCenter Server and set of local resources (ESXi hosts, vSphere Datastores, etc) that it manages. The expected behaviors of content management, distribution and deployment is also simliar to our first scenario which is highlighted below:

For this type of an environment, you would first setup a published library which stores all the content that you wish to distribute across your remote sites. Next, you would create a subscriber library at each of the remote locations where content will be replicated to the locally within the site. Simliar to our first scenario, content will also be synchronized from our published library out to each of the remote locations and when content is requested for deployment, the traffic is localized to the site rather than going across the WAN.

The added advantage with this deployment is that if your primary vCenter Server is unavailable, each remote location is unaffected and will be able to continue provisioning and have access to their local Content Library. In addition, if Enhanced Linked Mode is configured across the vCenter Servers and the ESXi hosts can communicate with each other, then Content Library replication will take place between host-to-host via NFC rather than over HTTP(s) between the vCenter Servers which can take advantage of things like VAAI for more efficient transfers.

As you can see in both scenarios, the characteristics of centralized content management, content distribution and optimal workload deployment from Content Library are exactly the same and can be achieved regardless if you have a single or multiple vCenter Server(s). Lastly, if you have more efficient method of replicating large amounts of data across your datacenter (array or network based tools), you also have the option of externally replicating your Content Library, have a look at this blog post here for more details.