What is the VMware UAG N+1 Deployment?

This week I learned about a new deployment method for the VMware Unified Access Gateway (UAG). When I say new, I mean new to me. 🙂 I thought it was an interesting method with specific use cases and then started to think about what other types of benefits it could have in an environment that used it.

What is N+1

The N+1 method refers to having an N number of externally accessible UAG IPs + 1 more for the Load Balancer VIP. The idea behind this deployment is that the user will access the VIP first and then be redirected directly to an available UAG. That redirection and the subsequent session is direct to the UAG from the user’s endpoint.

When is this used?

The N+1 method is typically used when IP Source affinity cannot be established by the load balancer. This creates a scenario where the load balancer does not persist the session to the same UAG throughout the session and connectivity and trusted authentication become compromised. With the N+1 method, after the initial Load Balance occurs, the connection is direct to the UAG with no possibility of being switched to another UAG mid session.

The big disadvantage to this method is that it requires a lot more additional public facing IPs. One for each of the UAGs in the cluster. You could also deploy this method using PORTS if IPs are not available or in short supply. You could have UAG1 use 443, UAG2 use 444 and so on.

There is, of course, added complexity to this type of configuration so that should be factored in as well when evaluating its appropriateness for your environment.

Additional Benefits?

Aside from solving the persistence issue necessary for a successful UAG session, the N+1 architecture may provide additional benefits to the environment. For starters, it takes the load balancers out of the connectivity stream once the session is established. This allows sessions to persist even if there is a disruption with the load balancers such as a restart or fault event. In very large environments, it also redistributes the horsepower needed to accommodate all sessions to the UAGs (which can be scaled out) from the Load Balancers (which are often less scaleable due to the physical nature of them).

Another potential benefit could be the use of external cloud based Load Balancers. You could ‘rent’ an AWS or Azure based software LB service to load balance the local UAGs if a hardware appliance is not in the budget. As long as the service can monitor the UAGs for health and load, it could do it’s thing and then redirect the sessions to the appropriate UAGs in the local Data Centers.

How do I implement this?

The actual configuration for this is not difficult at all once you understand what is happening. You are basically rolling out SINGLE server UAGs with an appropriate unique configuration attached to them. Each UAG has it’s own externally facing IP with URL and is configured that way. All UAGs share the Horizon Broker infrastructure and can be configured to use it. Then you just configure the Load Balancer like you normally would for a cluster of UAGs. Since the UAG is providing its own configurations to the endpoints once the session is established, no additional configurations are really needed.

Should I use this?

This solution is not for everyone. It has a pretty defined use case (lack of source IP affinity) and should probably only be used in that scenario or when you have a LOT of user connections and you want to move those loads from the LBs to the UAGs directly. But we are really talking about the 10s of thousands of connections here for that type of load management.

As the cloud adoption becomes more and more widespread, the use of software based edge Load Balancer Services might also make this solution appealing to even smaller clients.

But I think it’s a great solution to understand and know about in case you do find yourself with one of these unique use cases or discover another one where this solution fits the bill perfectly!

Happy Remote working!
– Carlo