Detailed explanation of the use and configuration files of HAProxy

Overview of HAProxy:

HAProxy is a free and open source software written in C that provides high availability, load balancing, and application proxying over TCP and HTTP.
HAProxy is especially useful for heavily loaded web sites that often require session persistence or Layer 7 processing. HAProxy runs on current hardware and can fully support tens of thousands of concurrent connections. And its mode of operation makes it easy and secure to integrate into your current architecture, while protecting your web server from being exposed to the network.
HAProxy implements an event-driven, single-process model that supports a very large number of concurrent connections. A multi-process or multi-threaded model is limited by memory constraints, system scheduler constraints, and ubiquitous locks, and can rarely handle thousands of concurrent connections. The event-driven model does not have these problems because it implements all these tasks in User-Space with better resource and time management. The downside of this model is that these programs typically scale less well on multi-core systems. That's why they have to optimize to make more work per CPU time slice (Cycle).

Configuration file: /etc/haproxy/haproxy.cfg #yum install haproxy's main configuration file
proxy configuration section: divided into four sections: defaults, frontend, listen, backend;
defaults name is used to provide default values ​​for listen/frontend/backend , whose name is an optional parameter, can be added for better readability, or not.

listen name defines a complete proxy server by associating front-end and back-end

frontend name defines the listening socket for receiving client requests and connecting to it

backend name Defines the backend server group for processing requests forwarded by frontend Note: name can use uppercase and lowercase letters, numbers,

Global segment description

global
    log         127.0.0.1 local2

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon

    stats socket /var/lib/haproxy/stats

maxconn conns
设定一个前端的最大并发连接数,因此其不能用于backend区段。对于大型站点来说,可以尽可能提高此值以便让haproxy管理连接队列,从而避免无法应答用户请求。当然,此最大值不能超出“global”段中的定义。此外,需要留心的是,haproxy会为每个连接维持两个缓冲,每个缓冲的大小为8KB,再加上其它的数据,每个连接将大约占用17KB的RAM空间。这意味着经过适当优化后,有着1GB的可用RAM空间时将能维护40000-50000并发连接。
如果为conns指定了一个过大值,极端场景下,其最终占据的空间可能会超出当前主机的可用内存,这可能会带来意想不到的结果;因此,将其设定了一个可接受值方为明智决定。其默认为2000。

log address facility [level [ minlevel ]]
为每个实例启用事件和流量日志,因此可用于所有区段。每个实例最多可以指定两个log参数,不过,如果使用了“log global”且"global"段已经定了两个log参数时,多余了log参数将被忽略。

global:当前实例的日志系统参数同"global"段中的定义时,将使用此格式;每个实例仅能定义一次“log global”语句,且其没有任何额外参数;

address:定义日志发往的位置,其格式之一可以为IPv4_address:PORT,其中的port为UDP协议端口,默认为514;格式之二为Unix套接字文件路径,但需要留心chroot应用及用户的读写权限;

facility:可以为syslog系统的标准facility之一;

level:定义日志级别,即输出信息过滤器,默认为所有信息;指定级别时,所有等于或高于此级别的日志信息将会被发送;

Defaults 段说明

defaults
        mode http                                        #默认的模式mode{tcp|http|health},health只会返回OK
                #retries 2                                        #两次连接失败就认为是服务器不可用,也可以通过后面设置
                option redispatch                          #当serverId对应的服务器挂掉后,强制定向到其他健康的服务器
                option abortonclose                     #当服务器负载很高的时候,自动结束掉当前队列处理比较久的链接
                timeout connect 5000ms              #连接超时
                timeout client 30000ms                #客户端超时
                timeout server 30000ms              #服务器超时
                #timeout check 2000                    #心跳检测超时
                log 127.0.0.1 local0 err                #[err warning info debug]
                balance roundrobin                      #负载均衡算法
                option httplog                                 #日志类别,采用httplog
                option httpclose                             #每次请求完毕后主动关闭http通道,ha-proxy不支持keep-alive,只能模拟这种模式的实现
                option dontlognull
                option forwardfor                           #如果后端服务器需要获得客户端真实ip需要配置的参数,可以从Http Header中获得客户端ip

mode { tcp|http|health } Sets the running mode or protocol of the instance. When implementing content exchange, the front-end and back-end must work in the same mode (in general, HTTP mode), otherwise the instance will not be able to start.

tcp: The instance runs in pure TCP mode, and a full-duplex connection will be established between the client and the server, and will not do any type of checking on Layer 7 packets; this is the default mode, usually used for SSL, SSH, SMTP and other applications;

http: The instance runs in HTTP mode, client requests will be deeply analyzed before being forwarded to the backend server, and all requests that are not compatible with the RFC format will be rejected;

health: The instance works in health mode, which only responds to inbound requests with "OK" information and closes the connection, and does not record any log information; this mode will be used to respond to health status check requests from external components; currently, this mode has been deprecated, because the monitor keyword in tcp or http mode can accomplish similar functions;

Listen segment description

listen stats
bind 0.0.0.0:8888                                            #监听端口
option httplog                                                  #采用http日志格式
stats enable                                                      #开启stats统计页面
stats uri /                                                            #统计页面访问的前缀,后通常要加上?stats
stats realm "Haproxy Auth"                          #开启认证功能
stats auth admin:admin                                #认证时的账号和密码
stats admin if TRUE                                      #在制定条件下开启admin功能
stats refresh 3s                                              #统计页面自动刷新时间间隔
stats show-desc demo                                 #统计页面显示的相关描述信息
stats hide-version                                           #隐藏haproxy的版本号

bind bind listening address
syntax: bind [address]:port_range [, ...] interface interface
This directive can only be used in the frontend and listen sections to define one or several listening sockets.

Frontend segment description

frontend  main *:80
default_backend    apache_groups

use_backend: call the specified backend host (defined in frontend and listen);
syntax: use_backend backend [{if | unless} condition]

Condition is mostly the name of acl

default_backend: The backend host called by default; (defined in frontend, defaults, listen)
Syntax: default_backend backend

Backend segment description

backend apache_groups
balance   roundrobin
cookie SERVERID insert indirect
server slave2 192.168.1.3:80 check inter 1s rise 2 fall 3 cookie A maxconn 1000
server slave3 192.168.1.4:80 check inter 1s rise 2 fall 3 cookie B maxconn 1000

balance defines the load balancing algorithm (available for "defaults", "listen" and "backend").

Syntax: balance algorithm [arguments]
The algorithm is used to pick a server in a load balancing scenario, it should only be used when persistent information is not available or when a connection needs to be redispatched to another server.
The supported algorithms are:
roundrobin : roundrobin based on weights, this is the most balanced and fair algorithm when the server's processing time remains evenly distributed. This algorithm is dynamic, meaning its weights can be adjusted at runtime, however, by design, each backend server can only accept up to 4128 connections;

static-rr: Round-robin based on weight, similar to roundrobin, but a static method, adjusting its server weight at runtime will not take effect; however, it has no limit on the number of back-end server connections;

leastconn: new connection requests are dispatched to the backend server with the least number of connections; this algorithm is recommended in scenarios with long sessions, such as LDAP, SQL, etc., which is not suitable for application layers with short sessions protocol, such as HTTP; this algorithm is dynamic and its weights can be adjusted at runtime;

source: Hash the source address of the request, divide it by the total weight of the backend server, and distribute it to a matching server; this allows requests from the same client IP to always be distributed to a specific server; however, When the total number of server weights changes, such as when a server goes down or a new server is added, many client requests may be dispatched to a different server than the previous request; TCP-based protocol often used for load balancing without cookie function; its The default is static, but this feature can also be modified by hash-type;

server defines the backend server

Syntax: server name address param

name: The internal name specified for this server, which will appear in logs and warning messages; if "http-send-server-name" is set, it will also be added to the request header sent to this server;

address: The IPv4 address of this server, also supports the use of a resolvable host name, but the host name needs to be resolved to the corresponding IPv4
address ;

disabled: this server is disabled;

backup: set as a backup server, only other servers in the load balancing scenario cannot be used to enable this server;

check: Starts performing a health check on this server, which can be fine-tuned with the help of additional parameters.

inter delay: Set the time interval of monitoring status check, the unit is milliseconds, the default is 2000, you can also use fastinter and downinter to optimize the event delay according to the server-side theme

rise count: Set the number of times that an offline server needs to be successfully checked to transition from an offline state to a normal state during the check state check.

fall count: Set the number of times that a server needs to be successfully checked to transition from a normal state to an offline state during the check state check

cookie value: Set the cookie value for the specified server. The value specified here will be checked when the request is inbound. The server selected for this value for the first time will be selected in subsequent requests. The purpose is to achieve persistent connection. Function;

maxconn maxconn: specifies the maximum number of concurrent connections accepted by this server; if the number of connections sent to this server is higher than the value specified here, it will be placed in the request queue to wait for other connections to be released;

maxqueue maxqueue: Set the maximum length of the request queue; 0 means no upper limit;

weight weight: weight, the default is 1, the maximum value is 256, 0 means not participating in load balancing;

[root@Haproxy ~]# yum install -y haproxy #Install directly using RPM

[root@Haproxy ~]# vim /etc/haproxy/haproxy.cfg #haproxy's main configuration file

Example of https proxy:

listen proxytofirehose :443
mode tcp
balance roundrobin
stick-table type ip size 200k expire 30m
stick on src
server firehose 192.168.122.2:443 check

curl -x 192.168.122.172:80 www.wo.com.cn This command uses the proxy server IP and port of 192.168.122.172:80 to access the site www.wo.com.cn Parameter description -x Set the proxy, the format is host[: port], the default value of port is 1080
wget -Y on -e "http_proxy= http://192.168.122.172:9201 " "www.wo.com.cn" This command uses the proxy server IP of 192.168.122.172:9201 and port access site www.wo.com.cn Parameter description -Y Whether to use proxy -e to execute the command

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324850138&siteId=291194637