The latest cloud infrastructure announcements, technical solutions, and enterprise cloud insights.

  • April 9, 2019

Using Regional Subnets and Load Balancers to Support HA and Failover

Last month, Oracle Cloud Infrastructure launched regional subnets, a new construct that allows subnets to span multiple availability domains. But what does it mean for a subnet to be regional? In Oracle Cloud Infrastructure, subnets were originally designed to cover only one availability domain in a region, referred to as availability-domain-specific subnets. As such, the subnet's resources were required to reside in a single particular availability domain. Now, subnets can be regional, which means that its resources can reside in any availability domain in a region. You can choose the type of subnet when you create it. Regional subnets and any new or existing availability-domain-specific subnets can coexist in the same virtual cloud network (VCN).

Introducing Regional Private Load Balancers

In conjunction with the release of regional subnets, we've also enhanced our private load balancer service to bring customers regional high availability. Before regional subnets, private load balancers were redundant only within a single availability domain, and the load balancer's availability was subject to the ongoing availability of the availability domain where it was created. This enhancement allows private load balancers to be highly available across multiple availability domains, completely transparent to the customer.

The following diagrams, taken from the Oracle Cloud Infrastructure documentation, show the difference between how the availability-domain-specific load balancer works and how the new regional load balancer works. In the first diagram, the private subnet with the CIDR range of exists only in AD-2, and would therefore not be fault tolerant if AD-2 were to go completely offline. In the second diagram, that the same private subnet, deployed as a regional subnet, is available across all three availability domains. This configuration enables the load balancer's IP address to float between all three availability domains.

Notice the different outcome if a failure causes AD-2 to go offline. In the first diagram, the load balancer's IP address also goes offline and your workload likely stops receiving requests. However, if you're using a private regional load balancer, as in the second diagram, the private IP address can move or failover to a different availability domain and continue to serve requests. This functionality helps to increase the availability of your load balancers and provide additional stability to your workload.

Note: Public load balancers continue to be highly available in availability-domain-specific subnets under a different failover model. Those created on regional public subnets are now redundant in the same manner as described here.

Use Cases

This section outlines a couple of different scenarios in which regional subnets can enhance the availability of your workloads.

Scenario 1: Regional Private Load Balancer

When you deploy a regional load balancer, you must first have a regional subnet (you can't deploy a regional load balancer is an availability-domain-specific subnet).

Step 1: Create the Regional Subnet

The following screenshot shows that the default (recommended) option for subnet creation in the Oracle Cloud Infrastructure Console is now Regional. When you select this option, you don't select an availability domain for the subnet. These are the only differences between creating a regional subnet and an availability-domain-specific subnet.

When you deploy a regional subnet from Terraform, you no longer add the availability_domain attribute, as you would with an availability-domain-specific subnet. This is shown in the following screenshot:

Note: Removing this attribute in the Terraform code for an existing availability-domain-specific subnet initiates a destroy operation and does not succeed on any subnet that has any VNIC-attached resources.

We encourage you to try it. See a full Terraform sample to expedite your success.

Step 2: Create the Regional Load Balancer

Now that you've created the regional subnet for the load balancer, you can create the regional load balancer.

The following screenshot shows that the Subnet field now has a Regional (Recommended) section. Instead of selecting an availability-domain-specific subnet, you now select the new regional subnet.

When you perform this operation in Terraform, you don't need to modify your template. Simply ensure a regional subnet is selected, and the load balancer will be regional as well.

By following these steps, you can deploy a regional load balancer in a regional subnet. Building on this effort, let's continue to another common scenario that can benefit from regional subnets.

Scenario 2: IP Failover Across Instances in Different Availability Domains

In addition to load balancing, many other applications and clustering solutions use the concept of a virtual "floating" IP address failover. In these scenarios, a cluster of machines is typically connected via a heartbeat, and a failover mechanism causes the IP to move back and forth because of changes in the "active" node that clients use. Before regional subnets, during a failover operation you could move the virtual IP address to an instance only in the same subnet. Now you can move that private IP address to an instance in any of the availability domains.

This design allows your application to be redundant between availability domains with virtual IP failover. For an example of how you can move a virtual IP between two different instances in a cluster setup by using Pacemaker, Corosync, and Oracle Cloud Infrastructure, see the Automatic Virtual IP Failover on Oracle Cloud Infrastructure blog post.


This post introduced you to regional subnets and load balancers, and how they can enhance your failover architecture on Oracle Cloud Infrastructure. We encourage you to read more about regional subnets in the VCN documentation. Release notes detailing this product release are also available.

We hope you enjoyed this article. Remember, all Oracle Cloud Infrastructure tenants have enterprise-grade support services included free of charge, and customers can open a service request to access these services. If you want to share any feedback with the product team, send an email to feedback_oci_virtual_networking_us_grp@oracle.com.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha