Posted on 2010-09-28
Some time in the middle of the night before 2.1.0, I implemented a director that used the client IP to direct traffic. The goal was to direct the same machine to the same backend - cheap session stickyness. Took about an hour to hack up and an other to pretty up.
Some time during roughly the same night, PHK refactored all the director infrastructure and in the process implemented a client director and a hash director as a sort of side-job. PHK's version obviously entered trunk and mine never saw the light of day (possibly because it was December and there isn't much daylight to see here in December anyway). At least the duplicated effort wasn't significant.
We've kept that somewhat hidden, mostly because the actual code for the hash and client director is about a screenfull of text once the VCL-bits are taken care of. And it's such a small feature. Truth be told, they both live within the random director and are just special exceptions. The VCL syntax is the same, except now it's called a client director instead of random.
The first up, the client director, will use the ascii-representation of the client IP to pick a "random" backend. (see why it's the ascii representation here: http://varnish-cache.org/trac/browser/trunk/varnish-cache/bin/varnishd/cache_dir_random.c?rev=5304#L99 (http://varnish-cache.org/trac/browser/trunk/varnish-cache/bin/varnishd/cache_dir_random.c?rev=5304#L99))
There isn't much to say about it. Your VCL will be the same as if it was a random director. If the "canonical backend" for the client is sick, the regular random algorithm will be used to pick a backend from the healthy ones.
In Varnish 2.1.4 you will also get a "client.identifier" VCL variable that you can use to tell varnish what identifies this as a unique client. In theory, you could pass a cookie to it and avoid wondering what happens if an IP changes. If it is set, the client director will use that instead of the IP. The only problem I have come up with using that approach is bootstrapping.
He very first request a client makes will have no cookies, so no data can be passed to client.identifier. The backend will presumably set a session-cookie of some sort so the next request could use that session cookie, but that means the first and second request is likely to go to different backends, even if the following requests will all go to the same backend.
Typical load balancers solve this by just setting the cookie them self. I suspect that is what it will come to, and I also suspect that it will be a lot nicer to do that in Varnish 3.0.0 when vmods are in place which could easily deal with these sort of things without messing up your regular VCL...
But until then, try out the client director for normal IP's at least. The client director is available in 2.1.3 (I think it's even in 2.1.0, though I can't remember. Definitely not documented in 2.1.0, though).
http://www.varnish-cache.org/docs/trunk/reference/vcl.html#the-client-director (http://www.varnish-cache.org/docs/trunk/reference/vcl.html#the-client-director)
I'm very interested in your take on how to deal with sessions, if just basing it on IP is "close enough" and if you think the client director will be able to solve most session-stickyness scenarios.