ocket8888 commented on code in PR #7302: URL: https://github.com/apache/trafficcontrol/pull/7302#discussion_r1095229331
########## docs/source/overview/traffic_monitor.rst: ########## @@ -56,3 +56,6 @@ Protocol Engagement ------------------- Short polling intervals of both the :term:`cache servers` and Traffic Monitor peers help to reduce customer impact of outages. It is not uncommon for a :term:`cache server` to be marked unavailable by Traffic Monitor - in fact, it is business as usual for many CDNs. Should a widely requested video asset cause a single :term:`cache server` to get close to its interface capacity, the Health Protocol will "kick in," and Traffic Monitor marks the :term:`cache server` as unavailable. New clients want to see the same asset, and now :ref:`tr-overview` will send these customers to another :term:`cache server` in the same :term:`Cache Group`. The load is now shared between the two :term:`cache servers`. As clients finish watching the asset on the overloaded :term:`cache server`, it will drop below the threshold and gets marked available again, and new clients will begin to be directed to it once more. It is less common for a :term:`Delivery Service` to be marked unavailable by Traffic Monito r. The :term:`Delivery Service` thresholds are usually used for overflow situations at extreme peaks to protect other :term:`Delivery Services` in the CDN from being impacted. +Handling Caches with same service IP Review Comment: Avoid using the word "cache" when you mean "cache server", it's harder to confuse the latter. Also, grammar and title casing: > "Handling Cache<del>s</del> <ins>Servers</ins> with <ins>the</ins> <del>s</del><ins>S</ins>ame <del>s</del><ins>S</ins>ervice IP" (you don't need to link the glossary term "cache servers" when it appears in headings, because that messes with heading anchors) ########## docs/source/overview/traffic_monitor.rst: ########## @@ -56,3 +56,6 @@ Protocol Engagement ------------------- Short polling intervals of both the :term:`cache servers` and Traffic Monitor peers help to reduce customer impact of outages. It is not uncommon for a :term:`cache server` to be marked unavailable by Traffic Monitor - in fact, it is business as usual for many CDNs. Should a widely requested video asset cause a single :term:`cache server` to get close to its interface capacity, the Health Protocol will "kick in," and Traffic Monitor marks the :term:`cache server` as unavailable. New clients want to see the same asset, and now :ref:`tr-overview` will send these customers to another :term:`cache server` in the same :term:`Cache Group`. The load is now shared between the two :term:`cache servers`. As clients finish watching the asset on the overloaded :term:`cache server`, it will drop below the threshold and gets marked available again, and new clients will begin to be directed to it once more. It is less common for a :term:`Delivery Service` to be marked unavailable by Traffic Monito r. The :term:`Delivery Service` thresholds are usually used for overflow situations at extreme peaks to protect other :term:`Delivery Services` in the CDN from being impacted. +Handling Caches with same service IP +------------------------------------ +Traffic Monitor is able to direct :term:`traffic router` to route traffic to groups of :term:`cache servers` with the same service IP address, but not to individual :term:`cache server` within that group. To monitor :term:`cache servers` within that group, HTTP :mailheader:`Keep-Alive` header is omitted with the health.polling.keepalive and stat.polling.keepalive Traffic Monitor :term:`profile` :term:`parameters` so that the Traffic Monitor source port changes for those connections and the Traffic Monitor can get to all the :term:`cache servers` within that group via `ECMP <https://en.wikipedia.org/wiki/Equal-cost_multi-path_routing>`(Equal Cost Multi Path). ECMP rules govern routing to destinations with equal cost. Changing the source port ensures all the routes to :term:`cache servers` within an ECMP group are taken. Then Traffic Monitor updates the responses using the :mailheader:`Via` header. In the event of :dfn:`Health Protocol` determining the overall health of one of the :te rm:`cache servers` in an anycast group by evaluating network throughput and load against values configured in :ref:`to-overview` to exceed their limit, it declares the whole groups as unhealthy. Review Comment: "traffic router" isn't in the glossary, but it should instead just be title-cased as "Traffic Router". Grammar: "...but not to individual :term:\`cache server\` within that group." -> "... but not to individual :term:\`cache server<ins>s</ins>\` within that group." (or "... but not to <ins>an </ins>individual :term:\`cache server\` within that group." If parameters `health.polling.keepalive` and/or `stat.polling.keepalive` have documentation, they should be links to it. If not, just monospace with double grave accents (or "back-ticks" - <kbd>\`</kbd>) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
