Configuration basics
Backends
A backend section defines a pool of servers to which the load balancer will route requests.
The following video is an overview of backends in an HAProxy configuration file and showcases several load balancing algorithms.
You can add as many backend sections as needed. Each backend keyword is followed by a label, such as web_servers, to differentiate it from others.
haproxybackend web_serversmode httpbalance roundrobinserver s1 192.168.1.25:80 checkserver s2 192.168.1.26:80 checkserver s3 192.168.1.27:80 check
haproxybackend web_serversmode httpbalance roundrobinserver s1 192.168.1.25:80 checkserver s2 192.168.1.26:80 checkserver s3 192.168.1.27:80 check
The label is mostly for readability, but it does come into play when referencing stick tables and categorizing traffic metrics. It should consist of only upper or lowercase letters, digits, dashes, underscores, dots, and colons.
Backend configuration example Jump to heading
The following example shows a pool of servers that are defined within the backend named web_servers. The server keyword identifies each server’s IP address and port, which the load balancer will use to send traffic to that server. The basic syntax of a server line includes a unique name, an IP address, and a port.
haproxyfrontend myfrontendmode httpbind :80default_backend web_serversbackend web_serversmode httpbalance roundrobinserver myfirstserver 192.168.1.25:80 checkserver mysecondserver 192.168.1.26:80 checkserver mythirdserver 192.168.1.27:80 check
haproxyfrontend myfrontendmode httpbind :80default_backend web_serversbackend web_serversmode httpbalance roundrobinserver myfirstserver 192.168.1.25:80 checkserver mysecondserver 192.168.1.26:80 checkserver mythirdserver 192.168.1.27:80 check
Define multiple backends Jump to heading
You can add multiple backend sections to service traffic for multiple websites or applications. In the configuration sample below, frontend foo_and_bar listens for all incoming HTTP requests and uses the use_backend directive to route traffic to either foo_servers or bar_servers, depending on the host HTTP header.
haproxyfrontend foo_and_barmode httpbind :80use_backend foo_servers if { req.hdr(host) -i foo.com }use_backend bar_servers if { req.hdr(host) -i bar.com }backend foo_serversmode httpbalance roundrobinserver foo1 192.168.1.25:80 checkserver foo2 192.168.1.26:80 checkserver foo3 192.168.1.27:80 checkbackend bar_serversmode httpbalance roundrobinserver bar1 192.168.1.35:80 checkserver bar2 192.168.1.36:80 checkserver bar3 192.168.1.37:80 check
haproxyfrontend foo_and_barmode httpbind :80use_backend foo_servers if { req.hdr(host) -i foo.com }use_backend bar_servers if { req.hdr(host) -i bar.com }backend foo_serversmode httpbalance roundrobinserver foo1 192.168.1.25:80 checkserver foo2 192.168.1.26:80 checkserver foo3 192.168.1.27:80 checkbackend bar_serversmode httpbalance roundrobinserver bar1 192.168.1.35:80 checkserver bar2 192.168.1.36:80 checkserver bar3 192.168.1.37:80 check
Change the load balancing algorithm Jump to heading
The load balancer selects a backend server for each request or connection based on the load balancing algorithm you choose. Add or change the balance directive in your backend to change the load balancing algorithm. By default, if you don’t specify an algorithm:
- In versions 3.3 and later, the load balancer selects two candidate servers at random (
balance random) and sends the request to whichever server is less loaded. - In versions 3.2 and earlier, requests are distributed across all backend servers in a rotating sequence while respecting the servers’ weights (
balance roundrobin).
In this example, we’ve set the balance directive to roundrobin:
haproxybackend web_serversmode httpbalance roundrobinserver s1 192.168.1.25:80 checkserver s2 192.168.1.26:80 checkserver s3 192.168.1.27:80 check
haproxybackend web_serversmode httpbalance roundrobinserver s1 192.168.1.25:80 checkserver s2 192.168.1.26:80 checkserver s3 192.168.1.27:80 check
Other load balancing algorithms, explained further in the sections below, include hash, first, leastconn, and more. See all the available load-balancing algorithms in HAProxy Configuration Manual’s balance.
roundrobin Jump to heading
Info
This is the default load balancing algorithm in versions 3.2 and earlier.
The roundrobin load balancing algorithm sends each new request to the next available server in the pool. By cycling through servers in order, it helps ensure that traffic is distributed evenly across all servers in the backend. Since the servers will receive requests in a predictable order, this can help with troubleshooting, as it’s easier to determine which server will receive the next request. This algorithm provides smooth and fair load balancing when backend servers have similar capacities and requests are short-lived and similar in duration. This predictable load distribution makes this algorithm a good choice for traditional web applications and APIs.
leastconn Jump to heading
When balance is set to leastconn, the server with the lowest number of connections receives the connection (request). Use this algorithm when you expect long-lived connections, such as for SQL databases, gRPC streams, LDAP, and other protocols that keep connections open for an extended period of time. This algorithm is not well suited for protocols that have short sessions, such as HTTP. It takes server weights and queued connections into account as well when choosing the best server.
random Jump to heading
Info
This is the default load balancing algorithm in versions 3.3 and later.
The random load balancing algorithm is a good choice for general-purpose load balancing. This algorithm implements the concept of the Power of Two Choices and provides efficient server selection that’s resilient to servers being added and removed frequently. It selects a server without having to analyze all servers, and since it will choose the least loaded of two randomly-chosen servers, it won’t select the most-loaded servers. This helps to smooth the distribution of requests across servers. This algorithm works particularly well with backends whose list of servers changes frequently, and it takes server weights into account when selecting the less-loaded server.
Tip
You can provide an additional argument to balance random called draws (balance random <draws>). Draws is an integer that determines how many servers will be selected as candidates. By default, the number of draws is two. We recommend you don’t change this value unless balance random 2 produces significantly uneven distribution across your servers. Increasing this value from 2 uses more CPU, though if your number of servers is large and your number of requests for each is no more than a few per second, you could see better distribution setting draws to 3 or 4.
first Jump to heading
Use balance first in cases where you power down servers that aren’t in active use. This algorithm will choose the first server in the list with open connection slots and send connections to it until it can’t receive any more connections, at which point it will move to the next server in the list. It ignores server weights. You must use the maxconn directive with this algorithm to establish the maximum number of connections for each server:
haproxybackend web_serversmode httpbalance firstserver s1 192.168.1.25:80 check maxconn 100server s2 192.168.1.26:80 check maxconn 100server s3 192.168.1.27:80 check maxconn 100
haproxybackend web_serversmode httpbalance firstserver s1 192.168.1.25:80 check maxconn 100server s2 192.168.1.26:80 check maxconn 100server s3 192.168.1.27:80 check maxconn 100
Tip
Be sure to monitor the number of queued connections per server to determine if you need to power on more servers. Use the show stat Runtime API command, keeping an eye on the value for each server’s qcur or the number of currently queued connections. Queued connections are waiting to access a backend server and a qcur value greater than zero may indicate you need more servers to handle connections.
hash Jump to heading
Use hash-based algorithms when you need to maintain affinity, or requests from the same client should reach the same server. Use balance hash to select the correct server. This algorithm takes an expression which, when evaluated, is used to compute the hash key and select the appropriate server.
Tip
There are several other load balancing algorithms that offer options similar to balance hash for simple hashing without needing to execute complex logic to compute the hash key. Use balance source when you want server affinity based on IP address. Use balance hdr(<header>) to assign server affinity based on the content of a particular HTTP header. Use balance uri for cache servers.
For example, if you wanted server affinity using IP addresses, you could use balance source. If, however, you wanted server affinity based on a /24 subnet instead of specific IP addresses, you could use balance hash with an expression that computes the subnet:
haproxybackend web_servers {0-1}balance hash src,ipmask(24)server app1 10.0.0.1:8080 checkserver app2 10.0.0.2:8080 checkserver app3 10.0.0.3:8080 check
haproxybackend web_servers {0-1}balance hash src,ipmask(24)server app1 10.0.0.1:8080 checkserver app2 10.0.0.2:8080 checkserver app3 10.0.0.3:8080 check
Enable health checks Jump to heading
Adding the check argument to each server line is a good practice; this enables health checking to remove unhealthy servers that don’t respond to a TCP connection from the load balancing rotation.
haproxybackend web_serversmode httpbalance roundrobinserver s1 192.168.1.25:80 checkserver s2 192.168.1.26:80 checkserver s3 192.168.1.27:80 check
haproxybackend web_serversmode httpbalance roundrobinserver s1 192.168.1.25:80 checkserver s2 192.168.1.26:80 checkserver s3 192.168.1.27:80 check
See also Jump to heading
For complete information on these directives that can be used in backends, see the HAProxy Configuration Manual:
- To select a load balancing algorithm, see the balance directive reference.
- To specify the type of traffic being processed, see mode.
- For complete information on
serverdirective syntax and options, see server. - To direct traffic to a specific backend, see use_backend.