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 NSX Advanced 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. NSX Advanced 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:
NSX Advanced Load Balancer is running in two locations (GSLB sites):
On Premises (NSX Advanced Load Balancer GSLB Site 1)
Public Cloud (NSX Advanced Load Balancer GSLB Site 2)
Each site has its own NSX Advanced Load Balancer Controller Cluster (represented by a single Controller icon)
The NSX Advanced Load Balancer for UAG has virtual services running in NSX Advanced Load Balancer GSLB Site 1 and NSX Advanced Load Balancer GSLB Site 2 respectively:
VIP1
VIP2
The GSLB service (GS) app domain name is demo.gslb.appshzn.com.
NSX Advanced Load Balancer GSLB Site 1 and NSX Advanced Load Balancer GSLB Site 2 have global DNS services (NSX Advanced Load Balancer DNS1, NSX Advanced Load Balancer DNS2 respectively). They are equally authoritative for the subdomain gslb.appshzn.com.
NSX Advanced 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 NSX Advanced Load Balancer DNS servers: NSX Advanced Load Balancer DNS 1 or NSX Advanced Load Balancer DNS 2.
Assume that the request goes to NSX Advanced Load Balancer DNS 1. NSX Advanced Load Balancer DNS 1 selects the UAG VIP depending on the GSLB algorithm.
Assume that NSX Advanced Load Balancer DNS responds to the client with the IP address of VIP1.
Now the client sends a request directly to NSX Advanced 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 NSX Advanced 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 NSX Advanced Load Balancer L7 virtual service on port 443, NSX Advanced Load Balancer chooses one of these servers based on the configured load balancing algorithm – UAG 1 or UAG 2. If NSX Advanced 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 NSX Advanced Load Balancer. If you have more UAG servers, then add more ports like 5003, 5004, and so on, on the NSX Advanced 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, NSX Advanced 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 NSX Advanced 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>
NSX Advanced 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 NSX Advanced 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.
NSX Advanced Load Balancer parses this response, replaces the IP/FQDN and port XML tags with the NSX Advanced Load Balancer FQDN and L4 Service port.
For example, in the case of UAG1, NSX Advanced Load Balancer VIP FQDN and 20001/30005 port (Blast/PCoIP respectively). Similarly, in the case of UAG 2, NSX Advanced Load Balancer changes it to NSX Advanced 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 NSX Advanced Load Balancer virtual service. Using the custom port, NSX Advanced Load Balancer knows to which UAG server the request must be sent to.
NSX Advanced Load Balancer sends the request to the appropriate UAG server. In this example, it is sent to UAG1.
UAG responds to NSX NSX Advanced Load Balancer.
NSX Advanced Load Balancer sends the response to the client which will be able to render the apps/desktops successfully.
