HAProxy Configuration

Internal

• HAProxy

Overview

If installed with yum, the default configuration file is deployed in /etc/haproxy/haproxy.cfg and the systemd configuration file in /etc/sysconfig/haproxy.

Example

The following example proxies HTTPS connections by passing them directly to the backend.

#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
    maxconn     20000
    log         127.0.0.1:514 local2
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    user        haproxy
    group       haproxy
    daemon

    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats

#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
#    option http-server-close
#    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          300s
    timeout server          300s
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 20000

listen stats :9000
    mode http
    stats enable
    stats uri /

frontend  atomic-openshift-api
    bind *:443
    mode tcp
    option tcplog
    default_backend atomic-openshift-api

backend atomic-openshift-api
    mode tcp
    balance source
    server      master1 192.168.122.13:443 check
    server      master2 192.168.122.14:443 check
    server      master3 192.168.122.15:443 check

Dependency on Other Services

Under some circumstances, HAProxy need other services to start before it starts, so it can rely on them. For example, if a local DNS server resolves the names referred from HAProxy configuration file, the named service must start before HAProxy. This is configured in the HAProxy's unit file /usr/lib/systemd/system/haproxy.service:

Requires=named.service
After=syslog.target network.target named.service

More details: Declaring a Dependency on a Service.

Logging Configuration

HAProxy logging concepts:

HAProxy Concepts - Logging

Logging configuration consists of the following steps:

Add the following to the "global" section of the configuration file:

log 127.0.0.1:514 local2

and then add the following to each "defaults" section or to each frontend and backend section:

log global

Then make sure the local syslogd does listen to the UDP traffic. For details on how to do this for rsyslogd, see:

Enable rsyslogd to Listen for UDP Traffic

Configure HAProxy to Log into a File

Assuming that logging was configured as described in the previous section, configure local2 events to go to the /var/log/haproxy.log file. Add the following line in /etc/rsyslog.conf:

local2.*  /var/log/haproxy.log

SSL Configuration

HAProxy SSL Pass-Through Configuration

Subjects

• HAProxy Routing by Domain Name

Configuration Reference

Options

tcplog

Logging is set to tcp instead of the default http.

ssl-hello-chk

A health check that verifies the the connection and its ability to handle SSL (SSLv3 specifically) connections.

defaults

mode

Possible values:

tcp

Used to pass secure connections off to a backend server without encrypting it.

balance

http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4-balance

Specifies the algorithm used to select a server when doing load balancing. This only applies when no persistence information is available, or when a connection is redispatched to another server. Possible values:

roundrobin

Each server is used in turns, according to their weights. This is the smoothest and fairest algorithm when the server's processing time remains equally distributed. This algorithm is dynamic, which means that server weights may be adjusted on the fly for slow starts for instance. It is limited by design to 4095 active servers per backend.

source

The source IP address is hashed and divided by the total weight of the running servers to designate which server will receive the request. This ensures that the same client IP address will always reach the same server as long as no server goes down or up. If the hash result changes due to the number of running servers changing, many clients will be directed to a different server. This algorithm is generally used in TCP mode where no cookie may be inserted. It may also be used on the Internet to provide a best-effort stickiness to clients which refuse session cookies. This algorithm is static by default, which means that changing a server's weight on the fly will have no effect, but this can be changed using "hash-type".