Configuration example:
backend htmpool mode http option redispatch option abortonclose balance static-rr cookie SERVERID option httpchk GET /index.jsp server 237server 192.168.81.237:8080 cookie server1 weight 6 check inter 2000 rise 2 fall 3 server iivey234 192.168.81.234:8080 cookie server2 weight 3 check inter 2000 rise 2 fall 3
This section defines a real back-end server group named "htmpool" through backend keyword. The following describes the meaning of each option.
option redispatch: This parameter is used to keep the environment in the cookie. By default, the backend server HAProxy serverID request which will be inserted into a cookie, session SESSION to ensure durability. If the back-end server has cookie fails, the client is not refreshed, which is a problem. At this point, if you set this parameter, it will be directed to the customer's request to force the addition of a healthy back-end server, to ensure the normal services.
option abortonclose: If this parameter is set, the server can be at high load conditions, automatically off the end of the queue processing time is relatively long link to the current.
balance: This keyword is used to define load balancing algorithm. HAProxy currently support a variety of load balancing algorithms, commonly used are the following:
roundrobin: is based on the weights of the round-robin scheduling algorithm, distributed server performance is relatively homogeneous, which is one of the most fair, most reasonable algorithm. This method is often used.
static-rr: is based on the weighted polling scheduling algorithm, but this algorithm is a static method, the server adjusts its weights will not take effect at runtime.
source: based on the request source IP algorithm. This algorithm first request for source IP performs the hash function, then the right result with heavy back-end server forwards to match the back-end server after a total division. This way you can make the same client IP requests are always forwarded to a specific back-end server.
leastconn: new connection algorithm forwards the requests to the backend server having the least number of connections. In conversation a long time the scene is recommended to use this algorithm, such as databases and load balancing. This method is not suitable for shorter sessions environments, such as HTTP-based applications.
uri: This algorithm would be a part or the entire URI performs the hash function, then the server through the total weight divided by weight, and finally forwarded to the backend server a matching table.
uri_param: This algorithm will be forwarded in accordance with the parameters in the URL path, it will ensure that when the number of real constant back-end server to request the same user always distributed to the same machine.
hdr (<name>): This algorithm is based on forward http header, if specified http header name does not exist, the roundrobin algorithm strategy forward.
cookie: Permits to insert SERVERID cookie, SERVERID each server may use the cookie server keyword defined in the following keywords.
option httpchk: This option indicates that enable the HTTP service state detection. HAProxy as a professional load balancer that supports health checks for backend portion of the designated back-end service nodes to ensure that when a node in the backend backend can not service the incoming requests from the client end frotend assigned to other health backend nodes in order to guarantee the availability of the overall service.
"Optionhttpchk" is used as follows:
option httpchk <method> <uri> <version>
Wherein the meaning of each parameter is as follows:
method: represents the HTTP request, commonly used OPTIONS, GET, HEAD several ways. General health check can be used HEAD way, rather than just using a GET, HEAD way because no data is returned, check the Response of only 200 HEAD is not a state. Therefore relatively faster GET HEAD way, the more simple.
uri: Indicates that the URL address to be detected, through the implementation of this URL, you can obtain the operational status of the back-end server. Under normal circumstances will return a status code 200, the other status codes returned are in an abnormal state.
version: Specifies the HTTP when a heartbeat is detected version number.
server: This keyword is used to define multiple back-end real servers can not be used defaults and frontend section.
Use the format:
server <name> <address>[:port] [param*]
Wherein each of the parameters are as follows:
<name>: Specifies the internal name for a real back-end server, you can just define one.
<address>: IP address or host name of the real back-end server.
<port>: destination port when the connection request is sent to the specified real server. When not set, using the same port when the client requests.
[param *]: is a back-end server based parameter set many parameters can be used, just to introduce some common parameters:
check: represents the enabling of this back-end server to perform health checks.
inter: Set time health check interval in milliseconds.
rise: Set the number of conversion from fault state to normal state requires a successful check, for example. "Rise 2" represents two inspections properly considered the server is available.
fall: Set the number of back-end servers from the normal state to the unavailable state needs to be checked, for example, "fall 3" represents that three checks fail on the server is unavailable.
cookie: setting the specified backend server cookie value, the value specified here is to be checked at the inbound request, the first selection of this value will always be selected backend server in subsequent requests, the purpose of function is to achieve a lasting connection. The above "cookie server1" represents web1 of serverid is server1. Similarly, "cookie server2" represents web2 of serverid to server2.
weight: Set the back-end server real weight, the default is 1 and the maximum is 256. Set to 0 to not participate in load balancing.
backup: set up the back-end server backup real server, it is enabled only in the case of all real back-end servers are not available.