Skip to main content

HAProxy Configuration with KeyDB

for reference here is a link to the HAproxy v1.8 configuration manual

HAproxy can be used here as a reverse proxy load balancer for high availability. The latest version has seamless reloads for when you are updating HAproxy with new or altered configs and will not effect your connections.

See the haproxy.cfg example for a traditional setup which will write to the master instance. With active-replica option where we have 2 masters the setup is similar however you may want to consider choosing balance as 'first' or defining one of the servers as 'backup'.

HAproxy performs health checks to decide where to direct traffic and maintains high availability. If you are looking to keep your load balancers highly available (redundant), consider using keepalived. You could also write your own heartbeat server to reassociate an aws elastic IP address when a server goes down. Keepalived seems very common though for HAproxy load balancer redundancy.

Performance If you are having performance issues consider increasing maxconn for the servers (backend) as well as in defaults and global sections. Believe the default is 2000. If you are still having performance issues check your cpu useage during high loads to find the bottleneck. HAproxy can run multiple threads and this may need to be configured.

global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
stats timeout 30s
user haproxy
group haproxy
daemon
# The lines below enable multithreading. This should correlate to number of threads available you want to use.
nbproc 1
nbthread 4
cpu-map auto:1/1-4 0-3
# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
# Default ciphers to use on SSL-enabled listening sockets.
# For more information, see ciphers(1SSL). This list is from:
# https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
# An alternative list with additional directives can be obtained from
# https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy
ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
ssl-default-bind-options no-sslv3
maxconn 40000
defaults
log global
mode http
option httplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
# Below is a common setup for HAproxy. In this example we are connecting to 2 instances with a shared port for keydb-cli
# Client connects to port 6380 and is redirected to one of the two nodes based on setup and checks.
#
# For active-replica support you will have 2 masters that are replicas of eachother with data syncing.
# No need for a sentinel node as there is no replica that needs to be promoted to master.
# HAproxy will check if one instance goes down and write to the other node. This is done with the health checks
# Default config for balance is roundrobin. If you have preference for which server is primary, you can place the
# word "backup" beside the server ip address. That way HA will send traffic to 'not-backup' instance unless it is unreachable.
# You can also consider adding weights to the end of the server line. Weights are expressed as "weight 50%" combining to 100% or otherwise between 1 and 256 if no % sign
# Choosing "balance first" will use the first connected instance and only start using the second if maxconn is exceeded.
# If you have a password you will have to include it here and set the same for both nodes.
# Note that in a common master-replica setup you will "expect string role:master" to validate you are only sending traffic to the healthy master
# With Active-rep, you will "expect string role: active-replica" as that is the role when in active-rep mode. Understanding this concept of getting data and
# health checking you can probe for other info if needed.
listen mykeydb
bind *:6380
maxconn 40000
mode tcp
balance first
option tcplog
option tcp-check
#uncomment these lines if you have basic auth
#tcp-check send AUTH\ yourpassword\r\n
#tcp-check expect string +OK
tcp-check send PING\r\n
tcp-check expect string +PONG
tcp-check send info\ replication\r\n
tcp-check expect string role: master
tcp-check send QUIT\r\n
tcp-check expect string +OK
server keydb3 172.19.0.3:6379 maxconn 20000 check inter 1s
server keydb2 172.19.0.2:6379 maxconn 20000 check inter 1s
# Sending PING is one health check to make sure server is active. Retrieving the replication info is to find if the node is
# a master. If not master then don't write to it. This prevents trying to write to a replica instance.
# The QUIT command prevents unwanted logging info every time this is run
# A common master-replica HAproxy setup does not need to include a "balance" option or "backup" as only the master
# will see incoming traffic (through checks). If you have sentinel nodes they will automatically promote the replica to master at which
# time the checks will redirect traffic there.