Haproxy 快速指南
快速开始
配置 haproxy
安装 haproxy
yum -y install haproxy
配置 haproxy
vi /etc/haproxy/haproxy.cfg
global
log 127.0.0.1 local0
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 10000
user haproxy
group haproxy
daemon
ulimit-n 100000
stats socket /var/lib/haproxy/stats level admin process 1
nbproc 12
cpu-map 1 0
cpu-map 2 1
cpu-map 3 2
cpu-map 4 3
cpu-map 5 4
cpu-map 6 5
cpu-map 7 6
cpu-map 8 7
cpu-map 9 8
cpu-map 10 9
cpu-map 11 10
cpu-map 12 11
defaults
log global
option tcplog
option dontlognull
retries 3
timeout connect 2s
timeout client 3600s
timeout server 3600s
maxconn 10000
listen admin_stats
bind *:1080
mode http
maxconn 10
stats refresh 10s
stats uri /haproxy
stats realm Haproxy
stats auth admin:admin
stats hide-version
stats admin if TRUE
frontend haproxy
bind *:40000
mode tcp
default_backend tidb
backend tidb
balance leastconn
mode tcp
# acl internal_networks src 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 127.0.0.1
# tcp-request content reject if ! internal_networks
# option mysql-check user haproxy post-41
server tidb1 10.0.1.4:4000 check
server tidb2 10.0.1.10:4000 check
检查配置文件
haproxy -f /etc/haproxy/haproxy.cfg -c
Configuration file is valid
启动 haproxy
systemctl start haproxy.service
查看 Haproxy Statistics Report
访问 http://haproxyip:1080/haproxy， 输入用户名密码 admin:admin
配置 rsyslog (可选)
此项配置会记录 haproxy 日志
vi /etc/rsyslog.conf
在 #### MODULES #### 下配置侦听端口与协议
# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
在 #### RULES #### 下配置日志存放路径
# Save haproxy log
local0.* /var/log/haproxy/haproxy.log
注意：local[x]，x 可配 0~7 之间，并且和 haproxy.cfg 里的 local[x] 一致
重新启动 rsyslog
systemctl restart rsyslog
配置监控（可选）
安装 haproxy_exporter
下载 haproxy_exporter
wget https://github.com/prometheus/haproxy_exporter/releases/download/v0.10.0/haproxy_exporter-0.10.0.linux-amd64.tar.gz
tar -zxvf haproxy_exporter-0.10.0.linux-amd64.tar.gz
启动 haproxy
./haproxy_exporter --haproxy.scrape-uri="http://{user}:{passowrd}@{haproxyip}:1080/haproxy?stats;csv"
# ./haproxy_exporter --haproxy.scrape-uri="http://admin:admin@10.0.1.4:1080/haproxy?stats;csv"
配置 prometheus
vi prometheus.yml，在 scrape_configs 下增加
scrape_configs:
- job_name: "haproxy"
static_configs:
- targets:
- '{haproxyip}:9101'
重启 prometheus
systemctl restart prometheus.service
访问 grafana.com，并导入报表
https://grafana.com/dashboards/2428
简介
什么是负载均衡（Load Balancing）
在网站创立初期，我们一般都使用单台机器对台提供集中式服务，但随着业务量越来越大，无论性能还是稳定性上都有了更大的挑战。这时候我们就会想到通过扩容的方式来提供更好的服务。我们一般会把多台机器组成一个集群对外提供服务。然而，我们的网站对外提供的访问入口都是一个的，比如 www.taobao.com。那么当用户在浏览器输入 www.taobao.com 的时候如何将用户的请求分发到集群中不同的机器上呢，这就是负载均衡在做的事情。
当前大多数的互联网系统都使用了服务器集群技术，集群即将相同服务部署在多台服务器上构成一个集群整体对外提供服务，这些集群可以是 Web 应用服务器集群，也可以是数据库服务器集群，还可以是分布式缓存服务器集群等。
在实际应用中，在 Web 服务器集群之前总会有一台负载均衡服务器，负载均衡设备的任务就是作为 Web 服务器流量的入口，挑选最合适的一台 Web 服务器，将客户端的请求转发给它处理，实现客户端到真实服务端的透明转发。
最近几年很火的「云计算」以及分布式架构，本质上也是将后端服务器作为计算资源、存储资源，由某台管理服务器封装成一个服务对外提供，客户端不需要关心真正提供服务的是哪台机器，在它看来，就好像它面对的是一台拥有近乎无限能力的服务器，而本质上，真正提供服务的是后端的集群。
负载均衡分类
现在我们知道，负载均衡就是一种计算机网络技术，用来在多个计算机（计算机集群）、网络连接、CPU、磁碟驱动器或其它资源中分配负载，以达到最佳化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。那么，这种计算机技术的实现方式有多种。
大致可以分为以下几种，其中最常用的是四层和七层负载均衡：
-
二层负载均衡
负载均衡服务器对外依然提供一个 VIP（虚IP），集群中不同的机器采用相同 IP地址，但机器的 MAC 地址不一样。当负载均衡服务器接受到请求之后，通过改写报文的目标 MAC 地址的方式将请求转发到目标机器实现负载均衡。
-
三层负载均衡
和二层负载均衡类似，负载均衡服务器对外依然提供一个 VIP（虚IP），但集群中不同的机器采用不同的 IP 地址。当负载均衡服务器接受到请求之后，根据不同的负载均衡算法，通过 IP 将请求转发至不同的真实服务器。
-
四层负载均衡
四层负载均衡工作在 OSI 模型的传输层，由于在传输层，只有 TCP/UDP 协议，这两种协议中除了包含源 IP、目标 IP 以外，还包含源端口号及目的端口号。四层负载均衡服务器在接受到客户端请求后，以后通过修改数据包的地址信息（ IP+端口号 ）将流量转发到应用服务器。
-
七层负载均衡
七层负载均衡工作在 OSI 模型的应用层，应用层协议较多，常用 HTTP、Radius、DNS 等。七层负载就可以基于这些协议来负载。这些应用层协议中会包含很多有意义的内容。比如同一个 Web 服务器的负载均衡，除了根据 IP 加端口进行负载外，还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。
HAProxy 是什么
HAProxy 是一个使用C语言编写的自由及开放源代码软件，其提供高可用性、负载均衡，以及基于 TCP 和 HTTP 的应用程序代理。
-
HAProxy 特别适用于那些负载特大的 web 站点，这些站点通常又需要会话保持或七层处理。
-
HAProxy 运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的 web 服务器不被暴露到网络上。
-
HAProxy 实现了一种事件驱动，单一进程模型，此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制，很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户空间 (User-Space) 实现所有这些任务，所以没有这些问题。此模型的弊端是，在多核系统上，这些程序通常扩展性较差。这就是为什么他们必须进行优化以使每个 CPU 时间片 Cycle 做更多的工作。
-
相较与 Nginx，HAProxy 更专注与反向代理，因此它可以支持更多的选项，更精细的控制，更多的健康状态检测机制和负载均衡算法。
包括 GitHub、Bitbucket、Stack Overflow、Reddit、Tumblr、Twitter 和 Tuenti 在内的知名网站，及亚马逊网络服务系统都使用了 HAProxy。
HAProxy基础概念和原理
Haproxy的特性：
- 可靠性与稳定性都非常出色，可与硬件级设备媲美。
- 支持连接拒绝，可以用于防止 DDoS 攻击
- 支持长连接、短连接和日志功能，可根据需要灵活配置
- 路由 HTTP 请求到后端服务器,基于 cookie 作会话绑定；同时支持通过获取指定的 url 来检测后端服务器的状态
- HAProxy 还拥有功能强大的 ACL 支持，可灵活配置路由功能，实现动静分离，在架构设计与实现上带来很大方便
- 可支持四层和七层负载均衡，几乎能为所有服务常见的提供负载均衡功能
- 拥有功能强大的后端服务器的状态监控 web 页面，可以实时了解设备的运行状态 ，还可实现设备上下线等简单操作。
- 支持多种负载均衡调度算法，并且也支持 session 保持。
Haproxy 七层负载均衡模式下，负载均衡与客户端及后端的服务器会分别建立一次 TCP连接，而在四层负载均衡模式下(DR)，仅建立一次 TCP 连接；七层负载均衡对负载均衡设备的要求更高，处理能力也低于四层负载均衡。
HAProxy 配置文件
Haproxy程序路径：
主程序：/usr/sbin/haproxy
主配置文件：/etc/haproxy/haproxy.cfg
Unit file：/usr/lib/systemd/system/haproxy.service（centos7）
Init.file：/etc/init.d/haproxy （centos6）
HAProxy 配置文件结构
haproxy 的配置文件由两部分组成：全局设定（global settings）和对代理的设定（proxies）
-
global settings：主要用于定义 haproxy 进程管理安全及性能相关的参数
-
proxies 共分为4段：defaults，frontend，backend，listen
proxies：代理相关的配置可以有如下几个配置端组成
- defaults：为除了 global 以外的其它配置段提供默认参数，默认配置参数可由下一个 “defaults” 重新设定。
- frontend：定义一系列监听的套接字，这些套接字可接受客户端请求并与之建立连接。
- backend：定义 “后端” 服务器，前端代理服务器将会把客户端的请求调度至这些服务器。
- listen：定义监听的套接字和后端的服务器。类似于将 frontend 和 backend 段放在一起
所有代理的名称只能使用大写字母、小写字母、数字、-(中线)、_(下划线)、.(点号)和:(冒号)。此外，ACL 名称会区分字母大小写。
HAProxy 配置文件描述
vi /etc/haproxy/haproxy.cfg
global
log 127.0.0.1 local0 # 定义全局的 syslog 服务器，最多可定义2个,格式：log <address> <facility> [max level [min level]]
chroot /var/lib/haproxy # 修改 haproxy 的工作目录至指定的目录并在放弃权限之前执行，保证haproxy的安全,使用配置文件默认值即可
pidfile /var/run/haproxy.pid
maxconn 10000 # 设定每个haproxy进程所接受的最大并发连接数，其等同于命令行选项“-n”；“ulimit -n”自动计算的结果正是参照此参数设定的；
user haproxy # 以指定的 user 运行haproxy，建议使用专用于运行 haproxy 的 user, 以免因权限问题带来风险；
group haproxy # 以指定的 group 运行haproxy，建议使用专用于运行 haproxy 的 group， 以免因权限问题带来风险；
daemon # 让 haproxy 以守护进程的方式工作于后台，其等同于 “-D” 选项的功能， 当然，也可以在命令行中以 “-db” 选项将其禁用；
ulimit-n 100000 # 设定每进程所能够打开的最大文件描述符数目，默认情况下其会自动进行计算，因此不推荐修改此选项；Linux默认单进程打开文件数为1024个
stats socket /var/lib/haproxy/stats level admin process 1 # 开启一个 socket 管理接口
nbproc 12 # 指定启动的 haproxy 进程个数，只能用于守护进程模式的 haproxy；默认只启动一个进程，
cpu-map 1 0 # 绑定 cpu,和 nbproc 数量相对。进程号从1开始，cpu 核数从0开始；
cpu-map 2 1
cpu-map 3 2
cpu-map 4 3
cpu-map 5 4
cpu-map 6 5
cpu-map 7 6
cpu-map 8 7
cpu-map 9 8
cpu-map 10 9
cpu-map 11 10
cpu-map 12 11
defaults
log global
option tcplog # 启用日志记录；tcplog 请求；
option dontlognull # 日志中将不会记录空连接；
retries 3 # 定义连接后端服务器的失败重连次数
timeout connect 2s # 定义 haproxy 将客户端请求转发至后端服务器所等待的超时时长
timeout client 3600s # 客户端非活动状态的超时时长
timeout server 3600s # 客户端与服务器端建立连接后，等待服务器端的超时时长
maxconn 10000 # 默认和前段的最大连接数，但不能超过 global 中的 maxconn 限制数
listen admin_stats # 开启一个统计报告服务
bind *:1080 # 监听1080端口
mode http # 基于http协议
maxconn 10
stats refresh 10s # 统计页面自动刷新时间间隔
stats uri /haproxy # url 地址
stats realm Haproxy # 统计页面密码框上提示文本
stats auth admin:admin # 账号：密码
stats hide-version # 隐藏统计报告版本信息
stats admin if TRUE # 在制定条件下开启admin 功能
frontend haproxy # 前端应用
bind *:40000 # 端口
mode tcp # tcp 模式
default_backend tidb # 此前端对应的后端应用
backend tidb # 后端应用
balance leastconn # balance 基于最少连接数
mode tcp # tcp 模式
# acl internal_networks src 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 127.0.0.1 定义一条ACL，ACL是根据数据包的指定属性以指定表达式计算出的true/false值。
# tcp-request content reject if ! internal_networks
# option mysql-check user haproxy post-41
server tidb1 10.0.1.4:4000 check # 后端应用地址，代理将会将对应客户端的请求转发至这些服务器。
server tidb2 10.0.1.10:4000 check
常见负载均衡算法
上面介绍负载均衡技术的时候提到过，负载均衡服务器在决定将请求转发到具体哪台真实服务器时，是通过负载均衡算法来实现的。负载均衡算法可以分为两类：静态负载均衡算法和动态负载均衡算法。
- 静态负载均衡算法包括：轮询、比率、优先权。
- 动态负载均衡算法包括：最少连接数、最快响应速度、观察方法、预测法、动态性能分配、动态服务器补充、服务质量、服务类型、规则模式。
轮询（Round Robin）：顺序循环将请求一次顺序循环地连接每个服务器。当其中某个服务器发生第二到第 7 层的故障，BIG-IP 就把其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复正常。
以轮询的方式依次请求调度不同的服务器；实现时，一般为服务器带上权重；这样有两个好处：针对服务器的性能差异可分配不同的负载；当需要将某个结点剔除时，只需要将其权重设置为0即可；
优点：实现简单、高效；易水平扩展
缺点：请求到目的结点的不确定，造成其无法适用于有写的场景（缓存，数据库写）
应用场景：数据库或应用服务层中只有读的场景
随机方式：请求随机分布到各个结点；在数据足够大的场景能达到一个均衡分布；
优点：实现简单、易水平扩展
缺点：同 Round Robin，无法用于有写的场景
应用场景：数据库负载均衡，也是只有读的场景
优先权（Priority）：给所有服务器分组，给每个组定义优先权，BIG-IP 用户的请求，分配给优先级最高的服务器组（在同一组内，采用轮询或比率算法，分配用户的请求）；当最高优先级中所有服务器出现故障，BIG-IP 才将请求送给次优先级的服务器组。这种方式，实际为用户提供一种热备份的方式。
最少的连接方式（Least Connection）：传递新的连接给那些进行最少连接处理的服务器。当其中某个服务器发生第 2 到第 7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。数据库常用的一种负载均衡方式。
网友评论