This section covers the user request flow for the GSLB application.

Procedure

  1. FQDN Address Resolution

    Figure 1 shows a client sending an HTTPS request to download the home page of application A. Its FQDN (A.acme.com) must be mapped to an IP address that is not yet known to the client. A hierarchical tree of DNS resolvers eventually identifies the corporate DNS for acme.com.

    The corporate DNS forwards the request to one of the three GSLB DNS instances since domain A.acme.com has been delegated to the NSX Advanced Load Balancer's global DNS (in this case to DNS-2).

    DNS-2 has four candidates for the optimal virtual sevice choice: 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 eventually reaches the original client.

    Figure 1. 1. FQDN address resolution
  2. Application Traffic Flows to Optimal Virtual Service

    Figure 2 shows the client using the VIP of VS-A3 to send its HTTP request.

    Figure 2. 2. Application traffic is directed to the optimal VIP
  3. Local Load Balancing

    Figure 3 shows one of the SEs in the SE group receiving the request directed to the VIP of VS-A3. It then load-balances it to one of VS-A3’s 3 servers. VS-A3 responds directly to the client.

    Figure 3. 3. Local load balancing