The geolocation algorithm of the NSX Advanced Load Balancer DNS for GSLB directs client requests to the optimal site based on the longitude and latitude of the client and GSLB sites. Each SE in the NSX Advanced Load Balancer DNS configuration refers to its own local copy of the geolocation database (geo-DB) to make that determination.
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 (tersely 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 making that translation. DNS-1 or DNS-2 would suffice. Each DNS instantiation has access to its own, 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.
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. As figure 2 shows, the client then directs its application request to vip-1.
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 on the most granular level without relying on a pre-populated geo-DB.
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.
Based on health monitoring status, DNS-2 would have returned vip-2, vip-3, or vip-4 in geo-proximity order.
As with the round-robin algorithm, it is possible to assign weights to the VIPs. So far, we have assumed each has equal weight, i.e., a ratio of 1:1:1:1. If the weights changed to 1:2:1:1 (in VIP order 1, 2, 3, and 4), a DNS response other than VIP-1 could easily be imagined for this particular client. For example, assume dist-1 = 500 miles and dist-2 = 600 miles. Looking at a physical distance alone, vip-1 is indeed 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 very much faster than servers at other sites. At such a speedy site, server-processing-time savings compare in magnitude to transit times over the WAN. A client’s geographic location may justify routing its traffic over a slightly longer distance for the reward of overall faster roundtrip time.
There are times when a client’s IP address does not yield an accurate client location. To address this, the administrator may choose to modify the DNS application profile to enable EDNS. If this option is selected, and an EDNS subnet extension is present in the DNS request, then it will be used instead of the client’s IP address. Refer to the Extension Mechanisms for DNS (EDNS) Client Subnet Option Insertion for more details.