5.2 Cloud Pod Architecture
A Pod represents a single instance of Horizon, which is made up of one or more resource blocks (vCenter Server) and a collection of Connection Servers. As previously described in Section
5.1 Deployment Models, it is not recommended or supported to span a single Pod across a wide area network (WAN) due to the latency impact on the JMS message bus. Cloud Pod Architecture addresses this by federating multiple “Pods” (up to 25) in a single Cloud Pod. See the following figure.
Figure 10. Cloud Pod Architecture
For cloud tenants, a Cloud Pod Architecture (CPA) implementation may be useful when extending an existing on-premises deployment of Horizon to the service provider. To provide CPA functionality, the first Pod must be initialized and then additional Pods can be joined to create a Pod federation.
It is also possible to initialize CPA for a single Pod. This enables a useful feature called Global Entitlements, which allows for a single entitlement to be assigned multiple desktop or application pools. In order to understand this, it is important to understand how local and global entitlements are presented to the end user.
Table 1. Cloud Pod Architecture Maximums
Description | Value |
Maximum number of sites | 5 |
Maximum number of tenant Pods in a federated Cloud Pod | 25 |
Concurrent connections per Pod | 10,000 |
Concurrent connections per Cloud Pod | 50,000 |
Figure 11. Horizon Client Pool Entitlements
A local entitlement allows the Tenant Administrator to entitle access to a desktop or application pool to an Active Directory user or group object. When the user launches the Horizon Client or HTML Access, they will see the desktop or application pool entitlement. If multiple desktop pools are added, these will each show separately to the end user. For example, if a user is entitled to desktop pools A and B, they will see both (see
Figure 11).
A global entitlement appears the same as a local entitlement to the end user, however, multiple desktop pools from the same Pod or multiple Pods can be added.
When a user connects to a global entitlement, if the first pool has no spare desktops available it will try the next pool within the local Pod. If there are still no desktops available, it will continue to the next Pod (same site) then eventually Pods in other sites providing they are part of the same global entitlement in the Pod federation.
Table 2. Cloud Pod Architecture Terminology
Term | Description |
Site | Typically, a data center site. A site will contain a logical grouping of well-connected resources, exhibiting low-latency, high bandwidth, reliable network connections. |
Global Entitlement | A global entitlement of desktop or applications pools across the federated Pod. |
Scope (Within Pod, Site or Any) | A scope is defined as part of the global entitlement and can be set to Within Pod, Within Site or All Sites. When a global site load-balancer places the user connection, the scope then determines how to handle traffic across sites.
Within Pod places the desktop in the local (current) Pod only.
Site, will place the desktop connection to any available Pod in the same site.
Any, will place the desktop connection anywhere in the federated Cloud Pod. |
Home Site | A home site is associated with a user or group and is selected for a Global Entitlement. For example, a user or group’s home site can be set to London for a Global Entitlement. If a home site is associated with a user, this will override any group home site assignments. |
