The Good ol’ Days
Traffic steering by geographic area becomes increasingly important as a company’s online presence strengthens. For many years customers on the Dyn platform have used Traffic Manager (TM) to accomplish this, which will not only steer traffic, but also monitor endpoints based on health rules from their configuration to enable cloud based failover and high availability.
In the summer of 2012, our incredible engineering team released Traffic Director (TD), which can be thought of as Traffic Manager 2.0. While keeping with the cloud based Global Load Balancing (GLB) roots, Traffic Director allows for geographic steering and monitoring, but also allows for greater granularity and accuracy in responses. This is accomplished based on a few fundamental improvements.
The most major revision is the way in which Traffic Director makes decisions. Traffic Manager uses the Dyn anycast network itself to determine location. This means that the nearest Dyn Point of Presence (PoP) from a network topology sense which resolves the query is used to decide which record to serve based on preset regions. So if you hit LON, you’re probably in Western Europe; if you hit LAX you’re probably in Western North America. Traffic Director, on the other hand, uses the location of the recursive servers subnet itself. Why does that matter? Well recursives go funny places, we commonly see Korean recursives hitting our Seattle PoP, though users should clearly be given an APAC focused endpoint. By using the recursive location, we can achieve greater accuracy and granularity in handing out the right response for the user.This granularity can even be taken a step further with Traffic Director, with an optional integration of EDNS0 Client Subnet (ECS). ECS allows TD to return the geolocation of the requesting client’s subnet, instead of the recursive server’s subnet, for ever further accuracy.
There are many other benefits of Traffic Director, such as being able to build the service outside of a production zone before testing, use of multiple record types such as ALIAS records for performing CNAME at the apex or SRV to enable geo-aware Voice Over IP (VOIP), custom response pools, cascading failover, service duplication, and monitoring location preferences, just to name a few.
Now, the meat and potatoes: making the switch from Traffic Manager to Traffic Director swiftly, and without interruption of service. First the prep work. You will want to talk to your friendly Dyn Account Manager to upgrade Traffic Manager to Traffic Director within your contract. Prep work complete, we face two scenarios. If A-Records are being used for traditional GSLB, just follow the below steps to make the change. In the case that CNAMEs are being used for perhaps Cloud Hosting or CDN Management, just follow along until step 2 and contact Dyn’s Technical Support Team who will walk through the assist with the rest.
Step 1: Build the Traffic Director for your liking. To learn more about Traffic Director configurations, reach out to our Technical Support Team, or read our help documentation here: https://help.dyn.com/traffic-director/. Don’t forget to test the service! You can even attach TD to a new host, send it some queries, then unattach to proceed with production. Nifty right?
Step 2: After you’re satisfied with the Traffic Director configuration and testing, it is time to add the Traffic Director on top of the Traffic Manager. The Traffic Director will automatically take precedence in serving queries over the Traffic Manager. Read up on our help page here for full steps: https://help.dyn.com/attaching-a-node/’
First, open up the service controls within the Traffic Director, then, select Attach Node.
From here, chose the zone where the Traffic Director should sit. This should be the same zone where the Traffic Manager exists. Next, select the node that the Traffic Manager currently exists on.
Publish the changes to make everything live.
Step 3: The final phase is to remove the Traffic Manager. Wait at least 24 hours before completing this step, to ensure that cache has expired. Once this time has gone by, you may remove the Traffic Manager. First, navigate into the Traffic Manager service, and select Delete Service at the top of the screen.
Once this has been done, a confirmation screen will appear, where delete should be selected to remove the service.
Go, Go, Go!
Continuing to use Traffic Manager is certainly appealing, considering it’s already implemented. However, keep in mind all the benefits of Traffic Director. Need I mention cascading failover, ALIAS, or edns0-client-subnet capabilities? DNS changes don’t have to be scary. If you’re in the position to switch from Traffic Manager to Traffic Director, luckily most of the heavy lifting has been done! So, what are you waiting for? Get started today!