VMware Horizon Cloud Pod Architecture Questions From the Field
While implementing a Horizon Cloud Pod Architecture, customers asked overall the same questions, how its work, what happens if…, In this blog i will cover some of the questions asked by customers in the field.
The first questions and most common, why do we need a Cloud Pod Architecture, we can also spread the connection brokers over two datacenters?
Spreading connection servers over two datacenters is not officially supported by VMware, In the field i see that it will work without any problems. Still you have one composer and one vCenter server.
With Horizon Cloud Pod Architecture, you can spread the risk because you use a different vCenter server, connection server and Composer.
Is it difficult to enable Cloud Pod Architecture?
In earlier releases of Horizon it was, Recently I deployed a Pod Architecture with Horizon 7.5 and i can say that is was quite easy. Understanding why you couldn’t add a local pool was harder than setup the Cloud Pod 😉
by default, cloud pod is disabled
What happens if one site with two connection brokers are down, can users still connect to their desktop?
When a site with two connection brokers are down, Users cannot connect to their desktops, because a connection server is needed for assigning users to a desktop.
Because there are two sites, Horizon will check if a desktop is available at his own site.
For redundant purposes, I will always recommended Two or more connection brokers at each site. Use DRS rule to spread the connection brokers VM on different ESXi Servers.
Floating and dedicated user assignment both supported?
Within Cloud Pod, both are supported. Note when you add a global entitlement, you must choose floating or dedicated user assignment.
after creating the entitlement can can only add pools with the same user assignment. you cannot change this afterwards.
User connect to a site without local pools, what happens?
When u user connect to a site without any local pools added, Because the user is assigned to a global entitlement, Horizon will check for available desktops at the other site. When there is a desktop available the request will be forwarded.
* Con10 is the connection broker and entry point of the user.
* Con01 is the connection broker of the other site.
Because Con10 has no local pools added to the global entitlement, the request is forwarded to Con01.
What are the limitations?
Horizon 7.5Â has the following limitations
- IPv6 is not supported
- Kiosk mode clients are not supported, in the official VMware documentation VMware provide a link to a workaround KB2148888
- Limit of 200.000 sessions
- Maximum of 25 Pods
- Maximum of 10.000 sessions per pod
- Maximum of 10 sites
- Maximum of 175 connection servers
Which Network ports are used
| Ports | Protocol | Descr |
| 22389 | HTTP | This port will be used for LDAP replication |
| 22636 | HTTPS | This port will be used for secure LDAP replication |
| 8472 | HTTPS | This port will be used for View interpod API communications ( VIPA ), this communication channel is used to launch new desktops and applications. Also the VIPA shared health status data. |
The VIPA communication channel will be configured when the admin initialize the Cloud Pod Architecture feature.
Different Version of Horizon supported in a pod?
Since the release of Horizon 7.4 it is supported to use different version of horizon within the same pod. Note that new features of Horizon 7.4 or 7.5 are not visible ( do not work ) in the horizon administrator of Horizon 6.x
Can i Remove a Pod from the Pod Federation?
Yes you can, In the Horizon Console, you must select in the inventory “Cloud Pod Architecture” after that, click on “Unjoin” to leave the pod federation.
Can i just Uninitialize the Cloud Pod Architecture feature when there are pods connected.
Before uninitialize the pod architecture, you must first unjoin the connected pods. The option will be greyed-out in the horizon administrator console.
Can i use adsi edit to view global LDAP information
For accessing global ldap information with Adsi, you must use the following adress for the connection point
- dc=vdiglobal,dc=vmware,dc=int
- localhost:22389
Cloud Pod use his own Ldap instance to store shared data.
What happens if the user is entitlement to the local pool and global entitlement
Because the user is assigned to the local and global pool, when logged in, there will be two desktop icons. Because this is confusing, my advise use only the global entitlements instead of local.
#Destination of above tiles are the same, when the user choose for “Desktop”, the cloud pod function is not working
So in cloud pod does each vcenter need to have its own PSC? I am assuming it does as if one site goes down it would still need to authenticate?
Hello, With horizon cloud pod you need at least one vcenter server each pod. there is no limitation to connect both vCenter servers to a cluster of PSC. make sure that each PSC will run separately in multiple datacenters. The use of a load balancer in front of the psc is required.
In order to run the environment independent, you can choose to use a vCenter server with a direct connection to a PSC without enhanced linked mode
When a PSC is down, The vcenter server is not able to do anything. created, modify, delete or other tasks will not be performed.
Good Luck, and thanks for the comment!
Greetz,
Kevin
What might be the reasons for having 2 PODs in 1 site – other than for scale? Ease of maintenance, upgrades, etc? I had a Vmware engineer suggest this, and I’m struggling to understand why – assuming all components within a single POD are redundant.
Hello Jeff.
Indeed, all the components within a single pod can be deployed as redundant (exclude composer server). The reason for using two pods within one site is that stretching the connection brokers on two datacenters is not supported by VMware. It should work, and i have seen it before by a customer but it is not allowed.
So if you got two or more datacenters you must use Horizon cloud pod architecture to combine the two environments to make it accessible from a single user interface.
Another reason for using Horizon cloud, When there is a failure within the pod (java process crashed) new desktops will not be deployed. I have seen this before and the only thing what you can do is rebooting the connection brokers within that pod. In that case you are a happy IT-admin because with Horizon Cloud pod, if there are no desktops available the request will be forwarded to the other pod.
Please let me know if you got more questions. i’m pleased to help you.
Greetz,
Kevin