Avi GSLB in an AWS Multi-Region, Multi-AZ Deployment

The Multi-AZ Support for AWS article explains how a single application (i.e., a virtual service) can span N AWS availability zones (AZs). Using a single SE group, Avi Vantage places VIPs on SEs running in each AZ. The multi-VIP feature load balances application back-end servers spanning multiple AZs.

In contrast, this article discusses a scenario wherein multiple application instances span N availability zones (AZs) in multiple AWS regions and Avi GSLB load balances the traffic among regions. The result is optimal user experience based on proximity and high availability.

xxxxxx
xxxxxx

Configuration

Initial configuration steps would be similar to the steps mentioned here. The difference lies in the way GSLB service is configured. In this section we discuss two methods by which to configure GSLB service for this scenario.

Method 1

  • Configure GSLB pool member using the IP address option.
  • Specify the FQDN of multi-VIP VIPs. As illustrated in the figure above, the FQDN is either aws-vs.demo.awsavi.net or aws-vs-east.demo.awsavi.net

    xxxxxx

  • As shown in the above screenshot, the pool member is configured with an FQDN.
    • The FQDN is resolved to an IP address by the Controller.
    • The DNS VS monitors the health of the resolved address while it returns the CNAME in its response.
    • If the user has configured an IP address, then the IP address will get overwritten whenever periodic FQDN refresh is done by the Controller.
    • Only one of the IPs - not all is monitored. Either the Avi Controller or AWS withdraws IP addresses/members that are not up.

Request Flow

xxxxxx

  1. A client sends a request to access avi.app.gslb.com.
  2. The request lands on Avi DNS VS, which identifies the most optimal pool member (in this case, either aws-vs.demo.awsavi.net or aws-vs-east.demo.awsavi.net),based on the GSLB method specified.
  3. The Avi DNS VS responds back to the client with a CNAME in the response.

    xxxxxx

  4. The same CNAME is sent to the client.
  5. Once the client gets the CNAME , the client sends another DNS query for resolution of the CNAME, based on the DNS server configuration. AWS may be configured as authoritative for subdomain demo.awsavi.net, Avi may be authoritative, or DNS settings may be configured in some other way.
  6. The CNAME gets resolved to one of the IP addresses of the individual VIPs (based on the DNS server used by the client, either Route 53 or Avi DNS ). In both the cases, these FQDNs (aws-vs.demo.awsavi.net or aws-vs-east.demo.awsavi.net) of multi-VIP VS get automatically recorded/registered in the DNS as A records pointing to individual VIPs. Example - if Route 53 is used as the DNS while deploying the cloud, then the FQDNs get registered on Route 53 as shown below.

    xxxxxx
    xxxxxx
    If Avi DNS is used instead, then the FQDNs get registered within Avi in a similar fashion.

Method 2

  • Configure using the individual VIP IP addresses, i.e., VIP1 IP1, VIP2 IP2, etc.
    xxxxxx
    xxxxxx
    • This permits configuring individual VIPs for the multi-VIP VS. If it is desired to add all the VIPs under GSLB service, then all the VIPs need to be added manually.
    • When a client sends a request for avi.app.gslb.com, the request first lands on the Avi DNS VS, which then chooses the optimal endpoint based on the configured GSLB algorithm.
    • The DNS VS then responds with one of the VIPs’ IP address.
    • Since each VIP has been explicitly added in this method, Avi uses datapath health checks to monitor the health of each member individually.
  • This second method outlined has a few limitations :
    • A new VIP might be added to a multi-VIP VS (i.e., VS1 IP3 is added to the pre-existing 2 IPs). In that case, one must manually edit the GSLB service and add the new VIP into the GSLB pool.
    • Being a multi-VIP VIP, there could be a case where IP addresses of the VIP are changed, possibly leading to inconsistency, unless the pool is not manually changed in the GSLB service.
      An Avi GSLB pool member can be — and typically is— an Avi virtual service (with associated VIP:port_number). The configuration of such a member requires the user to uniquely identify the site-id, the virtual service within the site, and the corresponding VIP of the virtual service. The relevant parameters are: cluster_uuid, vs_uuid and GslbPoolMember.ip within the GslbPoolMember object.
      For whatever reason, the site administrator changes Avi Vantage’s local configuration of the particular virtual service such that its VIP1 is changed from IP2 to IP4 .
      The situation: Whereas local VIP IP4 is operational, its address is not (yet) known to the GSLB configuration; it is no longer advertised as part of the global app; references to IP2 are invalid. The GSLB leader and active members detect the discrepancy between the VIP (IP2) and VIP (IP4). Avi Vantage then disables the GSLB pool member in question and notifies the administrator that the “Configured and Operational VIPs are out of Sync”.
      This is explained in detail in the Changing VIP of a Local VS Member of a GSLB Pool article.
      To avoid these situations, configuring the GSLB pool members for Multi VIP scenario using the first method is recommended. The advantages are:
  • There is no need to add individual VIPs.
  • There is no inconsistency in the event IPs change on a VS level.