Hi Jeremy, On Wed, Mar 03, 2010 at 11:55:49PM -0700, Jeremy Hinegardner wrote: > Hi all, > > We're moving to a system where each of our customers will have a > separate xen server with just that customer's data and an instance of > the webapplication in it (multiple users/customer). Now we have the > issue of routing user sessions to the appropriate backend server after > they have authenticated. > > Assume that login/authentication will happen in a separate gateway > application and that when authenticated, the login app will populate > a lookup table with the user's session id as the key and the value is > the 10.x.x.x address of the customer's xen instance. > > What I would like to do is have HAproxy, or something, be able to check > the Cookie: header, extract the session id, lookup that session id > in the lookup table and route the request to the appropriate IP address.
Why wouldn't your gateway application simply set up the cookie value corresponding to the backend ? Haproxy would then simply perform persistence on it and it would work. > This also means that when we provision a new xen slice for a customer, > that results in a new backend. > > So far, nothing I have found is able to do something along these lines. > It looks to me like I'll have to do some sort of customization to > HAproxy, nginx or varnish to get the functionality that I'm looking > for. > > If I boil it down to HAproxy terms, I would want to have a single > frontend with dynamically create acls based upon data looked up in a > table written to by some other process. Then those acls would be used > to route HTTP traffic to backends, most likely dynamically created. If you want to have something like dynamic backends, it looks more like a proxy than a reverse proxy. > I have considered just generating a haproxy config with all the backends > necessary, but that does not help with mapping the session id's to the > backends at runtime. If you're OK with creating your backends first then creating rules on the fly to switch a user to a backend, one future solution might be to rely on the new stickiness framework to inject entries. For instance, we could say that cookie XXX is associated to server YYY. Injection would simply be performed on the stats socket in admin mode. > Thoughts? Am I just crazy thinking of this? No it's not crazy. However I still find it less intrusive to have the gateway assign the proper cookie to the user and let haproxy use that cookie to find the proper server. Regards, Willy
