Peers
The peers
section enables the replication of stick table data between two or more HAProxy Enterprise nodes.
peers mycluster # peers list
This feature implements one-way replication of data. This makes it ideal for an active-standby cluster where the active node pushes data to the standby node. When the data replicates from the active node to the standby node, it overwrites existing data on the standby node.
For an active-active cluster, on the other hand, where both nodes receive traffic, use the Global Profiling Engine or the Stick Table Aggregator module (see Real-time Cluster-wide Tracking).
Configure peers
Add one or more peer
lines to your peers
section. Each one identifies a node that takes part in the synchronization. One of the peer
lines must be the local host:
peers mycluster # local host, active node peer
loadbalancer1192.168.1.10:10000 # standby node peerloadbalancer2192.168.1.11:10000
Ensure the host name specified in the peer
directive for the local host matches the name of the host as determined by one of the following methods, in order of precedence:
The
-L
argument specified in the command line used to start the load balancer process.The
localpeer
name specified in theglobal
section of the load balancer configuration.The host name returned by the
hostname
command. This is the default. The other methods are recommended.
Then, add a peers
attribute to your stick-table
directive to include that stick table in the synchronization. The attribute references the name of the peers
section you defined:
backend stick-table type ip size 1m expire 10s store http_req_rate(10s) peers mycluster
The names assigned to each peer
(e.g. loadbalancer1) must match that server's hostname so that HAProxy Enterprise can determine which peer is the local host. You must duplicate this configuration on each load balancer so the new active node can synchronize data in the opposite direction using the same list of hosts in the event of a failover.
You can also add stick table definitions directly to the peers
section, in which case you do not need to use the peers
attribute on the stick-table
. Then, reference the table as peers-section-name/table-name.
In the following example, we've added a stick table definition via the table
line to the peers
section and updated it to have the name sticktable1. We then reference it on the http-request track-sc0
and http-request deny
lines in the frontend:
peers mycluster peer
loadbalancer1192.168.1.10:10000 peerloadbalancer2192.168.1.11:10000 table sticktable1 type ip size 1m expire 10s store http_req_rate(10s) frontend www bind :80 http-request track-sc0 src table mycluster/sticktable1 http-request deny if { sc_http_req_rate(0,mycluster/sticktable1) gt 10 }
Persist data at reload
A useful side effect of using a peers
section is that HAProxy Enterprise will persist stick table data after a reload. This is because during a reload the old process connects to the new one and shares all of its stick table entries with it.
To use this feature only, you can define a peers
section with only the local host address:
peers mycluster peer
local127.0.0.1:10000
Without this, stick table data is lost during a reload.
Alternative syntax
Instead of writing peer
lines, you can use server
lines. This allows the same functionality of a server as seen in a backend
section, such as the ability to connect to the remote peer using SSL. You can also use a default-server
line to set defaults for the server lines that follow.
peers mycluster # peers will receive sync traffic over the bound port # optional: enable SSL bind :10000 ssl crt
/etc/hapee-2.4/certs/site.pem# define defaults for 'server' lines # e.g. 'ssl', peers will send sync traffic using SSL default-server ssl # do not set an IP address and port for the local peer server loadbalancer1 server loadbalancer2 192.168.1.11:10000
See also
Next up
Aggregations