In this session we will look at Cloud Pod Architecture “CPA” as it relates to Horizon View. As VDI matures adoption is leading to scaled out deployments, across multiple locations with complex designs.
Initially customers wanted single site HA for virtual desktop environments. As customers grew in certain verticals like healthcare multi-site solutions were introduced such as the the “AlwaysOn Desktop” model.
Early multi-site configurations required heavy orchestration on the management, user and virtual desktop metadata synchronization. With CPA we move to a federated model where Pods are aware of other Pods in other sites. A single Pod architecture can scale to 10,000 seats; to scale higher you need CPA. Between two Pods an intercommunication protocol is responsible for syncing information between sites.
The benefit of CPA is you can manage policies globally because of Global ADLDS replication. It is important that the intra-pod network is reliable to ensure information is insync. VMware has tested 2 sites and 4 pods and 20,000 concurrent sessions within their labs.
CPA takes the original Horizon Pod architecture and moves it to a federated pod architecture. To build this you have to understand your Mission critical applications to understand how much capacity you truly need to deliver capacity in the event of a failure. With CPA there is the concept of the Global Entitlement vs. Entitlement within a Pod. The user is automatically directed to a local Pod instance, if this is not available it looks to a site instance or lastly, any desktop that exists in the federation.
To configure you enable CPA on one pod and join the remaining pods. After pods are federated you configure global entitlement. You entitle users to both local and remote pools within the federated pods. A user is always served a virtual desktop from the local pool first; if it is not available then if uses the remote site.
The latest version of Horizon essentially wraps a GUI around the lmvutil utility that was introduced in View 6.0. With CPA you know see the remote pods show up in the dashboard along with their status. CPA does not do anything for the user metadata but it will replicate the entitlement information between sites. In addition to CPA you need a Load Balanced/Geo-DNS to redirect sessions properly for the client connection.
You can deploy multiple pods in a single site in a scale-up model. In the event that one pad fails the user is directed to the second pod. Another valid architecture is for roaming users; as the entitlement always prefers local the user will always receive the desktop in the local site even when travelling between New York and London. Another use case is for Disaster Recovery. In the event that the local pod failed the user would receive a desktop from the pod in the DR datacenter.
Inter-pod communication uses VIPA “View Inter-Pod API” over port 8472 which is TLS protected. Global ADLPS happens over port 22389.
Road mapped is Global Application Entitlements which is CPA for RDS applications. It requires Agent 3.5 or higher. Currently this works over HTML/Blast. In addition VMware is working on how high they can raise the scalability.