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.
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 health on a per-VIP basis can be viewed in the virtual service’s submenu, as shown below.
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.
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.
