Global Server Load Balancing (GSLB) is the act of balancing an application’s load across instances of the application that have been deployed to multiple locations. Application load at any one of those locations is usually managed by a local load balancer.
With GSLB, access to resources is controlled with DNS queries and health checking. Knowing if a site is healthy or not, GSLB serves back the IP in the form of a DNS record of the site the user must access based on the configured logic. If you have multiple instances of application/UAG servers deployed across the globe, and your users are geographically dispersed then, GSLB is required.
Currently this feature is under tech preview.
Prerequisites
Ensure the following prerequisites are met:
The Avi Load Balancer Controllers are set up in all the data canters
The cloud configuration is complete
The sites are added in GSLB and DNS virtual services are configured on the individual sites as per the requirement
UAG servers configured as per requirements along with other Horizon components
Reference Architecture
NSX Advanced Load Balancer can be deployed on-prem or on any cloud ecosystem which allows for easy deployment to load balance Horizon traffic in any ecosystem. Avi Load Balancer GSLB enables distributing the load across multiple, geographically dispersed data canters. Consider the request flow with the sample topology:
Only two GSLB sites are shown here. You can add more GSLB sites as per the requirement.
A sample topology is discussed below:
Avi Load Balancer is running in two locations (GSLB sites):
On Premises (Avi Load Balancer GSLB Site 1)
Public Cloud (Avi Load Balancer GSLB Site 2)
Each site has its own Avi Load Balancer Controller Cluster (represented by a single Controller icon)
The Avi Load Balancer for UAG has virtual services running in Avi Load Balancer GSLB Site 1 and Avi Load Balancer GSLB Site 2 respectively:
VIP1
VIP2
The GSLB service (GS) app domain name is demo.gslb.appshzn.com.
Avi Load Balancer GSLB Site 1 and Avi Load Balancer GSLB Site 2 have global DNS services (Avi Load Balancer DNS1, Avi Load Balancer DNS2 respectively). They are equally authoritative for the subdomain gslb.appshzn.com.
Avi Load Balancer monitors the health of the virtual services to choose the best location (that is, rule out unhealthy locations).
Request Flow
The client sends a request to access demo.gslb.appshzn.com.
The request goes to the Corporate DNS server that further sends the DNS query to one of the two Avi Load Balancer DNS servers: Avi Load Balancer DNS 1 or Avi Load Balancer DNS 2.
Assume that the request goes to Avi Load Balancer DNS 1. Avi Load Balancer DNS 1 selects the UAG VIP depending on the GSLB algorithm.
Assume that Avi Load Balancer DNS responds to the client with the IP address of VIP1.
Now the client sends a request directly to Avi Load Balancer on site1 that is VIP1.
The client initiates a request to Horizon demo.gslb.appshzn.com on L7 TLS port 443.
NSX Advanced Load Balancer picks a UAG server from the pool’s server list using the LB algorithm. Then Avi Load Balancer responds with a 307 redirect with location set to UAG VIP FQDN and with a custom L7 port meant for the selected UAG server. See the configuration section. We have added service ports in the range 5001-5005 as Horizon internal ports. Those ports are referred to as custom ports here.
All subsequent requests come from the client with this hostname+L7 port and are sent to the mapped UAG server.
The service ports 5001 to 5005 are specified on the virtual service.
Assume there are two backend UAG servers – UAG1 and UAG2. When the initial request comes on Avi Load Balancer L7 virtual service on port 443, Avi Load Balancer chooses one of these servers based on the configured load balancing algorithm – UAG 1 or UAG 2. If Avi Load Balancer has chosen UAG 1 server from the pool then it responds with a 307 redirect with location header set to the VIP FQDN with 5001 port (meant for UAG server1). Similarly in the case of UAG server2, port 5002 will be set by Avi Load Balancer. If you have more UAG servers, then add more ports like 5003, 5004, and so on, on the Avi Load Balancer virtual service.
To get custom port mapping to UAG servers, use show pool <pool-name> vs service server map kv as shown below:
admin:10-50-55-87]: > show pool UAG-MVP-pool vs service server map kv
+-------------------+---------------------------------------------------------+
| Field | Value |
+-------------------+---------------------------------------------------------+
| uuid | se-00505695c1f1 |
| keyval_entries[1] | |
| key | 10.98.17.153,47873,2 |
| val | fe_l7_port:5003,fe_blast_port:20003,fe_pcoip_port:30007 |
| local_eol | 1000 |
| version | 0 |
| ishub | False |
| keyval_entries[2] | |
| key | 10.130.172.191,47873,2 |
| val | fe_l7_port:5002,fe_blast_port:20002,fe_pcoip_port:30006 |
| local_eol | 1000 |
| version | 0 |
| ishub | False |
| keyval_entries[3] | |
| key | 10.130.172.192,47873,2 |
| val | fe_l7_port:5001,fe_blast_port:20001,fe_pcoip_port:30005 |
| local_eol | 1000 |
| version | 0 |
| ishub | False |
+-------------------+---------------------------------------------------------+
Use show pool <pool-name> vs service server map table as shown below:
[admin:10-50-55-87]: > show pool UAG-MVP-pool vs service server map table
+--------------------------------+--------------------+
| Field | Value |
+--------------------------------+--------------------+
| uuid | se-00505695c1f1 |
| vs_service_server_map_entry[1] | |
| app_service_port | 5001 |
| app_service_type | HORIZON_INTERNAL |
| ip_port_str | 10.130.172.192:443 |
| vs_service_server_map_entry[2] | |
| app_service_port | 5002 |
| app_service_type | HORIZON_INTERNAL |
| ip_port_str | 10.130.172.191:443 |
| vs_service_server_map_entry[3] | |
| app_service_port | 5003 |
| app_service_type | HORIZON_INTERNAL |
| ip_port_str | 10.98.17.153:443 |
| vs_service_server_map_entry[4] | |
| app_service_port | 20001 |
| app_service_type | HORIZON_BLAST |
| ip_port_str | 10.130.172.192:443 |
| vs_service_server_map_entry[5] | |
| app_service_port | 20002 |
| app_service_type | HORIZON_BLAST |
| ip_port_str | 10.130.172.191:443 |
| vs_service_server_map_entry[6] | |
| app_service_port | 20003 |
| app_service_type | HORIZON_BLAST |
| ip_port_str | 10.98.17.153:443 |
| vs_service_server_map_entry[7] | |
| app_service_port | 30005 |
| app_service_type | HORIZON_PCOIP |
| ip_port_str | 10.130.172.192:443 |
| vs_service_server_map_entry[8] | |
| app_service_port | 30006 |
| app_service_type | HORIZON_PCOIP |
| ip_port_str | 10.130.172.191:443 |
| vs_service_server_map_entry[9] | |
| app_service_port | 30007 |
| app_service_type | HORIZON_PCOIP |
| ip_port_str | 10.98.17.153:443 |
+--------------------------------+--------------------+
In summary, Avi Load Balancer L7 VIP must have enough service ports, each dedicated to a UAG server in the Pool. We recommend opening enough ports in the beginning itself. With this capability of Avi Load Balancer doing 307, any new UAG server can be added to the server pool with little to no configuration change needed on the Horizon server. Incoming client requests coming to a specific L7 service port (other than the base port) will be content switched to specific UAG servers in the pool.
Client sends the request on the redirected FQDN <FQDN>
Avi Load Balancer sends the request to one of the UAG servers. As per our example, it will be sent to UAG1.
UAG responds back to Avi Load Balancer with XML data. After a client completes authentication with a selected UAG server, UAG response containing IP/FQDN is used for secondary protocols communication.
Avi Load Balancer parses this response, replaces the IP/FQDN and port XML tags with the Avi Load Balancer FQDN and L4 Service port.
For example, in the case of UAG1, Avi Load Balancer VIP FQDN and 20001/30005 port (Blast/PCoIP respectively). Similarly, in the case of UAG 2, Avi Load Balancer changes it to Avi Load Balancer VIP FQDN and 20002/30006 port (depending on if it is Blast/PCoIP respectively).
Then L4 request with the custom port land on Avi Load Balancer virtual service. Using the custom port, NSX Advanced Load Balancer knows to which UAG server the request must be sent to.
Avi Load Balancer sends the request to the appropriate UAG server. In this example, it is sent to UAG1.
UAG responds to NSX Avi Load Balancer.
Avi Load Balancer sends the response to the client which will be able to render the apps/desktops successfully.
