Forum Discussion
Ichnafi
Cirrostratus
CirrostratusLoadbalancing a 2-stage proxy environment - persistence problems
Hello fellow F5-experts,
My situation:
I try to loadbalance Web-Proxy traffic. In genenal it seems to work, but we've run into some problems relating to websites with weird session handling. I sket...
RaghavendraSY
Altostratus
AltostratusFor all cache servers best option is destination persistence (Sticky perssitence).
Please test in your environment and let us know the status.
Destination address affinity persistence You can optimize your server array with destination address affinity persistence. Destination address affinity persistence, also known as sticky persistence, directs requests for a certain destination IP address to the same server, regardless of which client made the request. This type of persistence provides the most benefits when load balancing caching servers. A caching server intercepts web requests and returns a cached web page if it is available. In order to improve the efficiency of the cache on these servers, it is necessary to send similar requests to the same server repeatedly. You can use the destination address affinity persistence type to cache a given web page on one server instead of on every server in an array. This saves the other servers from having to duplicate the web page in their cache, wasting memory.
IchnafiThank you very much for you answer!
Using destination address as persitence profile was also my 1st (..ok, lets be honest 3rd) go to. But it did not seem to work.
When I tcpdump the traffic from VS-B towards the Pool B members, source address is the node in pPoll A BUT destination address is a Pool B node and not the actual websites IP the user wants to open. The requested web address is "embedded" in the HTTP Connect string sent by the proxy in Pool A.
Maybe I should have written that in my question in the first place.
Sorry.
- RaghavendraSY
Ok. You configured Sticky persistence for both virtual servers?
- Ichnafi
VS-A has source_addr persistence, because here VS-A sees the real client IPs and can persist based on that info.
VS-B has none (only a hard wired via iRule for a certain website). Source_addr would is useless, because the VS-B only sees the two IPs of our proxies. If I choose source_addr, the traffic would only use 2 of the nodes in pool B. I want to use as many nodes in pool B as possible and persist on those connections based upon the real client IP. I thought of inserting a X-Forwared-For header in VS-A, so VS-B has something to base persistense on, but I really don't know how.
Btw. the proxies in Pool B seem to strip headers like "X-Forwared-For". So the header is not available in the HTTP_RESPONSE.
- Ichnafi
Updated original Post.
- Ichnafi
Updated again, with possible solution.