This is an automated email from the ASF dual-hosted git repository. elsloo pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/trafficcontrol.git
commit 2dd9a0cdf1fa3f7262f8518b779e50c4e3c36804 Author: Rawlin Peters <[email protected]> AuthorDate: Mon Jun 8 14:18:30 2020 -0600 Fix up the docs, add changelog entry --- CHANGELOG.md | 1 + docs/source/admin/index.rst | 2 +- .../admin/{traffic_router/index.rst => traffic_router.rst} | 12 ++++++------ 3 files changed, 8 insertions(+), 7 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 572f3d0..7e35fec 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -17,6 +17,7 @@ The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/). - Traffic Portal: Added the ability to assign topologies to delivery services. - Traffic Portal: Added the ability to view all delivery services and cache groups associated with a topology. - Updated /servers/details to use multiple interfaces in API v3 +- Added [Edge Traffic Routing](https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_router.html#edge-traffic-routing) feature which allows Traffic Router to localize more DNS record types than just the routing name for DNS delivery services - Astats csv support - astats will now respond to `Accept: text/csv` and return a csv formatted stats list ### Fixed diff --git a/docs/source/admin/index.rst b/docs/source/admin/index.rst index af8b55a..8c5a889 100644 --- a/docs/source/admin/index.rst +++ b/docs/source/admin/index.rst @@ -39,7 +39,7 @@ Once everything is installed, you will need to configure the servers to talk to traffic_ops.rst traffic_portal/* traffic_monitor.rst - traffic_router/index.rst + traffic_router.rst traffic_router/migrationto2-3.rst traffic_stats.rst traffic_server.rst diff --git a/docs/source/admin/traffic_router/index.rst b/docs/source/admin/traffic_router.rst similarity index 99% rename from docs/source/admin/traffic_router/index.rst rename to docs/source/admin/traffic_router.rst index fd965f5..beee5c5 100644 --- a/docs/source/admin/traffic_router/index.rst +++ b/docs/source/admin/traffic_router.rst @@ -391,22 +391,22 @@ Localizing ``NS`` records reduces latency for the resolver, which, due to cachin Edge DNS Routing ---------------- -Edge DNS routing refers to the localization of ``NS`` records in Traffic Router. This can be turned on and off via the ``edge.dns.routing`` parameter; the number of records returned is controlled via ``edge.dns.limit`` and there is a hardcoded default limit of 4 when this feature is enabled. See :ref:`ccr-profile` documentation for parameter details. +Edge DNS routing refers to the localization of ``NS`` records in Traffic Router. This can be turned on and off via the ``edge.dns.routing`` parameter; the number of records returned is controlled via ``edge.dns.limit`` and there is a hardcoded default limit of 4 when this feature is enabled. See :ref:`tr-profile` documentation for parameter details. Edge HTTP Routing ----------------- -Edge HTTP routing refers to the localization of ``A`` and ``AAAA`` records that represent routing names for HTTP delivery services. This can be turned on and off via the ``edge.http.routing`` parameter; the number of records returned is controlled via ``edge.http.limit`` and there is a hardcoded default limit of 4 when this feature is enabled. The default or global limit can be overridden by modifying the ``maxDnsAnswers`` setting on the delivery service. See :ref:`ccr-profile` documenta [...] +Edge HTTP routing refers to the localization of ``A`` and ``AAAA`` records that represent routing names for HTTP delivery services. This can be turned on and off via the ``edge.http.routing`` parameter; the number of records returned is controlled via ``edge.http.limit`` and there is a hardcoded default limit of 4 when this feature is enabled. The default or global limit can be overridden by modifying the ``maxDnsAnswers`` setting on the delivery service. See :ref:`tr-profile` documentat [...] Edge Traffic Router Selection ----------------------------- Traffic Router performs localization on client requests in order to determine which Traffic Routers should service a given request. After localization, Traffic Router will perform a consistent hash on the incoming name and will use the value to refine Traffic Router selection. There are two main cases for Traffic Router selection: a localization hit, and a localization miss. Localization Hit: Consistent Hash (CH) -************************************** +"""""""""""""""""""""""""""""""""""""" When a client is localized, Traffic Router selects the nearest Traffic Router Location (cachegroup) based on proximity. Proximity is determined by using the latitude and longitude of the client, regardless of whether it is a coverage zone or geolocation hit, and the latitude and longitude specified on Traffic Router Locations. Once the location is identified, a consistent hash is performed on the incoming name and the list of Traffic Routers is ordered based upon the consistent hash. Onc [...] Localization Miss: Consistent Hash + Round Robin (CH + RR) -********************************************************** +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""" When a client cannot be localized, Traffic Router still needs to produce a list of Traffic Routers to service the request. Because the number of Traffic Routers in the CDN could far exceed the practical limits of what constitutes a "normal" sized answer, a selection algorithm is applied to select Traffic Routers. Much like the localization hit scenario, the incoming request name is consistent hashed and results size is limited by the same parameters. Because no client location is known, [...] For example, with four Traffic Router Locations each containing 10 Traffic Routers and a limit of 6, the algorithm would: @@ -419,10 +419,10 @@ For example, with four Traffic Router Locations each containing 10 Traffic Route Because the algorithm employs consistent hashing, the answers should be consistent as long as the topology remains the same. This approach can be thought of as the consistent hash round robin (CH + RR) selection process. Example Request Flow -******************** +"""""""""""""""""""" The following is an example of the request flow when a client requests the routing name for an example delivery service, ``tr.service.cdn.example.com``. The request flow assumes that the resolver is cold and has yet to build a local cache of lookups, meaning it has to walk the domain hierarchy asking for ``NS`` records until it reaches ``service.cdn.example.com``. This example starts after the resolver has determined which name servers are authoritative for ``cdn.example.com``. Note that [...] -.. figure:: images/edge_tr_example.png +.. figure:: traffic_router/images/edge_tr_example.png :scale: 30% :align: center :alt: Example Request Flow for Edge Traffic Routing
