Microsoft Azure supports availability zones based on high availability. The Avi Load Balancer supports multi-availability zones for the Microsoft Azure cloud. The Service Engines and application load balancers provisioned in Azure also use the new availability-zone-based HA. This section details the setup required to enable multi-availability zones in Microsoft Azure and Avi Load Balancer.

For complete information on availability zones in Azure, see the following links:

Configuration Setup For Microsoft Azure

On Microsoft Azure, ensure that the region selected supports the multi-availability zone feature. Currently, Avi Load Balancer supports SEs only across availability zones within a region.

Configuration Setup For Avi Load Balancer

Enable the use_enhanced_ha flag in the Azure cloud configuration in Avi Load Balancer. This flag cannot be enabled if the cloud has an already created SE or virtual service. The virtual service, pool creation configuration workflow remains the same. Azure allows subnets, ALBs, and public IPs to span across zones. So, the virtual service needs only one VIP that will be scaled out to SEs from different availability zones.

Support for Three Availability Zones for Microsoft Azure

Starting with release 21.1.1 of the Avi Load Balancer, support for three availability zones (AZs) per Service Engine group is provided, and option for selecting availability zones is made configurable. Prior to the release, the number of availability zones was set to 2 by default, and the value was not editable. By default, two AZs were available in the Azure configuration at the cloud level, and the SE could be created in either of the availability zones.

With the recent enhancement, SE can be created in any of the three availability zones as per the requirement. In case the zone is not supported in the region, an error appears while creating the SE.

Configuring Three Availability Zones

Navigate to Infrastructure > Cloud > Location & Network and enable the Use Azure's Enhanced HA Features option, as shown below. Select the availability zones as per the requirement.

Figure 1.

Use the use_enhanced_ha option available under the azure_configuration mode to configure the three availability zones as required for a Service Engine group. Following are the commands for configuring the AZs:

[admin:10-10-1-1]: > configure cloud Az1
[admin:10-10-1-1]: cloud> azure_configuration
[admin:10-10-1-1]: cloud:azure_configuration> use_enhanced_ha
Overwriting the previously entered value for use_enhanced_ha
[admin:10-10-1-1]: cloud:azure_configuration> availability_zones 1
[admin:10-10-1-1]: cloud:azure_configuration> availability_zones 2
[admin:10-10-1-1]: cloud:azure_configuration> availability_zones 3
[admin:10-10-1-1]: cloud:azure_configuration> save
[admin:10-10-1-1]: cloud> save

The following is the output after configuring three availability zones:

|   use_enhanced_ha            | True                                                                             |
|   use_managed_disks          | True                                                                             |
|   availability_zones[1]      | 1                                                                                |
|   availability_zones[2]      | 2                                                                                |
|   availability_zones[3]      | 3                                                                                |
|   use_standard_alb           | False
Note:

Ensure that the availability_zones configuration is exactly as the above. Adding incorrect values for availability_zones will result in SE creation failure.

Advanced Load Balancer Setup

Like basic ALB, the cloud connector creates one standard SKU internal ALB and one external ALB per SE group. Each virtual service has a single VIP and an optional public IP address. The Service Engine VMs are created in individual availability zones. Each virtual service is placed across at least two AZs. The cloud connector creating the standard SKU ALBs provides availability across the Azure AZs. The standard ALB requires Network Security Groups (NSG) to be explicitly configured to allow the traffic inflow for public IPs.

The scheme adopted for Network Security Group (NSG) creation for Azure is illustrated below:



Network Security Groups Setup

The cloud connector creates one NSG per cloud and associates it with each SE NIC created in that cloud. By default, NSG has the following rules configured:



These rules ensure that all inbound and outbound traffic to the virtual network is allowed. The Azure load balancer can then probe the VM, and the VM is able to access the internet.

In addition to these, when a public IP is configured, the cloud_connector adds one rule per public IP to this NSG. This allows inbound traffic from any source to the public IP:port configured on the virtual service. The priority of these rules start from 100.

Below is the sample NSG inbound rules post-configuration.

Azure supports up to 500 rules per NSG to accommodate the number of public IPs.

The following is the order of the setup:

  1. Creating NSG – One NSG is created per cloud when the first SE is created for the cloud.

  2. Associating NSG to NIC – When the Service Engine is created, the NSG is associated with the SE NIC at the time of creating the NIC. This ensures that the NIC comes up with the NSG.

  3. Creating NSG rule – When a virtual service with public IP is created, and an attach_ip call is issued to the cloud_connector, a rule for that public IP is configured in the NSG. The rule has all the ports (or range of ports) configured as part of the virtual service.

  4. Deleting NSG rule – When the public IP is removed, the corresponding NSG rule is removed from the NSG as part of the periodic garbage collection cycle.

  5. Deleting NSG– NSG is deleted when the cloud is deleted.