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