constellix background

When to Use Traffic Optimization or Regional Traffic Direction

April 17, 2018
DNS Provider Resource
Compare DNS Providers - Alternative Comparison Free Demo


Resources:

Subnet Mask Cheat SheetRecords Cheat SheetGeoDNS ExplainedFree Network TroubleshooterKnowledge BasePricing CalculatorLive CDN PerformanceVideo DemosOutage Prevention - CDN Outage - DDos Attack Prevention - DNS Outage


Categories:

BlogsNewsPress ReleasesIT NewsTutorials
Book a Free Demo →

Want DNS Freebies?

Give us your email and we'll send you the good stuff.

Thanks for joining our newsletter.
Oops! Something went wrong.
Enterprise DNS



Categories:

When it comes to DNS, there's nothing we love more - except DNS management. And maybe Secondary DNS. Or Failover. Even anomaly detection. Oh who are we kidding, if it's even remotely close to the topic of DNS, we got you covered!

Connect with
LinkedIn

Traffic Optimization vs Regional Traffic Direction

Since we launched our new traffic optimization service, ITO, we have received a lot of feedback from clients who want to know why they should use ITO over our traditional regional traffic director service. ITO is used to route users to the fastest responding server in their region. I bolded that for a reason. You really only want to use ITO when you have multiple endpoints in a region and you want users to be sent to the fastest one. If you use it on a global scale, with only one endpoint per region, you'll run into some problems. We'll elaborate on this in a minute. GTD (Global Traffic Director) splits up the world into five regions. Each region has its own zone file. So when a user wants the IP address of a domain, they will be answered by the zone file designated for their region. That means you can have different responses depending on the region. Now that you have a basic understanding of the two services, let's look at some use cases to illustrate the differences between the two and when you would want to use one over the over.Each numbered use case corresponds to a numbered flowchartin the diagram below.

GTD ITO use cases

#2

You have two data centers, each hosting a copy of your website. This could be a basic sort of CDN that is managed with DNS. Or you are expanding into a new market and want faster load times.

Goal:

You want users to be routed to the fastest responding data center.

Locations:

Seattle, WA USALondon, GB UK

How you would set this up with ITO pools:

  1. Create a pool and enable ITO.
  2. Make sure the monitoring region is set to World.
  3. Add the IP/hostnames for each data center.
  4. Create monitoring checks in Sonar for each data center. Choose one monitoring location in each region, ie: there are five regions so we might choose Sydney, AU; Tokyo, JP; London, GB; New York, NY; and Seattle, WA.
  5. Apply the check to the record pool. It should automatically populate the check name when you click the dropdown (if you entered the IP/hostname correctly).
  6. Choose the monitoring/routing policy. Always follow Sonar will add or remove an endpoint from the pool based on its health. Off on failure will not use that endpoint in the pool anymore if it is detected as down.
  7. Save the pool.
  8. Go to your domain and add the appropriate record. If you created an A record pool, create an A record, and so on.
  9. Enable pools.
  10. Add the pool you created.
  11. Save and commit your changes.

Benefits:

Users will always be routed to the fastest responding data center.

Disadvantages:

The average response times used to calculate which data center is the fastest is using a global average. This data is essentially irrelevant to the user because it is not specific enough to their location. Instead, we recommend only using ITO pools when you have more than one data center or server in a region. This way, all responses are optimized based on the region of the querying user.

#3

Same as before, we have two data centers: one in London and one in Seattle.

Goal:

You want users to be routed to the closest data center.

How you would set this up with GTD (Global Traffic Director):

  1. Enable the Global Traffic Director for your domain.
  2. Commit your changes. You will now see a default and five regional tabs. Any records you add to a region will be added to a region-specific zone file that will be used to answer any queries originating in that region.
  3. Now you will create two region-specific records; one for each region where you have a data center, ie: in US West you will create a record that points to your Seattle data center. You may also want to create a record for US East if you want all US traffic to be hitting the same data center. Could be helpful if you have region or language specific content.
  4. Optional: enable Failover in each of your region-specific records and add a second endpoint. This endpoint will only be used if the primary one is unavailable. You will need to create the appropriate Sonar monitoring checks for both endpoints.
  5. Create a World/Default record that will answer users not located in US East or Europe. Use whichever data center you think has the most capacity/fastest/etc.
  6. Commit your changes.

Benefits:

Users will be routed to a data center in their immediate region. In almost every case, this will also be the fastest responding data center. You also have backup data centers designated in the event that the primary is unreachable.

Disadvantages:

None.

#4

You have a large network with multiple servers in each region. Or you are building your own CDN with multiple web servers in each region. Or you want to manage a multi-CDN configuration.

Goal:

You want users to be routed to the fastest responding server in their immediate region.

Locations:

We’ll only use one region for this example, US East. Washington, DCChicago, IL

How you would set it up with ITO Pools:

  1. Create a pool and enable ITO. Set the region to US East.
  2. Enter the IP/hostnames of the servers in each location.
  3. Create Sonar monitoring checks for each location and select monitoring locations in the US East region.
  4. Apply the appropriate monitoring check to each location in the pool.
  5. Save the pool. Go to your domain and enable GTD (Global Traffic Director).
  6. Commit your changes. You will now see a default and five regional tabs. Any records you add to a region will be added to a region-specific zone file that will be used to answer any queries originating in that region.
  7. Create a record (A if you used an A record pool) in the US East region.
  8. Enabled pools and add the pool you created in step one.
  9. Optional: If you have multiple regions using ITO pools, you may want to enable pool failover. If your servers in US East are unavailable, you can failover the traffic to the US West or European pools.
  10. Create a default/World record that points to a pool or endpoint of your choosing. If a querying client does not match a region, they will be defaulted to this record.
  11. Save and commit your changes.

Advantages

Users are always routed to the fastest responding server in their region.

Disadvantages

None.

Priority DNS Security - image

Need better DNS?
We can help.

• 100% Uptime guarantee
• Configure with ease
• Prevent DDoS attacks
• Monitor your domains
• Optimize site traffic
• Enhance domain performance
• Free POC Account + Demo

BOOK FREE DEMO

Constellix DNS News

traffic optimization, regional traffic director, dns traffic, regional dns traffic

Sign up for industry news and insights. It'll be worth it.

Sign up for news and offers from Constellix and DNS Made Easy

Thanks for joining our newsletter.
Oops! Something went wrong.