Thanks for everyone's input! Just managed to get my desired configuration working by going direct when the src_ip matches one of the other parents, and having the remap rules "doubled", as follows:
parent.config: # Bypass peers if the request came from a peer already dest_domain=. src_ip="10.21.14.25" go_direct=true dest_domain=. src_ip="10.21.14.4" go_direct=true # Otherwsie, send to our peers dest_domain=. scheme=http parent="10.21.14.25:8080;10.21.14.4:8080" round_robin=strict go_direct=true dest_domain=. scheme=https parent="10.21.14.25:8443;10.21.14.4:8443" round_robin=strict go_direct=true remap.config: map http://www.proxy.example.com http://www.example.com/ map http://www.example.com http://www.example.com/ Since I'm using Chef to build this, it was trivial to make different parent.confs for each node: # Bypass peers if the request came from a peer already <% @peers.each do |peer| -%> dest_domain=. src_ip="<%= peer %>" go_direct=true <% end -%> # Otherwsie, send to our peers dest_domain=. scheme=http parent="<%= @peers.map{|p| "#{p}:8080"}.join ";" -%>" round_robin=strict go_direct=true dest_domain=. scheme=https parent="<%= @peers.map{|p| "#{p}:8443"}.join ";" -%>" round_robin=strict go_direct=true Josh Gitlin Principal DevOps Engineer [email protected]<mailto:[email protected]> PINNACLE 21 www.pinnacle21.com On May 7, 2020, at 5:03 PM, John Rushford <[email protected]<mailto:[email protected]>> wrote: In 9.0 when the parent.config is loaded, the parents for each config line are examined to see if the fqdn/ip matches the host itself or is localhost, if so that host is marked as unavailable for use by ParentSelection and NextHopSelection so prevent looping. However if you need to use the the host and you're sure that you won't loop because the combination of remap rules and the matching parent.config will not cause any problem, you can disable the self detection by adding 'ignore_self_detect=true' in the parent.config line and the the host will allow itself to be used as a parent. 8.1 has the self detection markdown as well but the 'ignore_self_detect' flag is not available there but should be backported. On Thu, May 7, 2020 at 2:38 PM Leif Hedstrom <[email protected]<mailto:[email protected]>> wrote: > On May 7, 2020, at 2:21 PM, Miles Libbey > <[email protected]<mailto:[email protected]>> wrote: > > Unfortunately, 9 is neither released nor stable yet :/ Correct. Possibly someone can back port these changes to their 8.x tree (I know others have :-) ). > > 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) Right. That’s the point of this feature, one parent.config for the “cluster”, and magic happens. — Leif > > On Thu, May 7, 2020 at 12:53 PM Josh Gitlin > <[email protected]<mailto:[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]<mailto:[email protected]> >> >> PINNACLE 21 >> www.pinnacle21.com<http://www.pinnacle21.com/> >> >> On May 7, 2020, at 3:52 PM, Leif Hedstrom >> <[email protected]<mailto:[email protected]>> wrote: >> >> >> >> On May 7, 2020, at 1:05 PM, Josh Gitlin >> <[email protected]<mailto:[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]<mailto:[email protected]> >> >> PINNACLE 21 >> www.pinnacle21.com<http://www.pinnacle21.com/> >> >> On May 7, 2020, at 1:51 PM, Josh Gitlin >> <[email protected]<mailto:[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.proxy.example.com/> >> http://www.example.com/ >> map https://www.proxy.example.com<https://www.proxy.example.com/> >> https://www.example.com/ >> >> >> Proposed fix to my config: >> >> map http://www.proxy.example.com<http://www.proxy.example.com/> >> http://www.example.com/ >> map https://www.proxy.example.com<https://www.proxy.example.com/> >> https://www.example.com/ >> map http://www.example.com<http://www.example.com/> http://www.example.com/ >> map https://www.example.com<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]<mailto:[email protected]> >> >> PINNACLE 21 >> www.pinnacle21.com<http://www.pinnacle21.com/> >> >> >> >> -- John Rushford [email protected]<mailto:[email protected]>
