Depending on your hardware you may like to configure more caches and separate concerns with varnish, but the load you are wanting to split is when you get a cache miss, as a cache hit comes straight out of memory.
Personally I have only done this with varnish 3, and varnish 4 configuration may be different, but if it is, I am sure it is even easier.
The first stage of setting up this hardware is determining all your back-ends; I suggest this be an include file if you have automated provisioning of servers because you could then add a line in this file, and start serving load from that server quite quickly.
Ensure that you add the .probe parameters for your backend; this sets up varnish to probe that backend to determine its health.
Here is a list of the parameters, and what they do.
- .url - This is the url to hit.
- .interval - How often to test the health.
- .timeout - How long till this server is considered timed out.
- .window - Works with threshold.
- .threshold - The number of successful requests per window the server needs to complete before the timeout to be considered alive.
You can set up the director based on round robin or client. Client will allow sticky sessions with one backend.
You may want to include the weight of each machine for whatever reason; the best place to see this is the varnish documentation. However, if you aren't keen on doing this yourself I have just learned that there is a varnish plus, where you can pay for a bunch of stuff and it seems like most of the work is done for you. So that may be worth looking into.
Hopefully this covers how to use varnish to quite quickly and simply set up a load balance; I believe my next blog will be about using varnish and the geoip MaxMind to guess where your users are from.
No comments:
Post a Comment