Horizon 8 Solutions for UAG and Connection Server Failover

[any_guy]

Hello everyone,

I'm reaching out to gather insights on how you achieve failover capabilities for Unified Access Gateways (UAG) and Connection Servers in your environments. Specifically, I'm considering the following options:

1. Two UAGs Behind Two Software Load Balancers: Each UAG is connected to a Connection Server.
2. No Load Balancer: Utilizing two UAGs and DNS as a failover solution, with a short TTL and manual host entry switch when UAG A fails.

The reason I'm reaching out and not defaulting to the load balancer option is due to the size of our environment, which serves fewer than 100 users. Load balancers seem like overkill in this scenario, though I'm open to considering them if no other suitable options present themselves.

For those of you who are utilizing the load balancer option, which load balancer are you using? We do not have a license for NSX, so that is not an option for us.

Additionally, I would appreciate hearing about any other solutions you might be using or have considered.

Thank you in advance for your input!

[Robin Harmsen]

We have a bit larger environment (1800 concurrenten users)... and use a NSX load balancer.

I would go for a load balancer as this will help automatic failover/switching without manually needing to do DNS changes. If business allows some outage a DNS change is an option... In our business (Hospital), we want this as seamless and automated as possible.

We use the load balanceren also to distribute the load evenly over our UAGs and two seperate Horizon PODs.

 

 

PS.. if i remember correct the UAGs also have a High availability option.. you might want to look into that to.

Edited July 20 by Robin Harmsen

[Matthew Heldstab]

We have been using Citrix Netscaler (ADC) to load balance Horizon ever since we migrated away from XenApp over 10 years ago.  Our strategy changed a little bit when Horizon went away from Security Servers in favor of UAG Appliances.  We have a LB VIP for our UAG's, and another LB VIP that the UAG's use to connect to the Connection Servers.  That way you can connect with any combination of connection servers and UAG appliances.  Back in the day, you needed to create health checks that treated each Security Server/Connection Server as a single entity and if either failed, you needed to take that security server out of the load balancer.  

A key concept is the load balancers do not maintain the connection to the UAG appliances.  Once the Netscalers point connections to a specific UAG appliance, that connection is made around the load balancers.  Therefore, your UAG appliances need either a publicly accessible IP address or an inbound NAT, similar to the LB VIP.

If you would like more information on how to load balancer Horizon with Netscaler, check out Carl Stalhood's blog.  
VMware Horizon Load Balancing – NetScaler / Citrix ADC – Carl Stalhood

Within Carl's blog, he has a link to Aresh Sarkari's blog containing some concepts related to load balancing with F5.
Persistence Profile – F5 LTM Load Balancing for VMware Unified Access Gateway Appliance | AskAresh

Sean Massey also has a great resource that is vendor agnostic.
Omnissa Horizon Load Balancing Overview | The Virtual Horizon 

I hope this helps!

[Sean Massey-1]

Thanks for referencing my blog, @Matthew Heldstab.  It’s a great place to get started with some Horizon load balancing topics, especially for UAGs. 

So first, I’d like to understand what you’re hoping to load balance.  Are you just looking to load balance your UAGs? Both your UAGs and Connection Servers (ie - one LB in front of the UAGs and one between the UAGs and CSs), or just the CS? 

My second question is about the 2nd option you mention - using DNS with manual entry updates/changes in place of a load balancer.  Are all your Horizon resources in the same site, or are you stretching between sites?

I definitely recommend using a load balancer, even for “small” environments of 100 or fewer users.  A load balancer is not overkill, and you don’t necessarily need an NSX, F5, or Netscaler ADC license.  Some open source load balance options will work, but you may not get all of the features of the paid ones (HAProxy Open Source doesn’t do UDP traffic, NGINX Open Source does not have Active Health Checks, etc…)

[Dan Berkowitz]

I believe you had some input in this article Sean - https://techzone.omnissa.com/resource/understand-and-troubleshoot-horizon-connections#understanding-horizon-connections

 

[any_guy]

On 7/21/2024 at 7:34 PM, Sean Massey-1 said:

So first, I’d like to understand what you’re hoping to load balance.  Are you just looking to load balance your UAGs? Both your UAGs and Connection Servers (ie - one LB in front of the UAGs and one between the UAGs and CSs), or just the CS? 

My second question is about the 2nd option you mention - using DNS with manual entry updates/changes in place of a load balancer.  Are all your Horizon resources in the same site, or are you stretching between sites?

First;
I'm not necessarily looking to load balance any of it (nice to have but not a must). I'm looking to have HA for the UAGs and the Connection Servers. I have solved the UAG HA by enabling the UAG integrated HA option, which seems to be sufficient for our environment.  As for load balancing or HA enabling the Connection Servers, if possible open source. I have read up on HA Proxy and NGINX, however, It's not quite clear to me what exactly it would impact, not to have UDP traffic (HAProxy). As for NGINX, if it does not do health checks, it's not something we would consider, since HA is the leading factor here and not load balancing.

Second;
All our Horizon resources are in the same site.

The UAG's are in a DMZ with an inbound NAT.

On 7/20/2024 at 5:50 AM, Matthew Heldstab said:

We have been using Citrix Netscaler (ADC) to load balance Horizon ever since we migrated away from XenApp over 10 years ago. 

I recall Netscaler used to have a free 'express' version. However, I can't find it anymore which suggest this is not available. anymore.

[Sean Massey-1]

8 hours ago, any_guy said:

I'm not necessarily looking to load balance any of it (nice to have but not a must). I'm looking to have HA for the UAGs and the Connection Servers. I have solved the UAG HA by enabling the UAG integrated HA option, which seems to be sufficient for our environment.  As for load balancing or HA enabling the Connection Servers, if possible open source. I have read up on HA Proxy and NGINX, however, It's not quite clear to me what exactly it would impact, not to have UDP traffic (HAProxy). As for NGINX, if it does not do health checks, it's not something we would consider, since HA is the leading factor here and not load balancing.

 

Hi Any_Guy.

First, thanks for that context.  I want to clarify one thing here.  When it comes to Horizon, HA and load balancing are the same thing.  You scale Horizon and make it highly available by putting the connection servers and UAGs behind some form of load balancer.

UAG HA is a great option for the UAGs, and it can work well in a lot of environments.  But it has some caveats. UAG requires N+1 public IPs for your UAGs - 1 public IP for each UAG you have in your DMZ and one floating IP/VIP that is used for your load balanced URL, and UAG should have its own public DNS name for Blast and HTTPS tunnel traffic.  If you haven’t read the documentation, I would strongly suggest reading it. (I’m not saying to not use it - it works great…just be aware of the caveats because if you don’t set it up right, it might seem like its working and then your users start getting disconnected randomly over time).

HAProxy should be fine for your connection servers.  You don’t need UDP for connection servers.  UDP would only be required if you’re sending all of your Blast or PCOIP traffic through the load balancer.  

[any_guy]

On 8/3/2024 at 6:11 AM, Sean Massey-1 said:

Hi Any_Guy.

HAProxy should be fine for your connection servers.  You don’t need UDP for connection servers.  UDP would only be required if you’re sending all of your Blast or PCOIP traffic through the load balancer.  

Hey Sean,

After reviewing the information at this link, I am inclined to implement the below setup to keep it as simple as possible. However, I still have a few questions that need clarification:

External Connections:

• Two UAGs in the DMZ behind an HAProxy LB, with each UAG connected to a different Connection Server.

Internal Connections:

• Two internal Connection Servers behind another HAProxy LB.

I understand that it is possible to use the same Connection Servers for both internal and external connections, but I prefer to separate them.

Here are my questions:

1. The diagrams in the link show only one LB in front of the UAGs. This essentially shifts the single point of failure to the LB. Is it not recommended to use two LBs to mitigate this risk? I mean, it must be, just confusing that the diagrams do not show this.
2. We use Entra to authenticate MFA with Horizon, configured as an enterprise application. Would this setup still work if an LB is placed between the UAGs and the Connection Servers?

[Sean Massey-1]

13 hours ago, any_guy said:

The diagrams in the link show only one LB in front of the UAGs. This essentially shifts the single point of failure to the LB. Is it not recommended to use two LBs to mitigate this risk? I mean, it must be, just confusing that the diagrams do not show this.

OK.  So yes...but...typically, you'd be working with an HA pair of load balancers that sync state between them and fail over from one to the other.  So the diagram would usually only show 1 load balancer because they're effectively acting as one. I wouldn't recommend doing two separate load balancers with two separate VIPs/DNS names because that's not really HA.

I think you can do this with HAProxy, but I believe it requires KeepAlived and other Linux clustering services.  But I also haven't tried this in my lab...

13 hours ago, any_guy said:

We use Entra to authenticate MFA with Horizon, configured as an enterprise application. Would this setup still work if an LB is placed between the UAGs and the Connection Servers?

It should as you're configuring Entra MFA on the UAGs.

[any_guy]

 

On 8/3/2024 at 6:11 AM, Sean Massey-1 said:

UAG HA is a great option for the UAGs, and it can work well in a lot of environments.  But it has some caveats. UAG requires N+1 public IPs for your UAGs - 1 public IP for each UAG you have in your DMZ and one floating IP/VIP that is used for your load balanced URL, and UAG should have its own public DNS name for Blast and HTTPS tunnel traffic.  If you haven’t read the documentation, I would strongly suggest reading it. (I’m not saying to not use it - it works great…just be aware of the caveats because if you don’t set it up right, it might seem like its working and then your users start getting disconnected randomly over time).

Hi Sean,

First, thanks to everyone for your input!

Since we only have two UAGs, it wouldn't be a great deal for us to have N+1 Public IPs. For additional context, we are only utilizing Blast, PCoIP has been phased out in our environment.

Let me try to sum it up and make sure my understanding is accurate:

• For the integrated HA to work, the two UAGs require the same configuration as already in place (Blast URL, etc.), plus their own NAT, i.e., one public IP per UAG, PLUS the VIP requires an additional public IP. So, that would be three public IPs in total for two UAG's
• The VIP is only used for the initial authentication and session management (XML API over HTTPS).
• The VIP moves to another UAG if the currently assigned UAG fails. Therefore, the authentication process remains up.
• If tunneling is not enabled, the sessions initially set up through the failed UAG should remain connected.

Is the above accurate? I would like to utilize the built-in HA functionality if, when set up correctly, it is reliable.

EDIT****

I geuss what I'm confused about is: https://techzone.omnissa.com/resource/load-balancing-unified-access-gateway-horizon#session-affinity-options-for-secondary-protocols

Method 1 and 2 only require a single Public IP for all UAGs and the VIP?

***EDIT

 

I'm a little concerned about your comment: "it might seem like it's working and then your users start getting disconnected randomly over time." Could you provide an example of what you have experienced in this regard?

As for the internal connection servers, I'm probably going with HAProxy.

Thanks again,

 

 

Edited August 6 by any_guy

[Sean Massey-1]

On 8/6/2024 at 11:10 AM, any_guy said:

For the integrated HA to work, the two UAGs require the same configuration as already in place (Blast URL, etc.), plus their own NAT, i.e., one public IP per UAG, PLUS the VIP requires an additional public IP. So, that would be three public IPs in total for two UAG's

Partially correct.  You would need 3 public IPs in total, but each UAG would need to have it's own unique Blast/Tunnel URL.

It would look something like this:

Floating/Shared VIP for UAG HA: 100.64.1.0/horizon.any_guy.com

UAG1 NAT Public IP: 100.64.1.1/horizon_uag1.any_guy.com

UAG2 NAT Public IP: 100.64.1.2/horizon_uag2.any_guy.com

On 8/6/2024 at 11:10 AM, any_guy said:

The VIP is only used for the initial authentication and session management (XML API over HTTPS).

Basically, yes.  Once you authenticate, you're communicating directly with the UAG that you authenticated against.  All session protocol/secondary traffic happens with that UAG, which is why each UAG needs to have its own DNS name/NAT public IP.

On 8/6/2024 at 11:10 AM, any_guy said:

The VIP moves to another UAG if the currently assigned UAG fails. Therefore, the authentication process remains up.

Partially.  In my experience, the UAG VIP will actually float between the two UAGs if both are up.  The authentication process will always remain available, and if one UAG goes down, the VIP will remain available on the UAGs that are online.

On 8/6/2024 at 11:10 AM, any_guy said:

If tunneling is not enabled, the sessions initially set up through the failed UAG should remain connected.

I'm not sure what you mean by this.  If a UAG goes down/fails, then user sessions that are connected to that UAG will be disconnected and the user will need to reconnect.  The UAG is basically a reverse proxy for Horizon, and session protocol/secondary protocol traffic is pinned to the UAG that the user authenticated against. 

On 8/6/2024 at 11:10 AM, any_guy said:

EDIT****

I geuss what I'm confused about is: https://techzone.omnissa.com/resource/load-balancing-unified-access-gateway-horizon#session-affinity-options-for-secondary-protocols

Method 1 and 2 only require a single Public IP for all UAGs and the VIP?

***EDIT

This is only relevant if you're using a 3rd-party external load balancer like Netscaler, F5, AVI, or similar services.  UAG HA is outside of the scope of that document as stated in one of the opening paragraphs:

Quote

This document focuses on the Horizon use case for Unified Access Gateway with an external load balancer. Unified Access Gateway also has a built-in high availability feature, although it is outside the scope of this document. Refer to the VMware Unified Access Gateway: High Availability - Feature Walk-through for details of that feature.

 

On 8/6/2024 at 11:10 AM, any_guy said:

I'm a little concerned about your comment: "it might seem like it's working and then your users start getting disconnected randomly over time." Could you provide an example of what you have experienced in this regard?

Yeah.  This happened because I did not configure my UAG HA prerequisites properly, and I didn't realize it at the time.

I used a single URL (horizon.lab.example) and VIP for both UAG1 and UAG2.  So what would happen is that a user would connect, and the VIP would be on UAG1.  So they would authenticate with UAG1 and their Blast session would go through UAG1.  But at some point during that user session, the VIP would float to UAG2.  And as soon as that happen, the user sessions would freeze and eventually disconnect.  Now this was in a lab environment, so it didn't cause any production impacts or outages, but it was still frustrating for myself and some other lab users.

That's why I say that you need to make sure you meet the prerequisites of N+1 public IP addresses and unique DNS names for each UAG because it won't work as intended without them.

[any_guy]

On 8/7/2024 at 9:58 AM, Sean Massey-1 said:

Partially correct.  You would need 3 public IPs in total, but each UAG would need to have it's own unique Blast/Tunnel URL.

It would look something like this:

Floating/Shared VIP for UAG HA: 100.64.1.0/horizon.any_guy.com

UAG1 NAT Public IP: 100.64.1.1/horizon_uag1.any_guy.com

UAG2 NAT Public IP: 100.64.1.2/horizon_uag2.any_guy.com

Basically, yes.  Once you authenticate, you're communicating directly with the UAG that you authenticated against.  All session protocol/secondary traffic happens with that UAG, which is why each UAG needs to have its own DNS name/NAT public IP.

Partially.  In my experience, the UAG VIP will actually float between the two UAGs if both are up.  The authentication process will always remain available, and if one UAG goes down, the VIP will remain available on the UAGs that are online.

I'm not sure what you mean by this.  If a UAG goes down/fails, then user sessions that are connected to that UAG will be disconnected and the user will need to reconnect.  The UAG is basically a reverse proxy for Horizon, and session protocol/secondary protocol traffic is pinned to the UAG that the user authenticated against. 

This is only relevant if you're using a 3rd-party external load balancer like Netscaler, F5, AVI, or similar services.  UAG HA is outside of the scope of that document as stated in one of the opening paragraphs:

 

Yeah.  This happened because I did not configure my UAG HA prerequisites properly, and I didn't realize it at the time.

I used a single URL (horizon.lab.example) and VIP for both UAG1 and UAG2.  So what would happen is that a user would connect, and the VIP would be on UAG1.  So they would authenticate with UAG1 and their Blast session would go through UAG1.  But at some point during that user session, the VIP would float to UAG2.  And as soon as that happen, the user sessions would freeze and eventually disconnect.  Now this was in a lab environment, so it didn't cause any production impacts or outages, but it was still frustrating for myself and some other lab users.

That's why I say that you need to make sure you meet the prerequisites of N+1 public IP addresses and unique DNS names for each UAG because it won't work as intended without them.

Thanks Sean!

You clarified all my remaining blanks.

Have an awesome weekend you all!