Unfortunately, 9 is neither released nor stable yet :/ Though we've not done it, I was thinking that you could use parent.config's "primary ring" to get the traffic to the peer, but, when down, sends it to itself through the secondary ring, and hitting its parent rule.
I'm also not entirely sure how the 9 feature works, but, I think the primary benefit is that you wouldn't have to generate different parent.config for each peer. (Whereas in my described version, peer1 would need peer2 in the parent list, and vice-versa for peer2. Both could have 127.0.0.1 as their secondary ring) On Thu, May 7, 2020 at 12:53 PM Josh Gitlin <[email protected]> wrote: > > Thanks Leif! I am on 8.0.7, so maybe I should switch to 9 > > Josh Gitlin > Principal DevOps Engineer > [email protected] > > PINNACLE 21 > www.pinnacle21.com > > On May 7, 2020, at 3:52 PM, Leif Hedstrom <[email protected]> wrote: > > > > On May 7, 2020, at 1:05 PM, Josh Gitlin <[email protected]> wrote: > > The more I dig into this, the more I realize I have gone horribly wrong > somewhere, as I seem to have just created an infinite parent proxy loop. So I > may need to RTFM again to fix this broken design! :) > > > > In ATS 9.x, there is a “self” detection mechanism for this exact purpose > (“cache cluster”). It prevents a box to parent a request that is hashing to > itself. > > — Leif > > https://github.com/apache/trafficserver/pull/5544 > > > Josh Gitlin > Principal DevOps Engineer > [email protected] > > PINNACLE 21 > www.pinnacle21.com > > On May 7, 2020, at 1:51 PM, Josh Gitlin <[email protected]> wrote: > > Hello, > > Apologies if this was covered in the docs or a previous message; I couldn't > find an answer in my search. > > I am having an issue with remapping and parent caching. I have two Apache > Traffic Server instances for HA, and each one has the other configured as its > parent cache. The goal being a shared cache, because the two instances are > behind a load balancer with leastconn distribution. > > I am seeing an issue where cache misses on server B get forwarded to server A > with the remapped URL and server A refuses to serve because it does not > recognize the URL in it's remap config. (Error "ERR_INVALID_URL") I know I > can resolve this by simply adding the original URL to the remap config, but > that felt like the wrong fix. > > Contents of remap.config now: > > map http://www.proxy.example.com http://www.example.com/ > map https://www.proxy.example.com https://www.example.com/ > > > Proposed fix to my config: > > map http://www.proxy.example.com http://www.example.com/ > map https://www.proxy.example.com https://www.example.com/ > map http://www.example.com http://www.example.com/ > map https://www.example.com https://www.example.com/ > > Is this the "right" way to fix this issue? The duplication feels like there > must be a better way... > > Josh Gitlin > Principal DevOps Engineer > [email protected] > > PINNACLE 21 > www.pinnacle21.com > > > >
