Forum Discussion
Wouter_de_Bruin
Nimbostratus
NimbostratusPersistence from proxy servers
I have an interseting (For me anyway!) challenge:
We have 3 proxy servers which are used to access the internal websites of the company.
The websites in turn are run on 3 Webservers behind the proxies. This means that a client connection is set up to a proxy server (Load balanced) and from the proxy server it gets load balanced to one of the web servers.
On the web server VIP we have source address persistence and predictive load balancing set up. What sometimes happens is that after a reload of the web servers the persistence for all three proxies end up on one of the web servers. Obviously not a good thing, as you could imagine. No load balancing anymore.
Is there a way that I can create an I-rule to fix this persistence problem. I have thought of TCP source port persistence, but I don't know if this is a good idea.
Another one is cookie persistence, but I still need to convince the proxy administrators that they'll be receiving a cookie from the F-5.
All insights into how I can fix this will be really appreciated.
Wouter
3 Replies
- Well, unfortunately "source port persistence" is a misnomer: All connections from the same client will use a unique source port, so you can't accomplish session persistence across multiple connections by tracking the source port.
I could see that if there was at any point only one webserver up and continuous traffic through the proxies, all traffic would continue to persist to that server even after the others were brought online, regardless of LB method chosen.
You could persist on an existing cookie value or other persistent unique value that is present in each request, but for a proxy that might be a bit of a crap shoot.
Other than a different persistence scheme, I think your only option might be to clear some or all proxy server connections to the overloaded pool member after the servers are recycled, then new traffic should then re-distribute (Predictive LB method should be fine.)
You can use the bigpipe command at the command line or in the GUI console:
orbigpipe conn client delete
orbigpipe conn destination delete
To minimize the chances of overloading a single server, I'd recommend only recycling one at a time, then selectively deleting some persistence entries as above.bigpipe conn client destination delete
HTH
/deb - A few suggestions from my colleagues came up over lunch (yeah, I know, I never get a break!)
First one was to force the one pool member DOWN then back UP almost immediately, which would have the same effect as the 2nd bigpipe command above, but you could do it in the GUI.
Next was the revelation that we now have bigpipe commands specific to killing the persistence entries rather than the connections themselves:
orbigpipe persist node delete
orbigpipe persist pool node deletebigpipe persist all delete
HTH
/deb 
Wouter_de_BruinThanks for the advice.
Breaking persistence on the overloaded webserver is the way we solve it already. This is only temporary, however. I have found a cookie in the reply from the webserver to the proxy -> client. This cookie contains user-unique information which we will be using to persist with. This provides a much more granular persistence and eventually load balancing and this is what we were looking for.
As far as I am concerned; Problem solved!
Wouter de Bruin
