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/statsmaxconn conns
sets the maximum number of concurrent connections for a frontend, so it cannot be used for backend segments. For large sites, this value can be increased as much as possible to allow haproxy to manage the connection queue to avoid failing to answer user requests. Of course, this maximum value cannot exceed the definition in the "global" section. Also, keep in mind that haproxy maintains two buffers for each connection, each with a size of 8KB, plus other data, each connection will occupy about 17KB of RAM space. This means that with proper optimization, 40,000-50,000 concurrent connections can be maintained with 1GB of available RAM space.
If you specify an excessively large value for conns, in extreme scenarios, the space it eventually occupies may exceed the available memory of the current host, which may bring unexpected results; therefore, set it to an acceptable value as Decide wisely. It defaults to 2000.
The log address facility [level[minlevel]]
enables event and traffic logging for each instance and is therefore available to all segments. Each instance can specify up to two log parameters. However, if "log global" is used and two log parameters have been set in the "global" section, the redundant log parameters will be ignored.
global: When the log system parameters of the current instance are the same as those defined in the "global" section, this format will be used; each instance can only define a "log global" statement once, and it does not have any additional parameters;
address: defines the location where the logs are sent, one of the formats can be IPv4_address:PORT, where the port is the UDP protocol port, the default is 514; the second format is the Unix socket file path, but you need to pay attention to the chroot application and user's Read and write permissions;
facility: can be one of the standard facilities of the syslog system;
level: defines the log level, that is, the output information filter, the default is all information; when the level is specified, all log information equal to or higher than this level will be sent;
Defaults section description
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中获得客户端ipmode { 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_groupsuse_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 1000balance 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 a server goes down or a new server is added, many client requests may be dispatched to a different server from 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 checkcurl -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