Let’s be stubborn: Load balancing External access to your on-premises Horizon Environment.
top of page
Zoeken
  • Foto van schrijverEdwin de Bruin

Let’s be stubborn: Load balancing External access to your on-premises Horizon Environment.

Regularly I get questions about the flow when a user is getting external access and the relationship between the Unified Access Gateways, load balancers and the Connection servers.


Especially because we sometimes need to deviate from the VMware Reference Architecture. This deviation could generate an error on the connection server. Most engineers cannot stand an error... they just want to eliminate it! (And of course, I praise them for it!)

But like many things in life, sometimes just accept it. I’ll explain later why this happens and one possible way to eliminate it.


I decided to write a little blog about the flow and the error so this might help others (and now of course I can point people to this blog when the questions popup again)


For the sake of the length of this blog I let the authentication and authorization part out.


Can you quickly explain how the design would look like if we would follow the Reference Architecture?


When following the VMware Reference Architecture and for example have a customer with 2 times a VMware Horizon POD (Point of Delivery, see this as a datacenter) with 1 View Block in each POD in a quick overview you would need:


GLSB (Global Server Load Balancing) – To send the user to a specific POD based on location or availability of the POD.


DMZ:


Per POD: A load balanced VIP in each POD, to load balance the Unified Access Gateways. Each POD has to be able to stand on its own so this VIP lives on a high available load balancer. So 4 load balancers in total.


Per POD: 2 Unified Access Gateways. 4 in total.


Internal:


Per POD a load balanced VIP in each POD, to load balance the Connection Servers. Once again 4 load balancers needed.

When rumble this in a quick drawing this will end up in this design:


So, when a user for example like Blade is logging in, he will get directed to a specific datacenter and end up on a virtual desktop or app (Wait Blade is ending up on a virtual desktop running on a blade server? huhu.. such a bad … bad joke… please just continue)

But what if he disconnects because he needs to kill a vampire or something on the other side of the world and he reconnects to his session from that part of the world? Could he end up in the other POD with a new session and losing all his data.. don't like to get him mad at me!


no worries. Cause we use Global pools the other side is aware of the session and will redirect to the existing session. But let’s not get carried away


(and yes Blade is that fast to do all of that within the logoff timer policy).


What the deviation you talked about?


Although this design is extremely high available it’s also quite expensive in resources. You would need 4 Unified Access Gateways. 8 load balancers which could get expensive depending on the licensing. In example when using Citrix NetScaler for the load balancing you need to license each load balancing node separately.


Additional load balancers to upgrade... UAGS to maintain... I get this design when the datacenters are across continent or something like that but not with the customer base I usually work with.


The datacenters usually are in the same building or just few milliseconds away. Some days only 200 to 300 external users are working remotely and, in most cases most external users are supportive to the process (although changing rapidly and maybe a bold statement from me personally).


Feels a bit over the top. So, let’s be stubborn.


Can we use 1 VIP in the DMZ, just 2 UAG’s and one internal VIP and thereby eliminating 4 load balancers and 2 UAG’s? Yes, you can!


The upside:

Eliminated 4 load balancers with its licensing and maintenance and of course 2 UAGS and freed up some resources by eliminating these components. Everything is high available, of course validated this with multiple scenario’s, good to go!


The downside:

There is always an error showing (Gateway Servers: Unreachable) in one or both the POD’s when logging in to the connection servers.


Everything works as expected tough. It's just annoying error...



Why? As described in the article the UAG sends a HTTPS get request with the X-EUC-Health Header to this Connection Servers. Since this report will only be send to one of the POD’s due to the load balancing setup you possibly will see mixed error states. To visualize (more combinations possible but this gives the idea):


Or:

Is there a way to fix this?


Well, can think of multiple ways but I suppose a little adjustment with the cost of an additional VIP and 2 extra Unified Access Gateways would do the job:


It's up to you if the error is so annoying its's worth the additional VIP and UAG's!


I hope this blog was informative and could help you in any way.


Don't hesitate to contact me if you have any questions or remarks!











248 weergaven0 opmerkingen
Post: Blog2_Post
bottom of page