X

Best Practices from Oracle Development's A‑Team

Manual fail-over is the past (Traffic Management Steering Policies)

Kiran Thakkar
Consulting Solutions Architect

Overview

Cloud has fueled business growth like no other technology in the past. Opening a new data center or starting a new business on the web is easier than ever before. While that has helped companies, it has also strengthened competition. User experience is of paramount importance. Businesses are going global, and they are using the internet as the growth engine. The ability of companies to serve their users better determines whether or not they are successful. One of the critical factors is to be able to serve users data from where they are. If the business has to serve a user from the APAC region from a service running in NA, it can lead to poor user experience. As we say, the world has become smaller. Even if a business is mostly regional, for example, a bank in the US, it cannot assume that its users will access the service/application from the US. A business traveler might require banking services from India, and the business/bank has to be able to serve that user with a reasonably good user experience.

To enable those business use cases, OCI released a new service as part of its DNS offering, Traffic Management Steering Policies. It allows businesses to configure policies to serve intelligent responses to DNS queries.

Depending on the user's geolocation or depending on load profile in a given region or depending on the IP prefix of the source IP address, return different answers to the DNS query for the application.

Components of a steering policy

Steering policy

It is a framework to define traffic management behavior for the given zones. It contains rules that help serve DNS requests. There are five traffic steering policies supported as below. The response, however, is driven by the rules defined for the policy.

  1. Load Balancer: (Global Server Load Balancing) Round-robin load balancing can be used to distribute traffic among multiple servers to optimize performance. Traffic can be split evenly among endpoints or weighted via ratio assignment.
  2. Failover: It's easy to set up a simple Active-Active failover between two public assets. The OCI will monitor the primary endpoint (via Oracle Health Checks) and reroute all traffic to a failover location if the primary endpoint is unresponsive.
  3. Geolocation Steering: Traffic Steering policies can also route traffic based on the source of the query. Geolocation Steering dynamically routes requests to the appropriate Response Pool based on the physical location of the originating request.
  4. ASN Steering: Dynamically routes traffic requests based on the originating ASN
  5. IP Prefix Steering: Dynamically routes traffic requests based on originating IP prefix (e.g., 172.16.1.0/24)

DNS zone Attachment

You can attach a steering policy to the DNS zone. An attachment of a steering policy to a zone occludes all records at its domain for the application sub-domain. You typically attach a policy to a zone for a specific sub-domain. A domain can have only one attachment for every sub-domain. For example, you cannot have two traffic steering policies for the application subdomain in the example.com DNS domain.

Steering policy rules

Rules are the guidelines for steering policy. For example, in a load balancer steering policy, should the traffic be spread equally between available servers, or only 10% of the traffic should be sent to a server is determined by the rules defined in the policy.

DNS query answers

Answers contain the DNS record data and metadata to be processed in a steering policy for a given condition.

Health check

The health check is an essential aspect of traffic steering policy. For example, for a failover traffic steering policy, when should DNS failover to secondary instance happen. Failover for US users should occur if the service is not accessible only from the US vantage point. If the service, for example, is not available from the APAC region, that should not trigger a failover to the DR site or region.

The meat of the post

Let's get to the part that you all are waiting for. How and where do I use traffic steering policies? Below are some examples of traffic steering policy.

Cloud Migration/Canary testing

The reason I combine cloud migration and canary testing in one topic is that the implementation is similar. In both cases, you want to either test a new feature/functionality added in the product/application or test a new data center/site to run the application. You deploy the application in a new data center or add a feature in an application running in an existing data center and start routing 10% of total traffic to the new site. You take user feedback, and if the feedback is positive, if there are no issues, then you start routing more traffic. You can use a traffic steering policy to implement the use case.

Load Balancing and Failover between multiple Active sites/regions

If there are numerous Active/Active data centers/regions, you can use steering policy to route a percentage of the traffic to a specific region. Or you can route traffic to the primary site and in case the primary site is not available, then route traffic to the secondary site. You can use health checks to determine if the site is available/healthy. 

 

Zero Rating Services

Conditional steering can be based on the originating enterprise, mobile operator, or other communications provider. Preferred ASNs can be directed to free resources while all other traffic can be directed to paid resources. Similar to ASN, you can use IP prefix or IP range as well to route traffic a specific resource. IP prefix can be used to segregate Internal vs. External users and route traffic accordingly to either the Internal portal or an external portal.

Layers of steering policies

The use case that I want to focus on is where you create layers of steering policies. Create steering policies for every region that implements DR or HA between data centers in a given region and a steering policy to steer users from a region to service instance in that respective region.

Regional steering policy

You create a region-specific steering policy to implement HA or DR between data centers in the region. In my example, I will create steering policies for the US and the EU regions. The difference between regional policies and global policy is, the regional policy creates DNS A record. In contrast, the global policy will use A records created by regional policy and will create CNAME records. I have highlighted that in regional and global policy screenshots. 

US region policy:

EU region policy:

 

Global Geo steering policy

Global steering policy is needed to route users from a region to service instance in that respective region.

Conclusion

Traffic steering policy is a vital feature for building resilient applications and services. But wait, don't forget security. Remember, I talked about the Web Application Firewall (WAF). Make sure you use WAF between regional steering policy and Load Balancer. With region specific steering policies, you can enforce different security policies for different regions using WAF in every region. I know, I know, this is already too much to cover in one blog. I will talk more about using steering policy with WAF in my next blog. Until then, Good luck using traffic steering policies. 

Sources

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