Before you begin to configure the
Cloud Pod Architecture feature, you must make decisions about your Cloud Pod Architecture topology. Cloud Pod Architecture topologies can vary, depending on your goals, the needs of your users, and your existing Horizon implementation. If you are joining existing Horizon pods to a pod federation, your Cloud Pod Architecture topology is typically based on your existing network topology.
Creating Cloud Pod Architecture Sites In a Cloud Pod Architecture environment, a site is a collection of well-connected pods in the same physical location, typically in a single datacenter. The Cloud Pod Architecture feature treats pods in the same site equally.
Entitling Users and Groups in the Pod Federation In a traditional Horizon environment, you use Horizon Administrator to create local entitlements. These local entitlements entitle users and groups to a specific desktop or application pool on a Connection Server instance.
Finding and Allocating Desktops and Applications in the Pod Federation Connection Server instances in a Cloud Pod Architecture environment use shared global entitlement and topology configuration information from the Global Data Layer to determine where to search for and how to allocate desktops and applications across the pod federation.
Considerations for Unauthenticated Users A Horizon administrator can create users for unauthenticated access to published applications on a Connection Server instance. In a Cloud Pod Architecture environment, you can entitle these unauthenticated users to applications across the pod federation by adding them to global application entitlements.
Global Entitlement Example In this example, NYUser1 is a member of the global desktop entitlement called My Global Pool. My Global Pool provides an entitlement to three floating desktop pools, called pool1, pool2, and pool3. pool1 and pool2 are in a pod called NY Pod in the New York datacenter and pool3 and pool4 are in a pod called LDN Pod in the London datacenter.
Implementing Connection Server Restrictions for Global Entitlements You can restrict access to global entitlements based on the Connection Server instance that users initially connect to when they select global entitlements.
Implementing Client Restrictions for Global Entitlements You can restrict access to global entitlements to specific client computers. To restrict access, you add the names of the client computers that are allowed to access a global entitlement in an Active Directory security group and then add this group to the global entitlement's users and groups.
Enabling Session Collaboration for Global Entitlements With the Session Collaboration feature, end users can invite other users to join an existing remote desktop session.
Considerations for Workspace ONE Mode If a Horizon administrator enables Workspace ONE mode for a Connection Server instance, Horizon Client users can be redirected to a Workspace ONE server to launch their entitlements.
Considerations for Mixed-Version Environments Mixed-version Cloud Pod Architecture environments are supported beginning with Horizon 7 version 7.4. For example, a pod federation can include pods that are running Horizon 7 version 7.4 and pods that are running Horizon 6 version 6.x.
Cloud Pod Architecture Topology Limits A typical Cloud Pod Architecture topology consists of two or more pods, which are linked together in a pod federation.
Cloud Pod Architecture Port Requirements Certain network ports must be opened on the Windows firewall for the Cloud Pod Architecture feature to work. When you install Connection Server, the installation program can optionally configure the required firewall rules for you. These rules open the ports that are used by default. If you change the default ports after installation, or if your network has other firewalls, you must manually configure the Windows firewall.
Security Considerations for Cloud Pod Architecture Topologies To use Horizon Administrator or the lmvutil command to configure and manage a Cloud Pod Architecture environment, you must have the Administrators role. Users who have the Administrators role on the root access group are super users.