• Skip to primary navigation
  • Skip to content
  • Skip to primary sidebar

virtuallyGhetto

  • About
  • Privacy
  • Automation
    • VMware Kickstart
    • VMware API/SDK/CLI
    • VMware vMA/VIMA
    • VMware OVF / OVFTOOL
  • Apple Mac
  • Nested Virtualization
  • VCSA
  • VSAN
You are here: Home / vSphere / Deployment models for vSphere Content Library

Deployment models for vSphere Content Library

12/01/2017 by William Lam 4 Comments

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.

More from my site

  • Maximum number of vCenter Servers per Single Sign-On (SSO) Domain
  • New vSAN Management 6.6 API / SDKs / CLIs
  • Creating your own 3rd Party Content Library for vSphere 6.0 & vCloud Director 5.x
  • Exploring new VCSA VAMI API w/PowerCLI: Part 2
  • Easily try out vSAN 6.6 Encryption feature using KMIP Docker Container
Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: vSphere, vSphere 6.0, vSphere 6.5 Tagged With: content library, vSphere 6.0, vSphere 6.5

Reader Interactions

Comments

  1. Erickson says

    12/04/2017 at 7:48 am

    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”?

    Reply
  2. Peter Scott says

    01/15/2018 at 8:07 am

    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?

    Reply
  3. Oliver says

    01/04/2019 at 12:53 am

    NFC? I assume you mean NFS…

    Reply
    • Dan says

      01/30/2019 at 8:45 am

      Nope…NFC is Network File Copy

      Reply

Thanks for the comment! Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Author

William Lam is a Staff Solutions Architect working in the VMware Cloud on AWS team within the Cloud Platform Business Unit (CPBU) at VMware. He focuses on Automation, Integration and Operation of the VMware Software Defined Datacenter (SDDC).

  • GitHub
  • Google+
  • LinkedIn
  • RSS
  • Twitter

Sponsors

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy