Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
Poul-Henning Kamp
phk at phk.freebsd.dk
Sat Jan 16 10:59:58 CET 2010
In message <4c3149fb1001151733g73f7a5dfjc84342b9df7f078f at mail.gmail.com>, pub c
rawler writes:
>Varnish performs very well. Extending this to have a cluster
>functionality within Varnish I think just makes sense.
You can do some clever stuff with the hash director to distribute the
content over a cluster of varnishes:
varnish1 has:
backend webserver {...}
backend varnish2 {...}
backend varnish3 {...}
acl partner {
"varnish1 ip"
"varnish2 ip"
"varnish3 ip"
}
director h1 hash {
{ .backend webserver; .weight 1; }
{ .backend varnish2; .weight 1; }
{ .backend varnish3; .weight 1; }
}
sub vcl_fetch {
if (beresp.http.x-partner == "yes") {
set beresp.ttl = 0s;
unset beresp.http.x-partner;
}
}
sub vcl_deliver {
if (client.ip ~ partner) {
set resp.http.x-partner = yes;
}
}
On varnish2 you change the "h1" director to read:
director h1 hash {
{ .backend varnish1; .weight 1; }
{ .backend webserver; .weight 1; }
{ .backend varnish3; .weight 1; }
}
On varnish3:
director h1 hash {
{ .backend varnish1; .weight 1; }
{ .backend varnish2; .weight 1; }
{ .backend webserver; .weight 1; }
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the varnish-misc
mailing list