The geolocation algorithm of the NSX Advanced Load Balancer DNS for GSLB directs client requests to the optimal site based on the location (longitude and latitude) of the client and GSLB sites. Each SE in the DNS configuration refers to its own local copy of the geolocation database (geo-DB) to determine this.
Operation
Figure 1 shows the operation of the Geolocation algorithm.
A client with IP address = client_IP requests service from a multi-site application implemented by four virtual services (VS-A1 through VS-A4) in four geographically separated data centers, DC1-DC4, one of which is a non-NSX Advanced Load Balancer load-balanced site (concisely referred to as an external site). The client’s local DNS must resolve the FQDN for the application to one of four potential addresses, vip-1, vip-2, vip-3, or vip-4. The first step is to find a DNS capable of doing that translation. DNS-1 or DNS-2 would suffice. Each DNS instantiation has access to its identical geo-DB. Using that database, either DNS-1 or DNS-2 can translate the five IP addresses into latitude-and-longitude-based locations.
The selection of DNS-2 is outside the control of NSX Advanced Load Balancer and thus may have nothing to do with geographical location. We have intentionally selected a more distant DNS to underscore this fact.
As figure 2 shows, the client then directs its application request to vip-1.
The algorithm running in DNS-2 calculates four distances, determines that dist-1 is the shortest, and therefore responds to the DNS request with vip-1. The distance is calculated between the client IP address and the various app instances (VS-A1 to VS-A4 in this example) using the longitude and latitude information from the geo-DB.
The actual client IP address (source IP) is used if it is a part of EDNS and the EDNS process is enabled on NSX Advanced Load Balancer.
If the EDNS subnet extension is not present in the DNS request, then the IP address of the last DNS hop is used.
Apart from geo-DB, the NSX Advanced Load Balancer supports more ways to specify the location, as explained in Assigning Geographic Locations to VIPs.
For more information on Geo-DB, see Geolocation Database (Geo-DB).
Assigning Geographic Locations to VIPs
Each GSLB service pool’s algorithm is independently set. The round-robin, consistent hash, and geolocation algorithms are the current options. To implement the geolocation algorithm, the NSX Advanced Load Balancer DNS for GSLB must have a way to assign locations to GSLB sites comprising a GSLB service. On a per-GSLB-service basis, the options are as follows:
- Compute location from geo-DB (default)
-
This method requires a look-up in a database constructed in advance. This database is described in a subsequent section of this guide.
- Inherit location from site
-
With this methodology, each participating GSLB site is assigned a location as part of the GSLB configuration object. The GSLB service’s member virtual service running at the site statically inherits the location associated with this site. This method can be useful when no bulk geo-DB information has been imported.
- Explicit configuration
-
This manual process gives the administrator full control at the most granular level without relying on a prepopulated geo-DB.
Considerations for Distance Calculation and Assignment of Geo-location
When the geolocation algorithm is selected for a given GSLB service, member virtual services with VIPs whose locations cannot yet be determined are essentially opaque. DNS responses will never include their VIPs. Instead, the geolocation algorithm will select a VIP from among the set of virtual services whose locations can be determined.
If no single member virtual service has a VIP whose location can be determined, the NSX Advanced Load Balancer DNS for GSLB will fall back to the (weighted) round-robin algorithm.
Since the distance calculation is based purely on a virtual service’s VIP, both NSX Advanced Load Balancer and external sites are candidates for VIP selection.
As with the round-robin algorithm, assigning weights to the VIPs is possible. So far, we have assumed each has equal weight, that is, a ratio of 1:1:1:1. If the weights are changed to 1:2:1:1 (in VIP orders 1, 2, 3, and 4), a DNS response other than VIP-1 can easily be imagined for this particular client. In figure 2 - 2. Geolocation algorithm running in DNS-2 selects vip-1, assume dist-1 = 500 miles and dist-2 = 600 miles.
The geographic location of a client might justify routing its traffic over a slightly longer distance for the reward of overall faster round-trip time. Looking at a physical distance alone, vip-1 appears as the right choice. But assigning a weight of 2 to vip-2 causes the algorithm to compare 500 miles to 600 / 2 miles. Since 300 is less than 500 miles, vip-2 would instead be selected. One use case for such weighting is a site whose servers are much faster than servers at other sites. At such a site, server-processing-time savings compare in magnitude to transit times over the WAN.
Sometimes, the IP address of a client does not yield an accurate client location. To address this issue, the administrator can modify the DNS application profile to enable EDNS. If this option is selected and an EDNS subnet extension is present in the DNS request, the EDNS subnet extension will be used instead of the client IP address. For more information, see Extension Mechanisms for DNS (EDNS) Client Subnet Option Insertion in the VMware NSX Advanced Load Balancer Configuration Guide.
