Back in March, we published a case study with Evernote on their use of our intelligent response solution, affectionately labeled “Traffic Director”, to migrate applications to the cloud. This piece is to consider some potential use cases on migration or managing hybrid environments, and explore some of the specific features and configure options within our intelligent response “Traffic Director” that enables our users to accomplish these complex migrations.
- Policies: Oracle Dyn’s Traffic Director policies are attached on a per hostname basis in the DNS zone – e.g. one for www.example.com, another for blog.example.com.
- Response Pools: for Traffic Director identify the groups of DNS answers (A records, CNAME etc.) that will be provided for DNS queries. There are also configuration considerations such as how many answers to hand out, overrides for the eligibility of an answer, and the behavior of the Response Pool as a whole in the event the minimum number of eligible answers unavailable.
- Rulesets: for Traffic Director identify geographic areas to describe a collective market the traffic pattern shall apply to.. Once established, the appropriate set of Response Pools can be applied to that market by order of preference. Multiple Response Pools can be identified to for each Ruleset so that in the event one Response Pool fails, the next Response Pool in line will take over to answer the DNS queries. A host name or a single IP address can be identified as the final response if all associated Response Pools fail.
- Weighting: The weight of the record determines how often it is served for a DNS query. The higher the weight, the more often this record is served over others of the same record-type with lower weights. A and AAAA records can have weights between 1 – 15. CNAME records can have weights between 1 – 255.
Leverage weighting within Traffic Director
OK, you have a workload or application configured in the “cloud” and you want to send it a small amount of traffic to it without fully committing all of your production traffic away from your current data center that you know is functional? Using weights within Traffic Director allows you to elegantly send a small slice of traffic to your new cloud location while continuing to keep the majority hitting the established data center. This certainly allows you to mitigate risk and allows for that critical testing of production traffic into the new cloud environment.
Using weights in Traffic Director you could simply configure a “weighted round robin” scenario where queries coming in for the hostname/s your Traffic Director policy is associated with are all predominantly directed to your current serving location (current data center), in the TD policy you would assign a high weight to this endpoint. The new endpoint you have just created (in this scenario the cloud) would be assigned a much lower weight (usually a 1). When your response pool that you have both endpoints weighted in answer DNS queries, your existing location will be handed out the majority of the time, while the new “cloud” endpoint you configured will see a small amount of traffic. The big benefit here is you are able to control the amount of traffic that is hitting your new location, and make adjustments as needed and slowly start to increase amount of traffic the new endpoint sees by incrementing the weight assigned to the that endpoint representing the new location.
Below is an example of a traffic pattern in Oracle Dyn’s Traffic Director using weights where the “data center” receives a large amount of traffic (weight of 99) while the “cloud” endpoint only will see a very small amount traffic (weight of 1).
Leverage Geo Steering with Traffic Director
Migrating to the cloud and wish to push a small amount of traffic from a lower priority economic market before increasing the volume, or you wish to target CDNs to economic zones or performance strength areas? Traffic Director’s geosteering capabilities fit very well.
Rather than using weighting, users can leverage our granular geo policies contained in the Traffic Director service to accomplish this use case. An example of this could be creating a policy within the Traffic Director service where all queries hitting the DNS hostname in question went to your current “on prem” data center, EXCEPT for queries originating from New Hampshire in the United States in which the Traffic Director policy would then answer with your cloud endpoint. As you become more comfortable with traffic hitting your new cloud endpoint you could slowly start to add more geographies your cloud endpoint is responsible for responding to.
Below is an example of this scenario of leveraging the geo steering functionality of Traffic Director. In this traffic policy I have configured 2 separate response pools with a single endpoint in each of them (cloud and datacenter). In my rulesets I have only selected DNS queries originating from New Hampshire to be sent to my new cloud location, while queries from any other part of the world hit my existing on premise endpoint. It is worth noting here with a little more consideration this would be an ideal way to run an active/active configuration in a hybrid model where you are leveraging both your data center and cloud environments.