VMware Cloud Pod Architecture – what it is and how it helps

When dealing with multiple datacenters, spread over multiple sites or continents even, you are faced with a couple of challenges. For one, you do not want to manage your desktops and/or applications on a per site or datacenter basis. Neither do you want your users in, let’s say New York to connect up to a desktop somewhere in Europe, in most cases anyway. And if you do, you would like to have full control when it comes to assigning desktops and/or applications — or entitlements as VMware likes to call them. Flexibility is key. This is where VMware’s Cloud Pod Architecture can help.

Traditional VMware Horizon/View deployments can consist out of one or more Pods, with each Pod containing up to five VMware View blocks. Each individual Pod can host up to 10.000 desktops, meaning 2000 per block. While for a lot of companies 10.000 desktops might be enough, the problem with this approach (if you would like to configure multiple) is that each Pod needs to be managed as a separate entity including its own user entitlements (desktops and application assignments). There is no way to aggregate the resources from multiple Pods or to manage them as a whole.

How a Cloud Pod architecture helps

In simple terms a Cloud Pod Architecture lets you publish a single icon that load balances connections across multiple pools in multiple pods in multiple sites, or datacenters (these two terms are interchangeable). Sort of what Citrx is doing with StoreFront multi-site configurations and aggregated icons, or zone-preference policies, for example.

VMware’s Cloud Pod Architecture lets you deploy multiple Pods across multiple sites or datacenters while centralizing management through a single entitlement layer. Users can be assigned to a desktop and/or application in the nearest site/Pod (non-persistent desktops), they can be bound to a so-called Home site/Pod so that they will always be connected to that specific site no mater where they are physically located (persistent desktops), or simply assign users to a desktop and/or application within multiple sites/Pod’s for HA/disaster recovery purposes.  Finally, you can aggregate multiple non persistent desktop pools spread out over multiple sites, with each site consisting out of multiple Pods by configuring a global entitlement layer, which will join all the pools together.

VMW fact: Keep in mind that you will still need to take care of the user data involved. If a user connects up to a desktop in New York while his or her associated user data (user profile, home dir. company data etc.) is located back in Europe, chances are things won’t be as ‘snappy’ as when the data would reside in the same site/datacenter. A replication mechanism of some sort might be worth considering. The same applies to the WAN/MAN links used in between, these are assumed to be low latency.

When configuring a global entitlement you first give it a name, assign members, either individually or by adding in groups of users, and of course the desktops/applications that the users are allowed to launch. I already mentioned the option to set a so-called Home site, for this to work a specific policy needs to be configured, it basically states: FromHome (true/false). This influences where the desktop search will be started as soon as a user connects. For example:

• When the FromHome policy is set to false the View Connection server will start its search in the current Pod the user is connected to. If it is set to true it will redirect the user to his or her home site and any Pods that will reside in it.
• By default the search will start with local resources first, meaning the Pod the user is currently connected to, as stated above. Next it will look in the same site/datacenter before it will continue to search over all sites as part of the global Cloud Pod Architecture.
• Current limits include: a maximum of 25 Pods, 5 sites/datacenters, 172 View Connection Servers and 75000 users in total.
• When dedicated assignment pools are used, a global entitlement will assign the user to a desktop, which as of than will be the default desktop for that specific user.

VMW fact: With the release of VMware Horizon® 7 and VMware Identity Manager™ 2.6, it is now possible to configure VMware Identity Manager to work with Horizon Cloud Pod Architecture when deploying your desktop and application pools over multiple data centers or locations. Sourced from: https://vdelboysview.com

The Pod  architecture

As highlighted earlier VMWare ‘s Cloud Pod Architecture joins together View Pods spread over multiple sites/datacenters enabling central management and brokering of all configured desktops and/or applications involved. This is called a Pod Federation.

Communication between sites/datacenters and the accompanying View Connection servers takes place through something called a Global Data Layer (see the image above). It is used by the View Connection servers to exchange key data like: the site topology, configured policies and desktop and application entitlements. Next to this, View Connection servers make use of the View InterPod API, or VIPA in short. This API is used by the View Connection servers to find/launch desktops and applications and to exchange health status information between sites/datacenters.

Have a look here on the actual configuration steps needed – written by Rob Bekmans.

Thanks for reading, hope it helped.

Bas van Kaam

Field CTO EMEA by day, author by night @ Nerdio

Father of three, EMEA Field CTO @ Nerdio, Author of the book Van de Basis tot aan Meester in de Cloud, Co-author of the book Project Byte-Sized and Yuthor of the book: Inside Citrix – The FlexCast Management Architecture, over 500 blog posts and multiple (ultimate) cheat sheets/e-books. Public speaker, sport enthusiast­­­­­­­­: above-average runner, 3 x burpee-mile finisher and a former semiprofessional snooker player. IT community participant and initiator of the AVD User group Community world wide.