HAProxy Enterprise Documentation 1.7r1

Peers

The peers section enables the replication of stick table data between two or more HAProxy Enterprise instances.

peers mycluster
   # peers list

This feature works well for one-way replication of data because when the data replicates to the peer, it overwrites existing data on that peer. This makes it ideal for an active-standby cluster where the active instance pushes data to the standby instance.

In an active-active cluster where both instances receive traffic, use the Stick Table Aggregator module to combine the data captured by all nodes in the cluster.

Configure peers

Add one or more peer lines to your peers section. Each one identifies an instance that takes part in the synchronization. One of the peer lines must be the local host:

peers mycluster
   # local host, active instance
   peer loadbalancer1 192.168.1.10:10000

   # standby instance
   peer loadbalancer2 192.168.1.11:10000

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 loadbalancer1 192.168.1.10:10000
   peer loadbalancer2 192.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 local 127.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-1.7/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

Dynamic-update