When you are load balancing a service it is important to make sure that servers that are receiving the traffic are in good condition to respond. In this article we will address this topic with a couple of mechanisms that HAProxy provides.
HTTP health checks
In order to enable health checks for each server, at least the check keyword must be placed in the server or default-server lines.
But let’s talk about HAProxy default behavior. These checks will use the server’s IP and TCP port to perform the health check. The interval between two consecutive health checks will be two seconds and its maximum timeout will be the same value, so if there is no response in that time it will be considered an invalid check. It will consider a server as UP after performing two consecutive valid health checks and it will consider a server as DOWN after performing three consecutive invalid health checks. It will only read the first 16384 bytes of the response. All these parameters can be changed in your configuration.
Now, the interesting thing about HAProxy is that it can perform layer 7 health checks, which are a more accurate method when forwarding traffic to http servers. To enable the http check, just use the option httpchk directive within the backend block.
backend http_test mode http balance roundrobin option httpchk http-check expect status 200 server Server1 192.168.10.11:80 check server Server2 192.168.10.12:80 check
You can customize this check a little further, like this.
option httpchk HEAD / HTTP/1.1rnHost: www.test.netrnUser-Agent: haproxy_check http-check expect status 200
Here we are specifying to use the HEAD HTTP method to save us the HTTP body response, followed by the HTTP protocol and finally the HTTP header, that is a concatenated string in which every parameter is separated by ‘rn’ and every key/value by a backslash and a space. In this particular header we have set the host, which is needed to check a virtual host in the target web server, and also the user agent to be able to identify those requests in the logs easily.
By using the http-check expect directive we set a match rule to look for a valid response. Here we used the status keyword to only mark as valid http responses whose code is 200. We could also look for a string by using the string keyword, although this requires us to use a GET or POST HTTP method instead of HEAD.
There are quite a few options for tuning your configuration, but it’s not this article’s aim to explain this check mechanism options in depth. You can get further detail in the HAProxy documentation.
Slow start mode
Slow start mode limits and meter the traffic forwarded to a server that is just back online, and this is done on a progressive basis. That is, the server gets an uprising traffic amount as time goes by within a configured time window, it starts by receiving a 0% of the traffic and incrementing until 100% at the end. This allows you to add new servers without overwhelming them with a flood of requests.
Slow start is very useful for applications that depend on cache and need a warm-up period before being able to respond to requests with optimal performance, or applications that have a startup delay because they may need to load modules or even compile some elements to initialize (hello ASP .NET).
You can set the slowstart parameter at the server line within the backend block or at the default-server line, whether it is in the backend or defaults block. It could look like this.
backend https_test mode http balance roundrobin option httpchk HEAD / HTTP/1.1rnHost: www.test.netrnUser-Agent: haproxy_check http-check expect status 200 default-server check ssl verify none slowstart 4m server Server1 192.168.10.11:443 server Server2 192.168.10.12:443
It only accepts a value for time, which can use several time units: ms (default), s, m, h, etc.
It is important to take into consideration that this mode is not applied to servers when haproxy starts or has been reloaded after the configuration has been modified because a new server has been added. It only applies to servers which have been previously marked as failed.
And well, I hope this will do for any basic doubts you could have about haproxy health checks.
I hope you’ve enjoyed this post and I encourage you to check our blog for other posts that you might find helpful. Do not hesitate to contact us if you would like us to help you on your projects.
See you on the next post!