A topology-based algorithm is supported for GSLB. A DNS virtual service has an option to configure topology policies (similar to DNS policies). These policies are triggered for the services configured with the topology-based GSLB algorithm. For other algorithms, the topology policies are not consulted.

Use Case

The topology-based algorithm is used in a deployment where hundreds of GSLB services are deployed across various tenants. The requirement is to use a round-robin algorithm for a few GSLB services, and for others, you need to define the preferred site based on the client’s IP address, Geo Location, and so on.

Previously, the above requirement is achieved using string groups. String groups are part of DNS policies to specify the GSLB services FQDN name. DNS policies are triggered using string groups to call out the preferred site. This approach is feasible for smaller environments but not for massive deployment.

For multiple GSLB services, using string groups is not feasible if you have the tenant-based access restriction where tenant users cannot modify DNS policies. This privilege to modify DNS policy is required to add the GSLB service’s FQDN in the string group.

The limitations mentioned above can be solved using the topology-based GSLB algorithm.

For this use case, a few GSLB services are configured with the round robin method, and the remaining services are configured with the topology-based algorithm. The topology policies are triggered only for the GSLB service that has a topology-based algorithm as the GSLB algorithm. Using this method, there is no overhead of configuring string groups or changing to DNS virtual service every time a new GSLB service is added to any tenant.

Note:

  • Topology policy consists of the exact match targets and actions of DNS Policy. It is recommended to use the preferred site or the fallback site action for topology-based policies.

  • For the GSLB services that do not have topology algorithm configured, the topology policies are not considered.

  • A topology policy applies to all the GSLB services using a topology-based GSLB algorithm. If the requirement is to have a different topology policy for different GSLB services, then string groups for FQDNs are used.

  • If the action configured for the topology policy fails, for example, if the configured preferred site does not exist anymore, then NSX Advanced Load Balancer GSLB falls back to the Geolocation algorithm. If Geolocation fails, then the GSLB falls back to round robin.

  • If a DNS virtual service has both the policies associated with it (DNS and Topology policies), then both the policies are triggered. The policies are triggered in the following order depending on the action configured within the policies:

    • If the DNS policy is configured to drop the request or send an error response, then this takes precedence over the topology policy.

    • If the DNS policy has action configured as the site selection, then the topology policy decision overrides the DNS policy.

It is recommended to configure drop or respond policies in the DNS policy, and preferred or fallback site-selection policies in the topology policy.

Topology Policy on GSLB Service Level

The topology policy algorithm can also be enabled on the GSLB service level apart from the GSLB pool level.

Consider a GSLB service that has two GSLB pools. The GSLB pools have their pool members. When the topology is enabled on the GSLB service level, topology policy rules are used for pool selection. At the time of pool selection, there could be multiple cases, as explained below:

  1. If a match is found as per the topology policies and the matched GSLB pool has a valid pool member (that is UP and healthy), NSX Advanced Load Balancer servers send that record to the client.

  2. If no match is found as per the configured topology policies rules, the configured GSLB algorithm is used for pool selection.

  3. If the selected pool has no valid members (for example, all pool members are down or deactivated), pools are tried in decreasing order of priority till a valid member is found. If all the pools have the same priority, pools are selected in a round-robin fashion.

  4. If the selected pool has, in turn, configured a topology algorithm, topology policy rules are used again to get a valid member from this pool. A typical use case is to select a pool and then select members from preferred sites.