Avi GSLB Architecture, Terminology, and Object Model

Avi GSLB provides simplified and centralized configuration and monitoring of global applications. In a typical environment, the corporate name server delegates one or more subdomains to Avi GSLB, which then owns these domains, and provides responses to DNS queries from clients. Avi GSLB provides an active/backup model for backup or disaster recovery applications, and an active/active model to respond with the most optimal site, based on load, proximity, etc. This article overviews the architecture, terminology and object model for Avi GSLB. If you have not done so already, please read Avi GSLB Overview.

Global Applications

A global application (represented as a GSLB service in Avi Vantage) is an application which cannot or should not be wholly contained by one Avi Vantage deployment, three of the most common reasons being

  • There exists a geographically dispersed community of users (clients),
  • Resilience to loss of a data center is required, and
  • The occasional migration to or addition of another data center.

Global server load balancing (GSLB) is the act of balancing a global application’s load across individual Avi Vantage (and possibly third-party ADC) deployments. In this document, we refer to these deployments as GSLB sites.

Four Key Functions Required for Global Applications

A global application requires a solution capable of performing these functions:

  1. Definition and ongoing synchronization/maintenance of the GSLB configuration — an Avi Controller responsibility
  2. Monitoring the health of configuration components — a responsibility shared by Avi Controllers and Service Engines
  3. Optimizing application service for clients by providing GSLB DNS responses to their FQDN requests — the responsibility of an Avi GSLB DNS running in one or more Service Engines
  4. Processing of global application requests — the responsibility of services placed on Avi SEs and/or running on third-party servers/load balancers

In Avi’s design, an individual GSLB site need not perform all four functions. For example, a virtual service defined by Controller_cluster_A (site_A) might respond to requests steered to it by GSLB DNS functionality overseen by Controller_cluster_B (site_B).

GSLB Site Classification


Avi Sites vs External Sites

GSLB sites fall into two broad categories:

  • An Avi site has an Avi Vantage Controller cluster and SEs and can perform any combination of the four key functions.
  • An external site runs third-party ADCs from vendors such as F5, Citrix, etc. Such sites can only perform function 4. The opacity of an external site prevents it from participating in a GSLB site configuration, which only contains information about Avi Controller clusters, such as their address and credentials.

Note: Not every virtual service homed to an Avi site or external site need participate in the Avi GSLB solution. Said another way, not every application is a global application.

Active vs Passive Sites

We further categorize an Avi GSLB site as either an active or a passive GSLB site.

  • Active sites perform some combination of the above-listed functions 1-3, typically all three.
  • Passive sites only perform task 4, i.e., the hosting of virtual services that respond to requests from the clients of global apps.
  • A passive site is never asked to furnish steering information (function #3), so none is ever pushed to it.
  • A passive site’s health is determined by a health monitor running on an active site. It is unaware of and has no means to determine the health of other sites.
  • An active site may host virtual services that back-end global apps. To that extent, it is additionally serving in a passive role; we do not say it is more “active.”

Leader and Follower Active Sites

  • Exactly one active site is statically designated as the GSLB leader. GSLB leadership is an Avi Controller function.
  • The other active sites are GSLB followers. What GSLB configuration data they need is propagated to them from the leader.
  • The Avi site on which the administrator first defines a GSLB configuration is automatically designated as the GSLB leader; other Avi sites subsequently added are followers.
  • The only way to switch leadership is through an override configuration from a follower site’s Controller. This override can be invoked in the case of site failures or maintenance. Read this article for more information.
  • Centralized analytics are rolled up by and available from the GSLB leader. Localized metrics and logs are available for the DNS virtual services hosting the GSLB records.

The leader is responsible for functions 1, 2, 3 and very likely 4.  Followers are further classified as active or passive, based on their behavior vis-a-vis the first three functions.

An active follower …

  • Receives the GSLB configuration from the leader, and thus can take over leadership in the event of the leader’s failure.
  • Must actively monitor the health of other GSLB sites.
  • May host an authoritative DNS for the Avi global applications defined by Avi GSLB. Such redundancy makes DNS service for the GSLB configuration more reliable and boosts the performance of address resolution.

A passive follower …

  • Does not receive the GSLB configuration, and thus can’t take over for a failed leader.
  • Does not monitor other sites. Its health is determined by a health monitor running on an active site.
  • Does not a have DNS participating in the GSLB configuration. That said, it may run DNS for applications unrelated to the GSLB deployment.

Note: An Avi site may participate in exactly one Avi GSLB configuration. For example, if site_A is a participant in GSLB_config_1, an attempt to incorporate site_A into GSLB_config_2 would result in an error.

Active/Passive Site

In the above example, Santa Clara, Chicago, and NY-1 are active sites. They each have a DNS service running. Boston, Austin, and NY-2 lack DNS services; they are passive sites.

Elements of a Global Service

A GSLB service is the representation of a global application; it front-ends application instantiations running at multiple sites. Key elements of a global service include:

  • The global application service’s name, by which administrators refer to it.
  • The FQDN of the application, by which end-user clients reference it. A list of domain names can be provided for aliasing (e.g., www.foo.com and foo.com).
  • Backing services running in various GSLB sites, organized into one or more GSLB pools. Most of the time, a backing service will be an Avi virtual service. However, it can be a third-party ADC’s virtual service, or even a simple IP:port on some solitary server.
    Note: A GSLB pool is much different than a server pool. The former aggregates backing services, while the latter aggregates servers.
  • Priorities for the one or more GSLB pools associated with the GSLB service. Priority is the basis for GSLB pool selection; thereafter the selected pool’s GSLB algorithm is the basis for service member selection.
  • Health monitoring methods by which unhealthy components can be identified so that alternatives may be selected.
  • A time-to-live (TTL) ranging from 1-86400 seconds that determines the frequency with which clients need to obtain fresh steering information for their global application requests. If none is specified for a particular GSLB service, the TTL value defaults to the one specified in the DNS application profile (default is 30 seconds). Note: Avi suggests caution when using very low values of TTL, since some DNSs/operating systems will discard a very low TTL.

GSLB Pools

A global application, AppA, spanning four sites, DC1 through DC4, is depicted below left. The GSLB pool object “GslbPool_1” aggregates services VS-A1 through VS-A4 across which load will be balanced; see below right. In contrast to an Avi server pool, which aggregates servers, a GSLB pool aggregates services.


Akin to an Avi virtual service, which may be configured to content-switch load across multiple server pools, a global service can switch load across multiple GSLB pools. A client’s request is steered to a particular GSLB pool based on GslbPool.priority. Refer to the below diagram. AppB, which corresponds to the GslbService_B object, is comprised of two pools, with priorities 5 and 10. As long as the pool of highest priority (GslbPool_3) is up and not at its connection limit, all traffic will be directed to it. GslbPool_2 will remain idle. However, when/if a pool is inaccessible, down, or at maximum capacity, a lower priority pool will be chosen instead.


GSLB Pool Members

The services that comprise a GSLB pool (e.g., VS-B3 and VS-B4) are called GSLB pool members. Members can be specified by

  • their Avi virtual service name,
  • an IP address, to specify standalone servers or VIPs defined by third-party load balancers, and/or
  • a DNS name, for example, to specify a DNS-based load balancer such as AWS ELB.

Pool members may be temporarily disabled by setting the GslbPoolMember.enabled flag to False (the default is True), which tells the GSLB DNS it may no longer furnish the member’s IP address in a DNS response. For example, set it to False to temporarily remove a member from participating in the global application during a maintenance period.


All members of a GSLB pool share the same priority, but each member of the pool may potentially have different weights. When a pool is selected (by priority) and its load is distributed across the members via the round-robin algorithm, these weights dictate the fraction directed to each member. In the example depicted below, as long as VS-B3 and VS-B4 are healthy and able to accept load, GslbPool_3’s higher priority will direct all load to it, but weights will cause Avi Vantage to direct 40% of that load to VS-B3 and 60% to VS-B4.


Active and Backup Pools

An active/backup configuration is used for backup/disaster recovery. One GSLB pool could be configured as the active pool and another GSLB pool as standby. If/when all virtual services in the active pool go down, the GSLB DNS instead directs global-app traffic to the (former) standby pool. 

There exist a variety of active/active configurations. All are used to put more resources to work as well as increase application availability.

  • A load-unaware active/active configuration incorporates multiple virtual services across sites to be equally responsible for handling the application. Three options are offered — (weighted) round robin, geolocation-based, and consistent hash. Consistent hash is the one option that can provide persistence.
  • A load-aware active/active configuration steers clients to the most optimal site based on the observed load of the members. This option is slated for a future release.

Load Balancing Algorithms for GSLB Pool Members

Once a particular pool has been selected, a GSLB algorithm (as indicated in the GslbPool.algorithm parameter) balances load across the pool’s member services. As mentioned, starting with 17.1, three load-unaware algorithms became available.

  1. The weighted-round robin algorithm balances even-handedly across all members. As discussed, load can be skewed by the GslbPoolMember.ratio [default = 1, range is 1-20] values that optionally may be set for members. For example, if virtual services A, B, and C have ratios of 1, 2 and 3 respectively, virtual service A will receive one-sixth, B will get one-third, and C will get one-half the load.
  2. GSLB_ALGORITHM_CONSISTENT_HASH – load is distributed based on the client's source-IP address (likely a DNS resolver address), unless EDNS processing is ON, in which case the source-IP will be found in the ECS option. An integer mask ranging from 1 to 31 can be applied on the client IP address, if there are multiple local DNSes in a given network, in one site. This algorithm can provide persistence.
  3. The geolocation algorithm directs client requests to the optimal site based on the longitude and latitude of the client and the GSLB sites. Please refer to Geolocation-based Load Balancing Algorithm for GSLB Members for details.

As of this writing, the complete list of supported and planned load balancing options are:

  • A load-unaware configuration, as discussed above.
  • A geolocation-aware configuration steers clients to the closest site. Member selection is based on the proximity of the client to the members.
  • A load-aware configuration steers clients to the most optimal site based on the observed load of the members. This option will be added in a future Avi Vantage release.

Service Selection by Pool Priority and GSLB Algorithm

As mentioned, each GSLB pool has associated with it a priority and a GSLB algorithm. Together they govern the assignment of client requests to the individual backing services within the GSLB pool.

For example, imagine a GSLB service with two GSLB pools – P1 and P2 – with priorities 10 and 5, respectively.

  • Because 10 > 5, all traffic will be sent to P1 as long as it is operationally up.
  • If P1 is assigned the GSLB_ALGORITHM_ROUND_ROBIN algorithm (the default), load will be directed to its member services based on their individual weights.
  • If P1 is assigned the GSLB_ALGORITHM_CONSISTENT_HASH algorithm, load will be directed to its member services based on a hash of the client IP address, with a user-supplied mask optionally applied.
  • If P1 is assgned the GSLB_ALGORITHM_GEO algorithm, load will be directed to its member services based on their geographic locations.

GSLB Health Monitor

To make its steering decision, the GSLB DNS service must know the health of GS members. Accordingly, a GSLB health monitor object is configured. It is the GSLB counterpart of the [virtual service] HealthMonitor object. Two kinds of health checking (control-plane and data-plane health) and their combination are supported.

Control-Plane Health

control-plane health

Control-plane health checking of GSLB pool members is so called because it relies on each site’s Avi Controller to assess the well-being of the virtual services local to it. To keep the GSLB DNS apprised of the health of members at all the Avi sites, each active Avi Controller periodically collects performance metrics and health information from every other GSLB Controller, be those others active or passive. The figure at right shows CC-1 combining its own health observations (of VS-A1, via that VS’ SEs) to those gathered from CC-2 and CC-3 (dashed lines). It passes this consolidated impression of health on to its local DNS (dark green arrow). At the same time, CC-2 would be doing likewise, collecting health info from CC-1 and CC-3. CC-3 is a passive site, has no local DNS to keep apprised, and is thus only responsible to reply to health queries from the two active sites.

Control-plane health checks can’t be collected from DC4, the external site, because it is running a third-party ADC; any health data that ADC collects locally is opaque to Avi Vantage.

Data-Plane Health

data-plane health

Data-plane health checking of GS members is so called because it involves queries from the GSLB DNSs directly to the GS members that respond to client requests for application data. Standard and/or custom health monitors can be used.

In the figure at right, DC1’s DNS is checking a member local to it (VS-A1, via that virtual service’s SEs), as well as every other GS member VS. Note that VS-A4’s health can only be had via data-plane health checks (by directing checks to vip-4).

Simultaneously, the DNS instance located in DC2 would be doing similar checks.

Control- and Data-Plane Health Combined

Both methods can be in play simultaneously. If so, a global virtual service will be marked as UP if one of the following are true:

  • Both control-plane and data-plane health report UP.
  • Data-plane health is reporting UP but control-plane health is failing due to a Controller being down.

For more information, please refer to Avi GSLB Service and Health Monitors.

A Note on Firewalls

Firewall settings must permit bi-directional Controller communication among all active sites.

In addition, for data-plane health monitors to work, all active sites need to be able to probe all virtual services/VIPs at every site participating in a GSLB service and configured to be probed (a GSLB service config can be set to probe all members or just non-Avi members).


The expected isolation and administrative restrictions of a multitenant architecture extend to Avi GSLB.

Predefined Roles

Navigating to Administration > Accounts > Roles reveals Avi’s default predefined roles (in the blue rectangle) that may be assigned to authorized Controller users. In our particular example, clicking the plus sign at the right end of the Tenant-Admin role row expands all ten columns, revealing more details about different aspects of the Avi Vantage platform. GSLB rights (red rectangle) focus on access to three GSLB entities – the GSLB configuration, global applications (services), and the geo database that supports geolocation.

predefined roles
For each role in the system, access rights can be independently set. The below table summarizes GSLB access rights for three of the predefined roles. Additional, custom-defined roles can be imagined.

GSLB access rights for three predefined roles

GSLB Administrators, Global Application Administrators

An authorized user may enjoy a different set of access rights, depending upon how they log in, i.e., into which tenant.

GSLB may only be configured/reconfigured by a user account having write access to GSLB Configuration. Such access is included in the definition of the predefined System-Admin role, the role assigned to the user named admin. GSLB configuration can only be performed from within the tenant named admin. A system administrator can place the DNS VS in the admin tenant or some other tenant. However, a site’s GSLB DNS VS can only be configured into a non-admin-tenant via the CLI using the UUID of the DNS VS. Each application administrator associated to that Avi tenant can then use that shared-DNS VS for their global application(s).

A user with write access to GSLB Services and read access to GSLB Configuration can define global applications (GSLB services) in their own tenant. It is mandatory that the same tenant be present in all Avi GSLB sites for proper operation. The requisite DNS records are registered on the shared-DNS service. The tenant administrator is able to get analytics of only the GSLB services defined for that tenant.