The Cloud Pod Architecture (hereinafter named CPA) is a feature that is available with the Horizon 7 Enterprise Edition. When CPA is configured, it creates a pod federation and additional Horizon pods become members of this. CPA is used in different scenarios as listed below:
Scalability - a single Horizon pod can support a maximum of up to 20,000 sessions; however, VMware recommends keeping this number at 10,000 sessions per pod. When you need to exceed this number of sessions in your organisation, additional Horizon pods can be deployed for scalability and grouped logically. These additional pods could be on the same site as the first pod or in different data centres in different locations.
Flexibility - by configuring CPA, you control where a user is granted their Horizon resource from. You can load balance users across sites to make the most of your underlying infrastructure or consider CPA for providing Horizon resources in the event of BC/DR:
Active/Passive Architecture - you can enforce a user to a home site, meaning regardless of where the user is connecting from, the Horizon resource is always provided by the same (active) Horizon pod. In the event the Horizon 7 resource is not available, the user will get their Horizon resource from the secondary (passive) Horizon pod seamlessly.
Active/Active Architecture - the only difference between this architecture and the active/passive architecture is that the user has no home site assigned. What this means is that any Horizon pod that is a member of the federation can service the user request for Horizon resources if they are a member of the global entitlement for the federation.
Several infrastructure requirements need consideration before configuring CPA.
Global Server Load Balancing (GSLB) is required to provide a single Horizon namespace for all users to connect to their virtual desktop environment. The role of the GSLB is to direct the user to the correct Horizon environment based on the configuration of the global entitlement that the user is assigned.
User data replication between sites is paramount. Users require their data to be available regardless of the site they are connecting to for their virtual desktops
Networking to allow the VIPA and Global Data Layer synchronisation between all Horizon Connection Servers across all Horizon pods is required
Figure 1 below illustrates at a high-level how CPA looks for internal-only use-case between two data centres; it does not show components required for external use-case connectivity such as Unified Access Gateway.
Figure 1: High-Level Architecture of CPA
Read the guide here or watch the video below for detailed walkthrough on configuring the Cloud Pod Architecture feature of Horizon 7.
Hi Surj,
Is there a license need to have active and passive sites licensed separately or both sites can use the same license in case of active passive ?
"In the event the Horizon 7 resource is not available, the user will get their Horizon resource from the secondary (passive) Horizon pod seamlessly." Not without activating the standby site components and override the home site.
Hi Surj,
Great Video on POD, I do have a question on POS.
Do i have to have same number of connection servers and pools in both pod do configure them, what i meant does both pods have to be identically same?