Do you have services or applications in the cloud that you want to start sending traffic to? Or a hybrid or multicloud scenario where you need to spread traffic between different cloud, cloud distribution networks (CDNs), or data centers, potentially in different geolocations? Oracle Cloud Infrastructure (OCI) Traffic Management allows you to create intelligent responses in domain name systems (DNS) to steer traffic based on a variety of conditions, including geolocation, autonomous system number (ASN) and prefix origin, weighted or round robin load balancing, active failover scenarios, or even a combination of those options. In this post, we cover some potential scenarios for steering DNS traffic for hybrid and cloud applications and explore some of the specific functionality within OCI DNS Traffic Management that enables these complex environments.
Load balancer weighting with Traffic Management
In this scenario, you have a workload or application in OCI, and you want to start sending a small amount of production traffic without fully committing all production traffic away from your current data center. Using weights within Traffic Management allows you to send a small portion of traffic to your new location while continuing to keep most of the traffic using the current production site.
This weighted load balancing policy allows you to mitigate risk by being able to control the amount of the critical production traffic sent to the new cloud environment. Using the Load Balancing template in OCI Traffic Management, you can configure a “weighted round robin” scenario where queries coming in against attached hostnames to your Traffic Management policy are predominantly directed to your current production location or data center. In the Traffic Management policy, you assign a high weight to this endpoint, while the endpoint representing your cloud environment is assigned a much lower weight, as shown in Figure 1. With this configuration both endpoints are weighted such that your current production location will be handed out most of the time, while the cloud endpoint will see a small amount of traffic.
A large benefit is that you can control the amount of traffic hitting your endpoints and adjust as needed, so you have the flexibility to slowly increase the amount of traffic the cloud endpoint sees by incrementing the weight assigned. This flexibility allows you to get to your desired traffic split between both locations, whether you’re doing a complete migration of traffic to the cloud or splitting traffic between multiple cloud or on-premises environments.
Figure 2 is an example of a traffic pattern in OCI Traffic Management using weights where the data center receives a large amount of traffic (weight of 99), while the cloud endpoint only sees a small amount traffic (weight of 1).
You can get more granular with weights if you want. You can define a number between 0–255 to determine how often a DNS response is served in relation to other responses. DNS responses with higher values are more likely to be served.
Geolocation steering with Traffic Management
In this second scenario, you want to push a small amount of traffic from a lower priority economic market before increasing the volume. Maybe you want to target CDNs to economic zones or performance strength areas. The geosteering capabilities of Traffic Management fit well here.
Rather than using weights, you can use the granularity of OCI Traffic Management geolocation rules to accomplish this goal. For example, you could use the geolocation steering template within Traffic Management where all DNS queries hitting the attached hostnames to your geosteering policy are served to your current on‑premises data center except for queries originating from some countries in the EU and all of Africa, which the Traffic Management policy then responds to with your cloud endpoint.
As you become more comfortable with traffic hitting your new cloud endpoint, you can slowly add more geographies to your cloud endpoint. This setup can also be an ideal way to run an active-active configuration in a hybrid model where you utilize both your data center and cloud environment or you want to target multiple CDNs based on geographic location.
Figure 3 shows an example of using the geosteering functionality of Traffic Management. This policy has two separate response pools representing a cloud and data center location. The rules in this example have DNS queries originating from France, Ireland, Italy, UK, and continental Africa sent to the cloud location, while queries from any other part of the world are sent to the data center endpoint.
The geosteering capabilities of Traffic Management allow you to define responses for large geographies down to the country level. In the US and Canada, the responses can even go down to state and province level. If you need even more granularity, you might want to consider using Traffic Managements ASN and prefix steering functionality.
Conclusion
OCI Traffic Management offers you a great deal of flexibility to steer public DNS traffic for many conditions that meet your desired use cases. Regardless of where your services are located across multiple cloud providers, data centers, or CDN providers, Traffic Management can monitor those locations for health and steer the based on numerous conditions.
To learn more about Traffic Management policies or getting started, visit the Traffic Management documentation. To learn more about OCI and the DNS offering, see Domain Name System (DNS). To get started implementing your DNS on Oracle Cloud Infrastructure, see the Public DNS documentation.
