Thanks Malcolm for your reply. That's give me a good insight how bigsite are running without the exact feature I was looking for.
If I understand well, I could define in HAProxy one sharda for each server I have. Like this my application can use appsession cookie to specify the server wanted. It's not clear if HAProxy can be configured to automatically redirect to any server of the big cluster if all the servers of the small sharda become unreachable. In my scenario, small sharda, would be one server and big cluster, would be all the servers. Sound like in both approach the application choose the sharda/server, to do this it still need to get the list of still available sharda/servers, how can we get it? Maybe HAProxy has or could have a simple HTTP request giving the updated list. Since most B2B web site use SSL, it would be nice that cookie and URL rewrite don't need to be used for continuous server stickiness but rely only on the SSL id after stickiness have changed. I mean not all browser support cookie and URL rewrite is a pain to be handled for all URLs showing up in the HTML. In other words, in any scenario where some mechanism is used to redirect to a specific server and SSL is present, the best implementation is to change the SSL ID "match table" instead of abandoning SSL ID stickiness for ever to a workaround like cookie or URL rewrite. So using your approach it seems I need from HAProxy: 1- Mechanism to change SSL ID server assignment, then the stickiness stay based on SSL ID for the rest of the session 2- When small cluster have no more live servers, it does failover to a "big/parent" cluster -----Original Message----- From: Malcolm Turnbull [mailto:[email protected]] Sent: Thursday, November 25, 2010 3:48 PM To: Sebastien Tardif Cc: [email protected] Subject: Re: How to achieve application driven load balancing scheme using HAProxy? On 25 November 2010 19:27, Sebastien Tardif <[email protected]> wrote: > > How to achieve application driven load balancing scheme using HAProxy? > > What I want to achieve is "user affinity between sessions" based on user login. So that, between http/s sessions, and even between days, user is more likely to reach the same server. > > Any idea how a server can re-stick http session to another server by setting something in the response that HAProxy will act on? > > Any comments? Sebastian, It sounds a bit overly complex to me, why not just implement sharding? i.e. 1) Every application server can handle the login page (no persistence required). 2) Login page once verified redirects to www.bigsite.com/sharda/ (or just sets an appsession cookie called 'sharda') or BOTH! 3) HAProxy reads the appsession cookie or URL and re-directs to a smaller cluster (sharda) could be anything such as all logins starting with 'a' 4) All servers in each shard use same database/storage/memchached to handle just the users starting with 'a' etc... Should give fairly unlimitted scaleability? I notice my googlemail client is doing it right now: "mail.google.com/a/loadbalancer.org" -- Regards, Malcolm Turnbull. Loadbalancer.org Ltd. Phone: +44 (0)870 443 8779 http://www.loadbalancer.org/
