Multi-AZ Support for AWS

This article introduces a feature which supports a single application spanning N availability zones (AZs).

Overview

The Multi-AZ feature addresses load balancing back-end servers of an application (virtual service) spread across multiple AZs in AWS with a VIP in each AZ. Without this feature, the user has to configure separate virtual services, one in each AZ. Avi Vantage centrally configures the Multi-AZ VS, and combines analytics and logs across multiple VIPs of the same VS into a single consolidated view for the application.

Refer to the below diagram. The application’s virtual service shares a common pool of nine servers (SRV1 - SRV9) in a single pool spanning the 3 availability zones (AZ-1, AZ-2, AZ-3). The servers are accessed via 3 VIPs (VIP1, VIP2, VIP3), one per AZ.

Multiple-VIP virtual service example

Note: In a Multi-AZ deployment, it is not required to have Active/Active HA for VIPs within each AZ. The Multi-AZ deployment automatically provides the HA by having SE instances across AZs. Also, Avi supports non-disruptive upgrades (SE in each AZ is upgraded one at a time, keeping the VS always up during the upgrade). Hence the recommended HA mode is N+M with buffer of 0.

Recommended Reading: Avi GSLB in a Multi-AZ AWS Deployment shows how Avi GSLB can be incorporated to raise the deployment to a higher level of sophistication. Applications can span N availability zones (AZs) in multiple AWS regions of AWS and Avi GSLB load balances the traffic among regions, providing a highly available solution that optimizes user experience based on the proximity.

DNS

For the Multi-AZ feature, the virtual service must be configured with an FQDN. Avi Vantage integrates with Avi DNS as well as Route 53 in AWS. One or the other is a pre-requisite for the Multi-AZ feature In both cases, all the VIPs for the VS are automatically populated in the DNS. It is recommended to configure DNS with consistent hashing algorithm to minimize cross-AZ traffic (AWS charges extra for inter-AZ traffic).

Server Selection

Any of Avi Vantage’s load balancing algorithms are available for server selection. In the current release, Avi Vantage does not automatically localize traffic on a VIP to the pool servers in the same AZ. This enhancement will be added in a future release.

Operational Status

Each individual VIP generates an event when it is UP/DOWN; this information can be used to determine the health of the VIP. Starting with 17.1.2, when a VIP is down, Avi Vantage automatically withdraws that VIP from DNS (be it Avi DNS or Route 53). When the VIP is up again, the DNS is updated automatically as well.

VS oper_status VIP oper_status
down if no VIP is UP
up if any of the VIPs are UP

In the virtual service list shown below, the IP addresses of the member VIPs are revealed.

Virtual service list

Virtual service health on a per-VIP basis can be viewed in the virtual service’s submenu, as shown below.

Virtual service submenu

Clicking on the Scale Out, Scale In, or Migrate button appearing in the above display results in windows with pulldown menus that enable selection of a particular VIP to be scaled or migrated.

Virtual service VIP scaleout

Virtual service VIP scalein

Virtual service VIP migrate

Creating a Multi-VIP VS in the UI

The user can use the Multi-AZ feature by specifying more than one VIP in the list within the VIP Address section of the Settings tab of the VS editor. Two VIPs are selected in the example below by specifying two networks from which they will be auto-allocated. In addition, its FQDN needs to be registered with Route 53.

VS editor shows multi-VIP-related settings