Although it's not the most elegant or even dynamic way of adding backends, I would approach this by defining the backends in a separate VCL and include it in default.vcl
using
include "backend.vcl";
Where you define your backends and a director. For example
probe healthcheck {
.url = "/online";
.interval = 15s;
.timeout = 0.3 s;
.window = 3;
.threshold = 1;
.initial = 1;
}
backend web1 {
.host = "10.1.2.1";
.port = "80";
.connect_timeout = 300s;
.first_byte_timeout = 5000s;
.between_bytes_timeout = 300s;
.probe = healthcheck;
}
director backendpool round-robin {
{ .backend = web1; }
}
And use the backendpool
as the backend. Then using shell scripting, ssh, a custom daemon or which ever method suits your needs best update the backend.vcl
by adding backends and issue a reload for Varnish.
The problem with this approach is that Varnish doesn't actually remove the backends that have been removed from the backend.vcl
. Even though they are not used, Varnish will keep probing them. This may lead to unexpected behaviour in the long run. At least the results of the backend health probes can get confusing if backend names are re-used. For example after renaming the web1
backend in the above example a couple of times and then changing its host to an invalid one, here are the Backend_health
polling results after reverting back to the above configuration with only a valid web1
backend defined.
0 Backend_health - web1 Still healthy 4--X-RH 3 1 3 0.001141 0.001055 HTTP/1.1 200 OK
0 Backend_health - web1 Still sick ------- 0 1 3 0.000000 0.000000
0 Backend_health - web2 Still healthy 4--X-RH 3 1 3 0.001061 0.001111 HTTP/1.1 200 OK
0 Backend_health - web3 Still healthy 4--X-RH 3 1 3 0.001007 0.001021 HTTP/1.1 200 OK
There is a patch for more granular backend handling for Varnish 2.1, but to my knowledge it is not available for Varnish 3.