With HAProxy situated in front of their servers, many people leverage it as a frontline component for enabling extra security and observability for their networks. HAProxy provides a way to monitor the number of TCP connections, the rate of HTTP requests, the number of application errors and the like, which you can use to detect anomalous behavior, enforce rate limits, and catch application-related problems early.
Behind the scenes, an in-memory storage called stick tables keeps track of this data. Stick tables associate a key, which is typically the client’s IP address, with counters. These counters represent any of the abovementioned signals, around which you can build custom policies in order to take action when a counter exceeds a threshold. For example, you might send a Too Many Requests error when a user’s request rate goes too high.
There’s just one potential problem. If you make changes to your HAProxy configuration file, you then need to reload HAProxy so that the changes take effect. However, a reload clears away all of your stick table data! The good news is that there is a simple way to preserve this data during a reload, which we’ll cover in this blog post.
Preserve stick table data with peers
Preserving stick table data comes down to defining peers in your configuration.
What are peers? When you operate two or more HAProxy instances for redundancy, you often need to synchronize stick table data between them. For example, in an active-standby setup, where one load balancer actively receives traffic while the other is on standby, you would want to synchronize them so that if the standby instance needs to take over, it has a copy of the data. Each load balancer instance that shares stick table data is called a peer.
You configure peers by adding a peers section to your HAProxy configuration.
As it happens, using a
peers section doubles as a way to preserve stick table data during a reload, and it works even if you operate only one load balancer.
First, add a
peers section to your configuration. For illustration purposes, let’s assume you have only one load balancer. You would list it like this:
peers section, each
peer line indicates a server participating in data synchronization. In this case, there’s only one, the current server. The first argument is the server’s hostname, which is garfield here. Then, the server’s IP address, which can be either a localhost address like 127.0.0.1 or the address at which other peers can access the server, such as 192.168.56.20. The load balancer listens at the designated port for incoming data, which is 10000 here.
It’s important that the first argument matches the server’s hostname. If that would be difficult to do, you can instead set the
localpeer directive in the global section of your configuration to use a different name, as shown below.
Next, add a
peers argument to your stick table declaration.
Your stick table will now be preserved during a reload. By reload, I mean this command:
Note that this will not work if you do a hard restart of HAProxy, such as:
To see data currently stored in a stick table, use the Runtime API’s show table command.
In this blog post, you learned how defining a
peers section in your configuration enables HAProxy to retain stick table data during a reload. This ensures that the policies you define for rate limiting and the like will continue to operate normally.
To learn more about stick tables, sign up for the on-demand webinar, Introduction to HAProxy Stick Tables.