This tutorial shows how to configure Varnish to handle interruptions to the Amazon S3 service gracefully. The mechanisms used are called retry and stale-if-error.
The retry functionality allows Varnish to retry backend requests with other backends if certain conditions are met, for example if Varnish fails to connect to a backend or if a backend returns a 5XX response status.
The conditions are configured in VCL, while the number of retries allowed per transaction is limited by the max_retries
parameter to varnishd
. By default, the max_retries
parameter allows four retries before giving up and propagating the failed backend request to the client.
sub vcl_backend_error {
# Retry backend requests when a transport error occurs.
return(retry);
}
sub vcl_backend_response {
# Retry backend requests when an undesireable HTTP response is received.
if (resp.status ~ '^5') {
# Retry backend responses with response status starting with 5 (meaning the 500-599 range).
return(retry);
}
}
Varnish Enterprise comes with functionality to revive stale objects from the cache in case the backend is unavailable or is unable to produce proper responses.
sub vcl_backend_response {
# In order to make it possible to revive stale objects, it is necessary to set a relatively high `keep` period.
# This is because it is only possible to revive stale objects that are not evicted from the cache.
set beresp.keep = 1y;
call stale_if_error;
}
sub vcl_backend_error {
call stale_if_error;
}
sub stale_if_error {
if (beresp.status >= 500 && stale.exists()) {
# Tune this value to match your traffic and caching patterns
stale.revive(20m, 1h);
stale.deliver();
return (abandon);
}
}
Refer to the stale module documentation for more information.
The configuration above can be expanded with more functionality, as covered by the other Varnish tutorials for Amazon S3.