Re: originserver plus carp configuration?
Henrik Nordstrom wrote: On Thu, 7 Apr 2005, Joe Cooper wrote: CARP balances based on a hash of the destination URL, not client. Hmmm...that raises a different question: How does one address the issue of maintaining client stickiness? It doesn't. CARP is designed for routing requests to a cloud/array of parent proxy cache servers with minimal duplication of cache content. Nevermind. One shouldn't configure Squid while tired. ;-) Now that httpd accel hosts are cache_peers I can used cache_peer_access to make the distribution decisions...Don't know why I didn't think of that, as I've used it in the past for similar purposes. That said, http://devel.squid-cache.org/rproxy/backend.html#balance suggests that some mechanism for load balancing based on client exists in rproxy, though I don't see anything relevant in the configuration options. (This item is marked (done) in the todo list.)
Re: originserver plus carp configuration?
On Thu, 7 Apr 2005, Joe Cooper wrote: The whole configuration is working, except for load balancing. Without carp I always get FIRST_UP_PARENT/192.168.1.47. With carp I always get CARP/192.168.1.48, no matter what IP I'm coming from (and I tried a half dozen client IPs to be sure I wasn't just coincidentally always hashing to the same destination). CARP balances based on a hash of the destination URL, not client. You can get quite detailed tracing of the CARP hashing by enabling debug section 39,9, combined with the cachemgr carp section. Regards Henrik
Re: originserver plus carp configuration?
Thanks for the rapid response, Henrik. Henrik Nordstrom wrote: On Thu, 7 Apr 2005, Joe Cooper wrote: The whole configuration is working, except for load balancing. Without carp I always get FIRST_UP_PARENT/192.168.1.47. With carp I always get CARP/192.168.1.48, no matter what IP I'm coming from (and I tried a half dozen client IPs to be sure I wasn't just coincidentally always hashing to the same destination). CARP balances based on a hash of the destination URL, not client. Hmmm...that raises a different question: How does one address the issue of maintaining client stickiness? You can get quite detailed tracing of the CARP hashing by enabling debug section 39,9, combined with the cachemgr carp section. Excellent. Thanks for the tip.
Re: originserver plus carp configuration?
On Thu, 7 Apr 2005, Joe Cooper wrote: CARP balances based on a hash of the destination URL, not client. Hmmm...that raises a different question: How does one address the issue of maintaining client stickiness? It doesn't. CARP is designed for routing requests to a cloud/array of parent proxy cache servers with minimal duplication of cache content. doc/rfc/draft-vinod-carp-v1-03.txt it's positive properties are - Deterministic static forwarding path. The same URL always gets the same forwarding part while the configuration is the same. - Minimal cache distruption on changes. If a member server is added/removed from the array only a portion of the cache in proportion to the size/power of the added/removed server is affected by the change. - No peering traffic. Thanks to the deterministic static forwarding path. it's negative properties are - Static forwarding path. Can not easily adjust to dynamic changes in weights / server capacity. - Forwarding is based on a hash of the complete URL. No client or even destination persisance. Regards Henrik
