This section covers the user request flow for GSLB in reference to the topology shown in the previous topic.
Procedure
- FQDN address resolution
The following figure shows a client sending an HTTPS request to download the home page of application A. Its FQDN, namely A.acme.com, must be mapped to an IP address that is not yet known to the client. A hierarchical tree of DNS resolvers identifies the corporate DNS for acme.com.
The corporate DNS forwards the request to one of the three GSLB DNS instances, namely DNS-2, because the domain A.acme.com has been delegated to NSX Advanced Load Balancer DNS.
DNS-2 has four candidates to choose for the optimal virtual service, namely, VS-A1, VS-A2, VS-A3, and VS-A4. It selects VS-A3, based on the load balancing algorithm, health, client location, and other factors. DNS-2 responds to the DNS query with the VIP of VS-A3, which in turn reaches the original client.
- Application traffic flows to optimal virtual service.
Once the FQDN is resolved to an IP address, the client query goes directly to the IP address returned by the DNS service (VIP of VS-A3 in this example). The following figure shows the client using the VIP of VS-A3 to send its HTTP request.
- Local load balancing.
The following figure shows one of the SEs in the SE group receiving the request directed to the VIP of VS-A3. It then redirects it to one of the 3 servers of VS-A3. VS-A3 responds directly to the client.
