共计 8377 个字符，预计需要花费 21 分钟才能阅读完成。
1. 项目介绍：
前面我们实现了 keepalived 主从高可用集群网站架构，随着公司业务的发展，公司负载均衡服务已经实现四层负载均衡，但业务的复杂程度提升，公司要求把 mobile 手机站点作为单独的服务提供，不在和 pc 站点一起提供服务，此时需要做 7 层规则负载均衡，运维总监要求，能否用一种服务同既能实现七层负载均衡，又能实现四层负载均衡，并且性能高效，配置管理容易，而且还是开源。
四层和七层负载均衡的区别：
四层：
通过分析 IP 层及 TCP/UDP 层的流量实现的基于 ”IP+ 端口 ” 的负载均衡。
七层：
可以根据内容，再配合负载均衡算法来选择后端服务器，不但可以根据 ”ip+ 端口 ” 方式进行负载分流，还可以根据 网站的 URL，访问域名，浏览器类别，语言等决定负载均衡的策略。
七层负载均衡模式下，负载均衡与客户端及后端的服务器会分别建立一次 TCP 连接，而在四层负载均衡模式下(DR)，仅建立一次 TCP 连接；七层负载均衡对负载均衡设备的要求更高，处理能力也低于四层负载均衡。
场景说明
在企业生产环境中，每天会有很多的需求变更，比如增加服务器、新业务上线、url 路由修改、域名配置等等，对于前端负载均衡设备来说，容易维护，复杂度低，是首选指标。在企业中，稳定压倒一切，与其搞得很复杂，经常出问题，不如做的简单和稳定。
在企业中，90% 以上的故障，来源于需求变更。可能是程序 bug，也可能是人为故障，也可能是架构设计问题等等。
前端负载均衡设备为重中之重，在软件选型上一定充分考虑，能满足业务的前提下，尽可能降低复杂度，提高易维护性。
2. 模块讲解：
Haproxy 是什么
HAProxy 是一个使用 C 语言编写的自由及开放源代码软件，其提供高性能性、负载均衡，以及基于 TCP 和 HTTP 的应用程序代理。相较与 Nginx，HAProxy 更专注与反向代理，因此它可以支持更多的选项，更精细的控制，更多的健康状态检测机制和负载均衡算法。
HAProxy 特别适用于那些负载特大的 web 站点，这些站点通常又需要会话保持或七层处理。HAProxy 运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中，同时可以保护你的 web 服务器不被暴露到网络上。
包括 GitHub、Bitbucket、Stack Overflow、Reddit、Tumblr、Twitter 在内众多知名网站，及亚马逊网络服务系统都使用了 HAProxy。
Haproxy 的特性
1、可靠性与稳定性都非常出色，可与硬件级设备媲美。
2、支持连接拒绝，可以用于防止 DDoS 攻击
3、支持长连接、短连接和日志功能，可根据需要灵活配置
4、路由 HTTP 请求到后端服务器, 基于 cookie 作会话绑定；同时支持通过获取指定
的 url 来检测后端服务器的状态
5、HAProxy 还拥有功能强大的 ACL 支持，可灵活配置路由功能，实现动静分离，
在架构设计与实现上带来很大方便
6、可支持四层和七层负载均衡，几乎能为所有常见的服务提供负载均衡功能
7、拥有功能强大的后端服务器的状态监控 web 页面，可以实时了解设备的运行状态，还可实现设备上下线等简单操作。
8、支持多种负载均衡调度算法，并且也支持 session 保持。
3. 实战演练
实验：实现基于 Haproxy+Keepalived 负载均衡高可用架构
一、环境准备：
CentOS 系统服务器 4 台、两台用于做 haproxy 主从架构，两台作为后端 server，服务器配置好
yum 源、防火墙关闭、各节点时钟服务同步、各节点之间可以通过主机名互相通信
|
机器名称 |
IP 配置 |
服务角色 |
备注 |
|
haproxy-server-master |
VIP：172.17.253.100 DIP：172.17.253.132 |
负载均衡器 |
开启路由功能 配置 keepalived |
|
haproxy-server-master |
VIP：172.17.253.100 DIP：172.17.252.162 |
负载均衡器 |
开启路由功能 配置 keepalived |
|
rs1 |
RIP：172.17.251.236 |
后端服务器 |
网关指向 DIP（桥接） |
|
rs2 |
RIP：172.17.251.237 |
后端服务器 |
网关指向 DIP（桥接） |
二、安装步骤：
1、iptables -F && setenforing 清空防火墙策略，关闭 selinux
2、拿两台服务器都使用 yum 方式安装 haproxy、keepalived 服务
3、后端服务器配置好基于 LNMP 架构的 web 服务
三、修改配置文件:
1．修改 /etc/keepalived/keepalived.conf 配置文件内容
在 haproxy-server-master 上
vim /etc/keepalived/keepalived.conf
global_defs {
notification_email {root@localhost}
notification_email_from root@mingming.com
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id keepalived_lvs
}
vrrp_instance VI_1 {
state MASTER
interface ens33
virtual_router_id 55
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass mingming
}
virtual_ipaddress {172.17.253.100}
}
在 haproxy-server-backup 上
global_defs {
notification_email {root@localhost}
notification_email_from root@mingming.com
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id keepalived_lvs
}
vrrp_instance VI_1 {
state BACKUP
interface eth1
virtual_router_id 55
priority 98
advert_int 1
authentication {
auth_type PASS
auth_pass mingming
}
virtual_ipaddress {172.17.253.100}
}
2. 修改主 haproxy 配置文件主要是 listen，frontend 和 backend 段
在 haproxy-server-master 上
vim /etc/haproxy/haproxy.cfg
listsen 段
listen stats
bind 0.0.0.0:1080
stats enable
stats uri /haproxyadmin
stats auth admin:admin
stats admin if TRUEfrontend 段
frontend web
bind *:80
default_backend lnmp-serverbackend 段
backend lnmp-server
balance roundrobin
option httpchk GET /index.html
server webserver1 172.17.251.236:80 check inter 3000 rise 3 fall 5
server webserver1 172.17.251.237:80 check inter 3000 rise 3 fall 5在 haproxy-server-backup 上和在 haproxy-server-master 上haproxy 配置文件的配置是一样的
然后在 haproxy-server-master 上和在 haproxy-server-backup 上都开启 keepalived 和 haproxy 服务，会发现 vip 漂移到 haproxy-server-backup 上（因为 haproxy-server-master 上 keepalived 的配置文件中优先级高），而且 haproxy-server-master 和 haproxy-server-backup 上 haproxy 服务都监听了 1080 端口和 80 端口
四，检验高可用效果
1. 客户端先访问一下 vip，成功访问小米网站
2. 在 haproxy-server-master 上停掉 keepalived 服务，会发现 vip 漂移到 haproxy-server-backup 上，客户端依旧能够访问 vip，访问小米网站，实现了高可用
3. 关闭后端一台服务器的 web 服务，观察 haproxy 健康状态监测
4. 企业级应用
Haproxy 访问控制 ACL 应用
haproxy 的 ACL 用于实现基于请求报文的首部、响应报文的内容或其它的环境状态信息来做出转发决策，这大大增强了其配置弹性。其配置法则通常分为两步，首先去定义 ACL，即定义一个测试条件，而后在条件得到满足时执行某特定的动作，如阻止请求或转发至某特定的后端。
定义 ACL 的语法格式如下：
acl <aclname> <criterion> [flags] [operator] <value> …
<aclname>：ACL 名称，区分字符大小写，且其只能包含大小写字母、数字、-(连接线)、_(下划线)、.(点号)和:(冒号)；haproxy 中，acl 可以重名，这可以把多个测试条件定义为一个共同的 acl；
<criterion>：测试标准，即对什么信息发起测试；测试方式可以由 [flags] 指定的标志进行调整；而有些测试标准也可以需要为其在 <value> 之前指定一个操作符[operator]；
[flags]：常见 haproxy 的 acl 支持的标志位有 3 个：
-i：不区分 <value> 中模式字符的大小写；
-f：从指定的文件中加载模式；
–：标志符的强制结束标记，在模式中的字符串像标记符时使用；
<value>：acl 测试条件常见的值有以下四类：
整数或整数范围：如 1024:65535 表示从 1024 至 65535；仅支持使用正整数(如果出现类似小数的标识，其为通常为版本测试)，且支持使用的操作符有 5 个，分别为 eq、ge、gt、le 和 lt；
字符串：支持使用 ”-i” 以忽略字符大小写，支持使用 ”\” 进行转义；如果在模式首部出现了 -i，可以在其之前使用 ”–“ 标志位；
正则表达式：其机制类同字符串匹配；
IP 地址及网络地址
同一个 acl 中可以指定多个测试条件，这些测试条件需要由逻辑操作符指定其关系。条件间的组合测试关系有三种：” 与 ”(默认即为与操作)、” 或 ”(使用 ”||” 操作符)以及 ” 非 ”(使用 ”!” 操作符)。
Haproxy 进行安全加固
通过 ACL 限制用户请求速率
be_sess_rate(backend) <integer>
be_sess_rate 测试标准
用于测试指定的 backend 上会话创建的速率 (即每秒创建的会话数) 是否满足指定的条件；常用于在指定 backend 上的会话速率过高时将用户请求转发至另外的 backend，或用于阻止攻击行为。例如：
backend dynamic
mode http
acl being_scanned be_sess_rate gt 100
redirect location /denied.html if being_scanned
通过 ACL 指定可访问的用户（定义到 frontend 段中）
阻断非指定请求
在传输层获取样本，通常是 TCP/IP 协议的 IP 和端口，以及建立连接速率等等。而且此部分样本通常用于
“tcp-request connection” 指令中的规则之中。
dst : ip #目标地址
dst_port : integer
src : ip #源地址
src_port : integer
# 阻断来自非指定 IP 的访问 80 端口的请求
acl myhost src 172.16.100.1
acl myport dst_port 80
tcp-request connection reject if !myhost myport
# 还可以用 block
block if ! myhost myport
Haproxy 实现动静分离功能（在 frontend 段中定义）
根据用户访问内容实现动静分离
path_beg <string>
用于测试请求的 URL 是否以 <string> 指定的模式开头。下面的例子用于测试 URL 是否以 /static、
/images、/javascript 或 /stylesheets 头。
acl url_static path_beg -i /static /images /javascript /stylesheets
path_end <string>
用于测试请求的 URL 是否以 <string> 指定的模式结尾。例如，下面的例子用户测试 URL 是否以 jpg、gif、png、css 或 js 结尾。
acl url_static path_end -i .jpg .gif .png .css .js
根据用户访问内容实现动静分离配置实例
frontend http-in
bind *:80
log global
option httpclose
acl url_static path_beg -i /static /images /javascript /stylesheets
acl url_static path_end -i .jpg .jpeg .gif .png .css .js
use_backend static_servers if url_static
default_backend dynamic_servers
backend static_servers
balance roundrobin
server imgsrv1 172.16.200.7:80 check maxconn 6000
server imgsrv2 172.16.200.8:80 check maxconn 6000
backend dynamic_servers
balance source
server websrv1 172.16.200.7:80 check maxconn 1000
server websrv2 172.16.200.8:80 check maxconn 1000
Haproxy 实现浏览器控制（在 frontend 段中定义）
hdr_reg <string> 正则匹配请求内容，匹配后可做对应的操作
# 阻断火狐浏览器发送的请求
acl firefox hdr_reg(User-Agent) -i .*firefox.*
block if firefox
# 将 IE 用户请求分配到静态服务器
acl ie_useragent hdr_reg(User-Agent) -i .*ie.*
use_backend static_servers if ie_useragent
Haproxy 实现真实日志记录
option forwardfor
option forwardfor [except <network>] [header <name>] [if-none]
允许在发往服务器的请求首部中插入 ”X-Forwarded-For” 首部。
<network>：可选参数，当指定时，源地址为匹配至此网络中的请求都禁用此功能。
<name>：可选参数，可使用一个自定义的首部，如 ”X-Client” 来替代 ”X-Forwarded-For”。有些独特的 web 服务
器的确需要用于一个独特的首部。
if-none：仅在此首部不存在时才将其添加至请求报文问道中。
HAProxy 工作于反向代理模式，其发往服务器的请求中的客户端 IP 均为 HAProxy 主机的地址而非真正客户端的地址，这会使得服务器端的日志信息记录不了真正的请求来源，”X-Forwarded-For” 首部则可用于解决此问题。HAProxy 可以向每个发往服务器的请求上添加此首部，并以客户端 IP 为其 value。
需要注意的是，HAProxy 工作于隧道模式，其仅检查每一个连接的第一个请求，因此，仅第一个请求报文被附加此首部。
下面是一个例子。
frontend www
mode http
option forwardfor except 127.0.0.1
在 haproxy 的配置文件中默认就有此选项
在 nginx 的主配置文件中也默认有此选项
Haproxy 实现会话保持
一、源地址 hash（用户 IP 识别）
Haroxy 将用户 IP 经过 hash 计算后 指定到固定的真实服务器上（类似于 nginx 的 IP hash 指令）。
缺点：当后端一台服务器挂了以后会造成部分 session 丢失
示例：
backend SOURCE_srv
mode http
balance source
server app-node1 10.31.1.179:80 check port 80 inter 3000 rise 3 fall 3
server app-node2 10.31.1.191:80 check port 80 inter 3000 rise 3 fall 3
server app-node3 10.31.0.35:80 check port 80 inter 3000 rise 3 fall 3
二、cookie 识别
haproxy 将 WEB 服务端返回给客户端的 cookie 中插入 haproxy 中特定的字符串 (或添加前缀) 在后端的服
务器 COOKIE ID。
backend COOKIE_srv
mode http
cookie SERVERID insert indirect nocache
server app-node1 10.31.1.179:80 check port 80 cookie a inter 3000 rise 3 fall 3
server app-node2 10.31.1.191:80 check port 80 cookie b inter 3000 rise 3 fall 3
server app-node3 10.31.0.251:80 check port 80 cookie c inter 3000 rise 3 fall 3
在 LB1 上配置好 HAProxy 后，LB1 将接受用户的所有请求。如果一个用户请求不包含任何 cookie，那这个请求将被 HAProxy 转发到一台可用的 WEB 服务器。可能是 webA,webB，webC。然后 HAProxy 将把处理这个请求的 WEB 服务器的 cookie 值插入到请求响应中。如 SERVERID=A。当这个客户端再次访问并在 HTTP 请求头中带有 SERVERID=A,HAProxy 将会把它的请求直接转发给 webA 处理。在请求到达 webA 之前，cookie 将被移除，webA 将不会看到这个 cookie。如果 webA 不可用，对应的请求将被转发到其他可用的 WEB 服务器，相应的 cookie 值也将被重新设置。
Haproxy 性能优化参数
option redispatch：当 server 对应的服务器挂掉后，强制定向到其他健康的服务器
option dontlognull：保证 HAProxy 不记录上级负载均衡发送过来的用于检测状态没有数据的心跳包。
retries 3 : // 3 次连接失败就认为服务器不可用，主要通过后面的 check 检查
maxconn 30000 : // 代理时所能接受的最大并发连接数，应该要比后端主机的并发总和要小
好了，今天的内容就到这里，下期再见。
构建高可用集群 Keepalived+Haproxy 负载均衡 http://www.linuxidc.com/Linux/2016-12/138917.htm
HAproxy 的基本配置（负载均衡 + 日志独立 + 动静分离 + 读写分离）http://www.linuxidc.com/Linux/2017-03/141614.htm
CentOS 7 下 Keepalived + HAProxy 搭建配置详解 http://www.linuxidc.com/Linux/2017-03/141593.htm
HAproxy 实现反向代理和负载均衡 http://www.linuxidc.com/Linux/2016-12/138749.htm
HAProxy+Keepalived 实现高可用负载均衡 http://www.linuxidc.com/Linux/2016-06/132225.htm
使用 HAProxy 配置 HTTP 负载均衡器 http://www.linuxidc.com/Linux/2015-01/112487.htm
Ubuntu 16.04 下安装 HAProxy 1.5.11 做 tcp 负载均衡 http://www.linuxidc.com/Linux/2016-06/132689.htm
CentOS 7.2 部署 Haproxy 1.7.2 http://www.linuxidc.com/Linux/2017-10/147553.htm
HAproxy 的详细介绍：请点这里
HAproxy 的下载地址：请点这里
本文永久更新链接地址：http://www.linuxidc.com/Linux/2017-12/149080.htm
