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:
Content Management | Content Distribution | Content Deployment |
---|---|---|
Centrally Managed | Sync across the WAN | Workloads stored and deployed locally |
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:
Content Management | Content Distribution | Content Deployment |
---|---|---|
Centrally Managed | Sync across the WAN | Workloads stored and deployed locally |
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.
Erickson says
Content Library needs a local datastore for each cluster/ESXi? I thought with Version 6.5 is possible to store contents on a datastore managed by the vCenter Server instance, in order to centrally store and manage VM templates, ISOs, etc. But if I need local datastore for each cluster, and have a multiple of libraries how can it be called "centrally"?
Peter Scott says
Thanks for the information. Any chance you can add the benefits and differences to using a Datastore vs. File Share and how that decision impacts your deployment model?
Oliver says
NFC? I assume you mean NFS...
Dan says
Nope...NFC is Network File Copy
Dave says
Hello. i have a quick question. When you Create a VM from a template in the Content Library, does it always copy the .ovf file to a local ESX Datastore and do the destination datastore? The reason I ask is some of our boot Datastores are low in space. Sometimes when Creating a VM from a template the copying of the .ovf fails because of lack of space on the local datastore. Shouldn't it try to copy it from the datastore the Content Library is on to the destination datastore and skip the middle man which is the local datastore?
ahang jadid irani says
thank you for sharing such nice and useful information
Sushil KumarSushil k says
Looks like there is a big limitation wrt to ISO files when using content libraries. they cannot be shared across multiple clusters , which sort of defeats the first purpose of having content libararies. H