Avi GSLB Architecture

This article has been replaced with Avi GSLB Architecture, Terminology, and Object Model.

Content prior to 29Aug2018:

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 can implement 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, functionality, and terminology for Avi GSLB.

Features Supported in Avi Vantage 16.3

  • DNS-based load balancing
  • Active/DR GSLB
  • Active/active GSLB with consistent hash
  • Hybrid cloud support
  • Centralized provisioning and visibility
  • Control-plane and data-plane health monitoring
  • Multitenancy support
  • Support for 3rd party load balancers

Features Planned for Future Releases

  • Active/active GSLB, based on load, geo-location and site cookie persistence
  • Centralized application logs

Architecture and Terminology

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 loading 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.


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

  1. Definition and ongoing synchronization/maintenance of the GSLB configuration,
  2. Monitoring the health of configuration components,
  3. DNS-based steering of inbound application requests to the best source for responses, and
  4. The actual processing of those responses.

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 DNS functionality overseen by Controller_cluster_B (site_B).

To better understand the steps one takes and the objects one touches to implement the Avi GSLB solution, it is important to keep in mind these distinct GSLB functions.

GSLB Site Types

GSLB sites fall into two broad categories:

  • An Avi site runs an Avi Vantage Controller cluster and SEs.
  • An external site runs third-party ADCs from vendors such as F5, Citrix, etc.

With the previously mentioned four functions in mind, we can 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. It is the one on which the initial GSLB site configuration is performed.
  • The other active sites are GSLB followers. What GSLB configuration data they need is propagated to them from the leader.
  • The only way to switch leadership is through an override configuration from a follower site. This override can be invoked in the case of site failures or maintenance.
  • 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.

Avi Sites Versus External Sites

  • Avi sites can perform any combination of the four functions. Each Avi site is characterized/identified by an Avi Controller cluster.
  • External 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 a particular Avi or external site need participate in the Avi GSLB solution. Put another way, not every application is a global application.

Defining a GSLB Service

A GSLB service is the representation of a global application. The corresponding GslbService object identifies

  • the application service’s name,
  • the FQDN of the application,
  • one or more GSLB pools comprising virtual service members running the application in the GSLB sites,
  • the priority/weights of the GSLB pools,
  • the weights of the virtual service members within those pools, and
  • the monitoring methods to be used to make sure members are alive.

The above merits further explanation.

A GSLB (pool) member is typically a virtual service (as opposed to a service running on a solitary back-end server without an ADC front-ending it). Like other virtual services, a GSLB member is represented by an IP address:port or a name. 

A GSLB pool is a collection of GSLB pool members sharing the same priority, but potentially different weights. 

Note: A GSLB pool is much different than an Avi server pool. The former aggregates virtual services, the latter aggregates servers. That said, there is a hierarchical relationship between the two types of pools.

The GslbHealthMonitor object is the GSLB counterpart of the [virtual service] HealthMonitor object. It provides configuration for monitoring the health of GSLB pool members.

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. Two options are offered — (weighted) round robin and consistent hash. In the 16.3 release, consistent hash is the one option that can provide persistence. Load/proximity support will be added in subsequent releases.
  • A load-aware active/active configuration steers clients to the most optimal site based on the observed load of the members. This option is planned for a future release.
  • A geo-location-aware active/active configuration steers clients to the closest site. Member selection is based on the proximity of the client to the members. This option is planned for a future release.

GSLB deployment architecture

Active/Passive Site

In the above example, Santa Clara, Chicago, Austin and NY are active sites while Boston is a passive site. Among the active sites, Santa Clara performs the function of GSLB leader, redirecting DNS queries to the appropriate followers (Chicago, Austin and NY).

GSLB Services

A GSLB service is the representation of a global application, that front-ends applications across multiple sites. This configuration object hosts the FQDN of the application, the backing virtual services in various sites, and the priority/ratios for the various members. This object also hosts the monitoring methods to make sure that the group members are alive.

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

Health Checks

There are three options for the GSLB member health checks required by the GSLB DNS virtual service:

  • Control-plane health - The DNS virtual service collects the results of checks performed by the Avi Controllers located at the sites where the various local and remote virtual services run
  • Data-plane health - The DNS virtual service performs GSLB healh checks directly to local and remote member virtual services
  • Both control- and data-plane health - For a GS member to be marked as UP, both control- and data-plane health should report UP. If control-plane health checks are failing because the Controller is unreachable) but data-plane health checks are working, the GS member is  marked as UP.

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

Overall Flow

GSLB  deployment architecture

A GSLB service is the representation of a global application that front-ends applications across multiple sites. Among other parameters, the GslbService configuration object defines the FQDN of the application, the backing virtual services in various sites, and the priority/ratios for the various members. This object also hosts the monitoring methods to make sure that the virtual service members are alive. The GSLB DNS can offer the GSLB service either DNS-based load-balancing or geo-location-based routing.

Site Failure Handling

Consider two failure cases:

  • GSLB leader site fails
  • Follower site fails

In both cases, the DNS service marks all GS members of the failed site as DOWN. In the above example, NY site has crashed while Santa Clara (GSLB leader) and Chicago sites are still functioning.

In case of a GSLB follower site failure, the GSLB configuration is synchronized with the currently UP active site(s). In case only the Controller at an active site fails, the follower site’s DNS server will cannot receive GSLB configuration updates because all configuration updates must flow through a Controller to the follower site’s GSLB DNS.

In case of GSLB leader site failure, no modifications can be made to GSLB configuration.

Site Failure Recovery

All active sites detect successful connection to a follower via control-plane health monitor updates. In the case of control-plane health monitors, active sites query the Controllers at other sites to fetch health and load information of the GSLB virtual services local to them.

The GSLB DNS service then updates the GS member status of the recovered sites as UP or DOWN based on the GS health monitors.

  • Follower Site Recovery

The GSLB leader detects successful connectivity to a follower shortly after it has come up and updates it with the latest GSLB configuration.

  • Leader Site Recovery

Only an administrator can resume updates to the GSLB configuration.

To know more about GSLB leader and site recovery, please refer to Avi GSLB Site Configuration and Operations.

Tenancy and GSLB

  1. The Avi admin user can do a GSLB site configuration.
  2. The Avi admin user or a tenant administrator can configure the GSLB DNS virtual service.
  3. Each tenant user can create a GSLB service and health monitors for it. The requisite DNS records are registered on the GSLB DNS virtual service configured in step 2.


  • A tenant administrator has visibility only to his/her tenant’s GSLB services.
  • The tenant should have read access to the Gslb configuration object.