HAProxy Enterprise Documentation 2.4r1

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 loadbalancer1 192.168.1.10:10000

   # standby node
   peer loadbalancer2 192.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:

  1. The -L argument specified in the command line used to start the load balancer process.

  2. The localpeer name specified in the global section of the load balancer configuration.

  3. 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 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-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