Managing Public DNS records During a Recovery using OCI Full Stack DR

Create a traffic management steering policy with a custom load balancer hostname.

In my first blog, my load balancers in both regions didn't have any custom domain names, and in most of the customer cases, we do have custom URL names assigned to the LB. However, I decided to demonstrate how to handle the failover from the primary region to the secondary with OCI DNS management. In this solution, we assign one custom URL domain to both LBs in our primary and secondary DR regions.

Let's dive in. Navigate to the DNS management from the Networking resources and click on Traffic management steering policies.

Click on Create Traffic Management Steering Policy and fill out all the required items there.

Check the screenshots below.

Note: The load balancers with an A record was added to the first and second answer pools.

Note: 152.70.125.76 is the San Jose public load balancer IP address and 141.148.185.79 is the Phoenix public load balancer IP address.

Note: You must have an available public zone with your registered domain configured on OCI. Otherwise, you won't have any zone options available to choose from. 

Note: In my case, I configured "fsdr" as a subdomain/hostname for the "ateam-oracle.cloud" domain, where we already have the zone and required certificate configured inside the OCI.

Note: In the Pool priority configure section, San Jose LB (primary region) is first, and Phoenix LB is the second one (Phoenix is the DR region in this blog).

After I created a policy, I ran the “nslookup” command to see where my LB URL resolves.

As you see below, the server IP belongs to San Jose LB.

Execute the DR plan to validate the load balancer failover.

For testing the DR solution, I executed the DR plan once again and made the Phoenix region primary this time; as you see below, the LB URL this time was resolved with the public IP address of the Phoenix load balancer.

In the last step, I took a screenshot from the traffic steering policy details page; as you see below, the San Jose health check status is unhealthy because there is no compute instance available in a backend set server, and DNS policy failover the traffic to the second LB in Phoenix with healthy backend set server.

I hope you enjoyed it!