Re: Persistence based on a server id url param

From: Willy Tarreau <w#1wt.eu>
Date: Tue, 2 Jun 2009 09:32:20 +0200


Hi Ryan,

On Mon, Jun 01, 2009 at 12:22:57PM -0700, Ryan Schlesinger wrote:
> I've got haproxy set up (with 2 frontends) to load balance a php app
> which works great. However, we're using a java uploader applet that
> doesn't appear to handle cookies. It would be simple for me to have the
> uploader use a URL with the server id in it (just like we're already
> doing with the session id) but I don't see any way to get haproxy to
> treat that parameter as the actual server id. Using hashing is not an
> option as changing the number of running application servers is a normal
> occurrence for us. I also can't use the appsession directive as the
> haproxy session id cache isn't shared between the two frontends (both
> running an instance of haproxy). Can this be done with ACLs and I'm
> missing it?

You could very well use ACLs to match your URL parameter in the frontend and switch to either backend 1 or backend 2 depending on the value.

Alternatively, you could hash the URL parameter (balance url_param) but it would not necessarily be easy for your application to generate an URL param which will hash back to the same server. So I think that the ACL method is the most appropriate for your case.

Basically you'd do that :

frontend

	acl srv1 url_sub SERVERID=1
	acl srv2 url_sub SERVERID=2
	acl srv1_up nbsrv(bck1) gt 0
	acl srv2_up nbsrv(bck2) gt 0
	use_backend bck1 if srv1_up srv1
	use_backend bck2 if srv2_up srv2
	default_backend bck_lb

backend bck_lb
	# Perform load-balancing. Servers state is tracked
	# from other backends.
	balance roundrobin
	server srv1 1.1.1.1 track bck1/srv1
	server srv2 1.1.1.2 track bck2/srv2
	...

backend bck1
	balance roundrobin
	server srv1 1.1.1.1 check

backend bck2
	balance roundrobin
	server srv2 1.1.1.2 check

That's just a guideline, but I think you should manage to get it working based on that.

Regards,
Willy Received on 2009/06/02 09:32

This archive was generated by hypermail 2.2.0 : 2009/06/02 09:45 CEST