Use the Cloud Pod Architecture feature to link together multiple pods to provide a single large desktop and application brokering and management environment.
A pod consists of a set of Connection Server instances, shared storage, a database server, and the vSphere and network infrastructures required to host desktop and application pools. In a traditional Horizon 8 implementation, you manage each pod independently. With the Cloud Pod Architecture feature, you can join together multiple pods to form a single Horizon 8 implementation called a pod federation.
A pod federation can span multiple sites and data centers and simultaneously simplify the administration effort required to manage a large-scale Horizon 8 deployment.
The following diagram is an example of a basic Cloud Pod Architecture topology.
In the example topology, two previously standalone pods in different data centers are joined together to form a single pod federation. An end user in this environment can connect to the New York pod and receive a desktop or application in either pod.
When using Cloud Pod Architecture with Unified Access Gateway appliances, each appliance must be associated with a single pod.
Key Components of Cloud Pod Architecture
Cloud Pod Architecture is built from a small number of components that work together to make many independent pods behave like one system.
| Component | What it is | What it is responsible for |
|---|---|---|
| Pod | A set of Connection Server instances, shared storage, a database server, and the vSphere/network infrastructure needed to host desktop and application pools. | Hosting and brokering desktops and applications for the users connected to it. |
| Pod federation | Two or more pods joined together using the Cloud Pod Architecture feature. | Presenting the joined pods as a single logical brokering environment. |
| Global Data Layer | A second, replicated LDAP instance that runs on every Connection Server instance in the pod federation. | Storing and replicating topology, global entitlements, home sites, federation access groups, and policies pod-federation-wide. |
| VIPA (View InterPod API) | An HTTPS-based interpod communication channel. | Real-time pod-to-pod communication: launching sessions on a remote pod, finding existing sessions, and exchanging health status. |
| Site | A collection of well-connected pods, typically in one data center, treated as equals by Cloud Pod Architecture. | Modeling network locality so brokering can prefer nearby resources over resources reached across a slower WAN link. |
| Global entitlement | A named object linking users or groups to desktop or application pools anywhere in the federation, plus the policies controlling how resources are found and allocated. | What a user actually sees and selects in Horizon Client. |
| Home site | An optional relationship between a user or group (or a user/group and a specific global entitlement) and a site. | Anchoring where the search for a resource starts, regardless of which pod the user connects through. |
How Cloud Pod Architecture Differs from a Traditional Horizon 8 Deployment
In a traditional, non-federated Horizon 8 deployment, each pod is a self-contained island: it has its own Connection Server instances, its own local entitlements, and no awareness of any other pod. A user connecting to pod A can only be brokered a desktop or application that physically exists in pod A.
Cloud Pod Architecture changes this in three ways:
- Entitlements become global instead of local. You entitle a user or group to a global entitlement that can be backed by pools in any pod in the federation, rather than to a pool on one specific Connection Server instance.
- Brokering becomes federation-aware instead of pod-local. The Connection Server instance a user connects to (the connecting pod, also called the brokering pod) can use VIPA to ask other pods whether they have a matching resource, in an order controlled by the global entitlement's scope policy and the user's home site.
- Configuration and state become shared instead of siloed. Topology, entitlements, and home sites live in the Global Data Layer and are visible from every pod. Session and health information is likewise visible pod-federation-wide in Horizon Console. (Exception: Horizon 8 event databases are not shared across pods.)
What does not change: every desktop or application pool still physically exists in exactly one pod, and each pod remains fully capable of operating on its own. Cloud Pod Architecture is a brokering and management layer on top of your existing pods, not a replacement for them.
Was this page helpful?