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.
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.
Four Key Functions Required for Global Applications
A global application requires a solution capable of performing these functions:
- Definition and ongoing synchronization/maintenance of the GSLB configuration,
- Monitoring the health of configuration components,
- DNS-based steering of inbound application requests to the best source for responses, and
- 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).
GSLB Site Classification
Avi Sites vs External Sites
GSLB sites fall into two broad categories:
- An Avi site runs 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 a particular Avi or external site need participate in the Avi GSLB solution. Put 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. 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.
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 (from the first and only leader) is through an override configuration from a follower site. This override can be invoked in case of site failures or maintenance.
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. If site_A is a participant in GSLB_config_1, an attempt to incorporate site_A into GSLB_config_2 will result in an error.
Defining a Global Service
A GSLB service is the representation of a global application; it front-ends instantiations of the application that are deployed at multiple sites. The corresponding GslbService object identifies the following data, which are key to understanding operation of the Avi GSLB:
- The application service’s name, by which administrators reference the GSLB configuration.
- 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 virtual services in various GSLB sites, organized into one or more virtual service pools.
- Priorities for the various pools and weights of the virtual service members within those pools.
- A load-balancing algorithm governing the assignment of client requests to backing servers.
- 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 client requests. If none is specified for a particular GSLB service, the TTL value defaults to the one specified in the DNS application profile (default there 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.
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 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.
- For a GSLB service the minimum members parameter refers to the minimum number of servers within the GSLB service pools.
- For a GSLB service having the priority GSLB service algorithm, pools are sorted based on the priority and the minimum servers’ logic is applied.
- For a GSLB service having the geolocation GSLB service algorithm, pools are sorted based on the client’s location and the minimum servers’ logic is applied.
For instance, in the case of two pools – P1 and P2 with priority ten and five respectively – the traffic will be sent to P1 as long as it is up. With minimum servers logic, P1 will be chosen exclusively as long as the number of servers active in P1 matches the defined minimum server value. That is, if the minimum servers’ value is set to five, then P1 will be chosen as long as it has five active(up) servers.
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. 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.
- A geolocation-aware active/active configuration steers clients to the closest site. Member selection is based on the proximity of the client to the members. Refer to this article.
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).
A global application, AppA, spanning four sites, DC1 through DC4, is depicted below left. A GslbPool object “GslbPool_1” combines virtual services VS-A1 through VS-A4 into a single entity and balances load across them; see below right. In contrast to an Avi server pool, which aggregates servers, a GSLB pool aggregates virtual services.
Akin to a simple 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 virtual 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 theGslbPoolMember.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 will direct 40% of that load to VS-B3 and 60% to VS-B4.
Load Balancing Algorithms for GSLB Pool Members
Once a particular pool has been selected, a GslbPool.algorithm balances load across the pool’s virtual services. Starting with 17.1, three load-unaware algorithms became available.
- 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.
- Consistent hash is based on the client IP address (typically the local DNS IP address). A mask can be applied on the client IP address, if there are multiple local DNSes in a given network, in one site. IT is an option that can provide persistence. Starting with 17.2.5, GSLB site cookie persistance is the other.
- 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.
Bypassing the Load Balancing Algorithm
Under certain circumstances, it may be desirable to bypass the load balancing algorithm for certain clients based on certain conditions being met. Refer to the GSLB Site Selection with Fallback and Preferred-Site Options article.
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 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 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.
If there are firewalls between sites, they must be optioned to permit communication from the GSLB DNSs to all VIPs.
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.
The expected isolation and administrative restrictions of a multi-tenant architecture extend to Avi GSLB. GSLB is configured by the Avi “admin,” who can place the DNS service VS in the “admin” tenant or some other. Each Avi tenant can then use that shared DNS service VS for their global applications.
Each tenant user can define their own global applications (GSLB services) in their own tenant. The requisite DNS records are registered on the shared DNS service. The tenant admin is able to get analytics of only GSLB services in that tenant. The tenant user needs only “read” access to the GslbService object.