I wanted to write the last blog post for this year on some hidden gems that possibly some people do not know exist in VMware horizon 7 and 8.
In this blog we will discuss a feature called cloud pod architecture that perhaps you already have read about in my VCAP DTM study guide. But for those that don’t have any idea what cloud pod architecture or better known as CPA is, let’s start with the basics.
When deploying a Horizon environment, you start with your initial connection server. During the installation of the connection server,
a local ADAM database based on the Lightweight Directory Service (Microsoft LDS), is created where al horizon related data is stored.

If you are interested in having a look at how the ADAM database is build up, you can connect using ADSI-edit to it.
Following connection string should be used: localhost:389 DC=vdi,dc=vmware,dc=int but there is a KB article on the exact procedure.

All data regarding connection servers within the deployment, the configuration of desktop pools, VDI desktops and entitlements are all store in this database. So when installing your second connection server, your need to select the “replica” option as it needs to join into the existing ADAM database. During the installation of the second connection server an ADAM database is created but all data is replicated from the initial connection server. After the installation, all servers will be in constant sync with each other synchronizing all changes like desktop created, destroyed user logon/logoff.

Single Pod Architecture with single or multiple vCenters

With the basics explained how a traditional deployment of cloud pod works. Let’s get into the whole CPA design and what the benefits are.
With a traditional deployment, all connection servers are located in one single pod. This means all connection servers are in the same vicinity of each other, meaning the same LAN.
More on the network requirements of the connection server component can be found here.

This is illustrated in the diagram on the left where you can see a single deployment with multiple connection servers.
Most of the time this is also the deployment I tend to see at customers with existing horizon deployment.

A single management block (all backend services) hosted on a high-available infrastructure cluster, used with one or two horizon clusters that are in the same vCenter as the infrastructure cluster or separated vCenter servers.

You may ask yourself the question: Why do I need separate vCenter servers for my Horizon clusters?
The answer is very straight forward: dependencies and the corresponding Single Points of Failure (SPOF).

Let me explain, with the usage of Instant Clones, all connection servers will interact directly with that vCenter server. This for the creation of new clones, changes to images, or details about the current state of the VM’s. When a vCenter outage occurs, all provisioning stops. No more desktops can be created to provide a desktop for your end-users. This is why every customer purchasing horizon is entitled to vSphere for Desktop and vCenter for Desktop licenses.

These are permanent licenses that entitle your vSphere hosts when used solely for horizon workloads. The same goes for the vCenter for desktop licenses, customers have the right to deploy additional vCenters for their Horizon clusters. However vCenter does have some drawbacks, I will list all pros and cons:

PROS:

– No SPOF when using Instant clones
– High availability on Horizon resources blocks (vSphere components + desktop pools)
– Maintenance and lifecycle management can be performed in a rolling upgrade fashion
– Granular testing and validation can be performed due to rolling upgrades for vSphere components.

CONS:

– Multiple vCenter instances need to be maintained
– Image synchronization is more difficult but can be solved with a Content library or shared NFS
– Additional resources required in the infrastructure cluster
– Still, big bang upgrade on backend connection servers

With the clear advantages of using multiple vCenters for flexibility and high-availability. We still remain with the same limitations on our backend connection servers.
A single ADAM database synchronized between multiple members, so no high-availability in case of DB corruption and always a big bang upgrade.

Cloud Pod Architecture

This is where CPA solves the problem. Initially designed for multi geo-location horizon deployments, CPA provides a scalable and truly high-available horizon setup.
Building upon the traditional pod structure, two isolated backends will be interconnected with a global ADAM database.

This means that both connection server pods will still have an individual ADAM database containing all data mentioned above, but during the initialization of the CPA federation, a second ADAM database is created. The global adam database.

In this database, all global entitlements and the link between local pools and the entitlements are stored. This is then synced using the VIPA protocol between all pods.
So as seen in the diagram, the traditional deployment is just duplicated to the other side. This can be for example be a data center in New York and the other in Los Angeles. Both pods will be communicating with each other by replicating the global ADAM database between all members.

Why do I need separate pods when I only have one physical site?
This is indeed a good question on why do I even need this? When I just have a data center or room located in (building A & building B or basement and floor 2,…)

It all again comes back to RCAR, If you do not know what this is please check out my VMUG video on this topic.
In short, how business critical is the deployment? What is the required availability of the solution?

In the case of some of my customers, that answer will be without doubt mission-critical to the business.

To provide a similar overview as the single/multiple vCenters, here is a pros/cons list for the implementation of CPA:

PROS:
– No SPOF on connection server pod level
– High availability on Horizon management blocks
– Maintenance and lifecycle management can be performed in a rolling upgrade fashion
– Granular testing and validation can be performed due to rolling upgrade. No big bang upgrades

CONS:

– Upgrades tend to be longer due to more horizon components need to be upgraded
– Desktop pool configuration needs to be performed on both sides in case of Active-Active setup
– Double the number of resources required in the infrastructure clusters

Conclusion

Based on my personal experience, the implementation of CPA can greatly improve the availability of your horizon solution as well as provide more flexible lifecycle management to allow for more granular testing.
The biggest pro in my opinion is the option to fully upgrade an entire site (desktop / vSphere / vCenters and backend services) in 1 go and fully test before allowing any end-users on the site.

I hope this blog was helpful and will clearly identify why CPA is a hidden gem that is sometimes misunderstood.