目录
HAProxy 负载均衡器
Haproxy概述
ha-proxy是一款高性能的负载均衡软件。因为其专注于负载均衡这一些事情，因此与nginx比起来在负载均衡这件事情上做更好，更专业。
HAProxy（High Availability Proxy）是由法国人 Willy Tarreau 个人开发的基于 TCP、HTTP 协议实现的开源 L4-L7 软件负载均衡器，采用单进程和事件驱动模型实现，具有高可用和反向代理特性，支持双机热备与虚拟主机。目标是支持 10000+ 请求连接，为后端业务服务器集群提供高性能的负载均衡服务。适用于大连接数，要求会话保持，分发复杂的流量负载均衡场景。
四层代理：HAProxy 采用 NAT 模式，在客户端和 Real Server 之间双向转发流量 七层代理：HAProxy 通过分析、理解、修改应用层协议来实现更加 “智能” 的流量分发。 注：Real Server，实际处理客户端请求的业务服务器。
应用特性
客户端侧长连接（Client-side Keep-alive）TCP 加速（TCP Speedups）响应池（Response Buffering）RDP 协议基于源的粘性（Source-based Stickiness）更好的统计数据接口（A much better stats interfaces）更详细的健康状态检测机制（More verbose health checks）基于流量的健康评估机制（Traffic-based Health）支持 HTTP 认证服务器管理命令行接口（Server management from the CLI）基于 ACL 的持久性（ACL-based Persistence）日志分析器性能优势
haproxy 作为目前流行的负载均衡软件，必须有其出色的一面。下面介绍一下ha-proxy相对LVS，Nginx等负载均衡软件的优点。
支持tcp / http 两种协议层的负载均衡，使得其负载均衡功能非常丰富。 支持8种左右的负载均衡算法，尤其是在http模式时，有许多非常实在的负载均衡算法，适用各种需求。 性能非常优秀，基于单进程处理模式（和Nginx类似）让其性能卓越。 拥有一个功能出色的监控页面，实时了解系统的当前状况。 功能强大的ACL支持，给用户极大的方便。HAProxy 基于事件驱动（Event-Driven）、单一进程模型和 Ebtree 弹性二叉树机制，显著降低了上下文切换的开销及内存占用，根据官方文档，HAProxy 可以跑满 10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom’s 10GbE NICs (Myri-10G PCI-Express)，作为软件级负载均衡是比较惊人的。多进程或多线程模型受内存限制、系统调度器限制以及无处不在的锁限制，很少能处理数千量级的并发连接。
基于事件驱动（Event-Driven）：事务不会长时间占用 CPU，直到事件来临时，操作系统才会将事务唤醒。 单一进程模型：避免了多线程、多进程的上下文切换、模式切换以及调度器负载的性能开销。 Ebtree（Elastic Binary Tree，弹性二叉树机制）树形存储：是由 Willy Tarreau 自己发明的一种不平衡二叉搜索树数据结构，实现了以 O(log(N)) 的低开销来保持计时器命令、保持运行队列命令及管理轮询及最少连接队列，还实现了删除叶节点时保持 O(1) 的时间复杂度，但同时也放弃了树的平衡。 O(1) 事件检查器（Event Checker）：允许其在高并发连接中对任何连接的任何事件实现即时探测。 单缓冲（Single Buffering）机制：能以不复制任何数据的方式完成读写操作，这会节约大量的 CPU 时钟周期及内存带宽。 借助于 Linux 2.6（>=2.6.27.19）上的 splice() 系统调用，HAProxy 可以实现零复制转发（Zero-copy Forwarding），在 Linux 3.5 及以上的操作系统中还可以实现零复制启动（Zero-Starting）。 内存分配器在固定大小的内存池中可实现即时内存分配，这能够显著减少创建一个会话的时长。 优化的 HTTP Header 分析：优化协议头分析功能避免了在 HTTP Header 分析过程中重复读取任何内存区域。 精心地降低了昂贵的 Linux 系统调用，减少模式切换开销，大部分工作都在用户空间完成，如时间读取、缓冲聚合及文件描述符的启用和禁用等。会话保持
HAProxy 为来自同一客户端的请求访问实现了三种会话保持方案：
SOURCE_IP：HAProxy 将客户端的 SOURCE IP 进行 Hash 计算并保存，由此确保相同 IP 访问时被转发到同一台 Real Server 上。Cookie：HAProxy 依靠 Real Server 发送给客户端的 Cookie 信息进行会话保持Session：HAProxy 保存 Real Server 的 Session 及服务器标识健康检查
HAProxy 使用 Health Check 来确定 Backend Real Server 能不能处理分发的客户端请求，这避免了运维人员在 Real Server 不可用时需要人工移除。默认的 Health Check 方法是尝试和 Real Server 建立 TCP 连接，比如：检查 Real Server 是否在预设的 IP:Port 上进行监听。HAProxy 允许手动配置 Health Check 方法，有 TCP，HTTP，PING 三种方式。
当 Real Server 被检查失败时，HAProxy 会自动禁用它，客户端请求不会分发到该 Real Server，直到它重新激活位置。
配置文件
HAProxy 的配置文件为 /etc/haproxy.cfg，主要由 5 部分组成：
global：全局配置参数，属于进程级配置，通常与操作系统配置相关。 defaults：默认配置参数，此部分的设置参数值默认会自动被引用到 frontend、backend 和 listen，属于公用的配置参数部分。如果 default 的配置参数与后面几个部分的私有配置参数冲突，则优先私有配置参数。 frontend（前端）：设置接收客户端请求的前端虚拟节点（LB 服务器），允许根据 ACL 规则直接指定 backend。 backend（后端）：配置后端服务器集群，也就是一组处理客户端请求的 Real Server。 listen：是 frontend 部分和 backend 部分的结合体，在较新版本的版本中 listen section 是可选的。负载均衡策略
roundrobin：简单轮询 基于权重进行轮询,在服务器的处理时间保持均匀分布时,这是最平衡,最公平的算法.此算法是动态的,这表示其权重可以在运行时进行调整.理解举例：
◆有三个节点A、B、C
◆第一个用户访问会被指派到节点A
◆第二个用户访问会被指派到节点B
◆第三个用户访问会被指派到节点C
◆第四个用户访问继续指派到节点A，轮询分配访问请求实现负载均衡效果
static-rr：权重轮询 基于权重进行轮询,与roundrobin类似,但是为静态方法,在运行时调整其服务器权重不会生效.不过,其在后端服务器连接数上没有限制 leastconnections：最少连接数优先新的连接请求被派发至具有最少连接数目的后端服务器. 此算法会将新的连接请求转发到具有最少连接数目的后端服务器。在会话时间较长的场景中推荐使用此算法 ，例如数据库负载均衡最小连接数算法，根据后端的节点连接数大小动态分配前端请求 理解举例：
◆ 有三个节点A、B、C，各节点的连接数分别为A:4、B:5、C:6
◆ 第一个用户连接请求，会被指派到A上，连接数变为A:5、B:5、C:6
◆ 第二个用户请求会继续分配到A上，连接数变为A:6、B:5、C:6;再有新的请求会分配给B，每次将新的请求指派给连接数最小的客户端
◆ 由于实际情况下A、B、C的连接数会动态释放，很难会出现一样连接数的情况
◆ 此算法相比较rr算法有很大改进，是目前用到比较多的一种算法
source：请求源主机 IP 地址，基于请求源IP的算法。此算法先对请求的源IP进行HASH运算，然后将结果与后端服务器的权重总数相除后转发至某台匹配的后端服务器。这种方式可以使同一个客户端IP的请求始终转发到某特定的后端服务器基于来源访问调度算法，用于一些有Session会话记录在服务器端的场景，可以基于来源的IP、Cookie等做集群调度 理解举例:
◆ 有三个节点A、B、C，第一个用户第一次访问被指派到了A，第二个用户第一次访问被指派到了B
◆ 当第一个用户第二次访问时会被继续指派到A，第二个用户第二次访问时依旧会被指派到B，只要负载均衡调度器不重启，第一个用户访问都会被指派到A，第二个用户访问都会被指派到B，实现集群的调度
◆ 此调度算法好处是实现会话保持，但某些IP访问量非常大时会引起负载不均衡部分节点访问量超大，影响业务使用
uri：请求 URI，此算法会对部分或整个URI进行HASH运算，再经过与服务器的总权重相除，最后转发到某台匹配的后端服务器上 uri_param：请求 URl 的参数，此算法会根据URL路径中的参数进行转发，这样可保证在后端真实服务器数据不变时，同一个用户的请求始终分发到同一台机器上 hdr(name)：根据 HTTP Request Hander 锁定每一次 HTTP 请求，此算法根据HTTP头进行转发，如果指定的HTTP头名称不存在，则使用roundrobin算法 进行策略转发 rdp-cookie(name)：根据据 Cookie 锁定并哈希每一次 TCP 请求四层负载均衡与七层负载均衡
四层负载均衡
以常见的 TCP 应用为例，负载均衡器在接收到第一个来自客户端的 SYN 请求时，会通过设定的负载均衡算法选择一个最佳的后端服务器，同时将报文中目标 IP 地址修改为后端服务器 IP，然后直接转发给该后端服务器，这样一个负载均衡请求就完成了。从这个过程来看，一个 TCP 连接是客户端和服务器直接建立的，而负载均衡器只不过完成了一个类似路由器的转发动作。在某些负载均衡策略中，为保证后端服务器返回的报文可以正确传递给负载均衡器，在转发报文的同时可能还会对报文原来的源地址进行修改。
七层负载均衡
这里仍以常见的 TCP 应用为例，由于负载均衡器要获取到报文的内容，因此只能先代替后端服务器和客户端建立连接，接着，才能收到客户端发送过来的报文内容，然后再根据该报文中特定字段加上负载均衡器中设置的负载均衡算法来决定最终选择的内部服务器。纵观整个过程，七层负载均衡器在这种情况下类似于一个代理服务器。
对比四层负载均衡和七层负载均衡运行的整个过程，可以看出，在七层负载均衡模式下， 负载均衡器与客户端及后端的服务器会分别建立一次 TCP 连接，而在四层负载均衡模式下， 仅建立一次 TCP 连接。由此可知，七层负载均衡对负载均衡设备的要求更高，而七层负载均衡的处理能力也必然低于四层模式的负载均衡。
ACL 规则
HAProxy 支持基于 ACL 规则的分发策略：
通过 ACL 规则检查客户端请求是否合法 符合 ACL 规则的客户端请求被提交到指定 backendACL 规则经常被用到 frontend section，使用方式：
acl <acl_name> <acl_method> -i [匹配的路径或文件] acl_name：自定义名称 <acl_method>：hdr_reg(host)、hdr_dom(host)、hdr_beg(host)、url_sub、url_dir、path_beg、path_end etc. [匹配的路径或文件]：支持使用正则表达式，e.g. .html .jpg .gifEXAMPLE：
acl www_policy hdr_reg(host) -i ^(www.z.cn|z.cn) acl bbs_policy hdr_dom(host) -i bbs.z.cn acl url_policy url_sub -i buy_sid= use_backend server_www if www_policy use_backend server_app if url_policy use_backend server_bbs if bbs_policy default_backend server_cache常与 ACL 规则一起使用配置参数有 use_backend 和 default_backend，两者均用于指定 backend。
use_backend：满足 ACL 规则的客户端请求就转发至该 backenddefault_backend：没有满足 ACL 规则的客户端请求转发至该 backendWeb 监控平台
HAProxy 支持基于 Web 的监控平台，可以查看 frontend 和 backend 的运行状态，当出现故障时，会通过不同颜色来展示故障信息，解决了故障报警问题。
Keepalived 虚拟路由器
KeepAlived 是一个使用 C 编写的，基于 VRRP 协议的高可用解决方案。通过 VIP 地址和心跳检测支持高可用功能，避免发生单点故障。
核心组件
VRRP Stack：VRRP 协议的实现 IPVS Wrapper：为 RS 集群中的服务器都生成 IPVS 规则 Checkers：对 IPVS 集群的 RS 做健康检查 控制组件：配置文件分析器，用来实现配置文件的分析和加载 I/O 复用器：管理 I/O 复用功能 内存管理组件：用来管理 Keepalived 高可用的内存管理VRRP 虚拟路由冗余协议
在现实网络环境，经常需要使用路由协议来完成主机定位，使用路由协议的方法常见有两种：
动态路由协议（e.g. RIP、OSPF） 在主机上配置静态路由显然，在主机上配置静态路由是更多用户可以使用的方式，用户可以在自己的机器上配置一个或多个网关条目。不过使用静态路由存在一个问题，因为大家都依赖于路由器的动态路由协议，所以当路由器处于单点状态并发生故障时，所有人的网络都会受到牵连。VRRP 协议的目的就是为了解决静态路由单点故障问题。
VRRP（Virtual Router Redundancy Protocol，虚拟路由冗余协议），该协议会对共享多存取访问介质（e.g. 以太网）上的主机设备的默认网关（Default Gateway）进行冗余备份，从而当其中一台路由设备宕机时，备份路由设备也能够及时接管路由转发任务。为用户提供了透明、可靠的网络服务质量。
VRRP 的工作机制
VRRP 协议的基本对象概念：VRRP 路由器和虚拟路由器，Master 路由器和 Backup 路由器。
VRRP 路由器：指运行 VRRP 协议的路由器，是物理实体 虚拟路由器：指由 VRRP 协议创建的、虚拟的逻辑路由器，一组 VRRP 路由器协同工作，共同构成一台虚拟路由器。虚拟路由器对外表现为一个固定的 VIP 和 MAC 地址， Backup 路由器：VRRP 路由器组中起到备份作用的路由器，可以存在任意个 Backup。 Master 路由器：为了保证高可用，VRRP 路由器通常存在多个，其中有且仅有一个是实际工作的，称为 Master 路由器。主要负责转发网关上的 IP 数据包以及响应 ARP 请求等路由工作，Master 并非是一成不变的，VRRP 通过竞选（Election）协议来动态的从 VRRP 路由器组中决策出 Master。Master 拥有一些特权，比如：拥有虚拟路由器的 VIP 和 MAC，客户端都是使用这个 VIP 地址来配置静态路由。 Backup 路由器：作为 Master 路由器的冗余，当 Master 出现故障或需要切换时替换成为新的 Master。高可用原理
每个 VRRP 路由器至少有一个 vrrp_instance，每个 vrrp_instance 都拥有 VRID 作为唯一标识。VRID 范围在 [0—255] 之间。VRRP 路由器的虚拟 MAC 地址由 VRID 组成，格式为 00-00-5E-00-01-[VRID]。
当 Master 激活时，由 Master 负责使用自己的 MAC 来应答 ARP 请求；当 Master 失效时，选举出一个 Backup 负责响应 ARP 请求（把 VIP 绑定到自己的网卡上）并暂时升级为 Master。当 Master 恢复激活时又会重新接管 VIP， 实现了自动化的故障转移。这样的话，无论 Master 如何在 VRRP 路由器中切换，都能保证 ARP 响应给客户端的 VIP 地址对应的 MAC 地址的拥有者始终是激活的。而且客户端不需要因为 Master 的切换而修改自己的静态路由配置，对于客户端主机而言，这种主从切换是透明的。
VRRP 控制报文只有 VRRP 通告（Advertisement）一种。它使用 IP 多播数据包进行封装，组地址为 224.0.0.18，只限于同一 LAN 内发布，保证 VRID 在不同 LAN 中可以重用。为了减少网络带宽消耗，所以只有 Master 可以周期性的发送 VRRP 通告报文。如果 Backup 在连续三个通告间隔内依旧收不到 VRRP 通告，或者收到优先级为 0 的通告后，就是启动新的一轮 Master 选举。
高可用模式
主从模式：单虚拟路由器，只有一个 VIP，当 Master 出现故障时，VIP 漂移到 Backup 上。e.g. 192.168.0.7 是一个 VIP 在两台服务器之间漂移。
主主模式：多虚拟路由器，两个 VIP，一个 VRRP 路由器拥有两个 vrrp_instance。当其中一个 Master 故障时，它的 VIP 就漂移到另一台 Master 上（此时有两个 VIP）。当故障恢复后，再将 VIP 重新漂移过来。e.g. 192.168.10.141 和 192.168.10.142 是两个 VIP，可以在两台 Master 之间漂移.
健康检查原理
Keepalived 同样支持后端服务器集群的健康状态，如果有 Real Server 出现故障，Keepalived 会及时的检测到并将其从集群剔除。当故障的 Real Server 恢复后，Keepalived 又会自动将其加入集群。这些工作由 Keepalived 自动完成，无需人工干涉，运维人员需要做的只是修复发生故障的 Real Server。
Keepalived 支持 L3, L4 及 L5 层网络的健康检查：
L3：Keepalived 定期向 backend 发送 ICMP 数据包（PING）如果发现某台 Real Server 的 IP 地址没有激活，Keepalived 就会报告该 Server 失效，并将它从 backend 中剔除。L3 的工作就是通过 IP 地址是否有效来判断 Real Server 是否正常工作。
L4：主要以 TCP 端口状态来判断 Real Server 是否正常工作。例如：apache service 的端口一般是 80，如果 Keepalived 检测到 80 端口没有启用，则判断该 Real Server 失效，将其从 backend 中剔除。
L5：工作在应用层，比 L3、L4 要复杂一些，占用的带宽也更大。Keepalived 根据用户预设的业务服务应用程序运行是否正常判断 Real Server 是否正常工作，如果应用程序的运行状态与预设的不符，则将其从 backend 中剔除。
HAProxy & Keepalived
HAProxy & Keepalived 组合成为高可用负载均衡解决方案。由 HAProxy 提供 backend 划分和负载均衡；由 Keepalived 提供负载均衡服务器的高可用以及 Real Server 集群的健康检查。
Haproxy 环境搭建（基于Centos7.x）
服务器IP地址软件部署HAproxy-maste10.0.0.11haproxy+keepalivedHAproxy-backup10.0.0.12haproxy+keepalivedweb110.0.0.13nginxweb210.0.0.14nginxHaproxy的安装
# 需要配置epel源 # 安装HAproxy软件，主备都要安装 [root@haproxy-master ~]# yum install -y haproxy [root@haproxy-backup ~]# yum install -y haproxyHaproxy配置配置文件
# [root@haproxy-master opt]# vim /etc/haproxy/haproxy.cfg global log 127.0.0.1 local2 # 定义haproxy日志输出设置 log 127.0.0.1 local1 notice ulimit-n 65535 # 设置每个进程的可用的最大文件描述符 maxconn20480 # 默认最大连接数 chroot /var/lib/haproxy# chroot运行路径 user haproxy # 运行haproxy 用户 grouphaproxy # 运行haproxy 用户组 daemon # 以后台形式运行harpoxy nbproc 1 # 设置进程数量 pidfile /var/run/haproxy.pid# haproxy 进程PID文件 defaults modehttp# 所处理的类别(7层代理http，4层代理tcp) log global# 引入global定义的日志格式 maxconn 10140 # 最大连接数 optionhttplog # 日志类别为http日志格式 optionhttp-server-close #每次请求完毕后主动关闭http通道 optiondontlognull # 不记录健康检查日志信息 optionforwardfor# 如果后端服务器需要获得客户端的真实ip，需要配置的参数， # 可以从http header 中获取客户端的IP retries 3 # 3次连接失败就认为服务器不可用，也可以通过后面设置 option redispatch #《---上述选项意思是指serverID对应的服务器挂掉后，强制定向到其他健康的服务器, 当使用了cookie时，haproxy将会将其请求的后端服务器的serverID插入到cookie中，以保证会话的SESSION持久性；而此时，如果后端的服务器宕掉了,但是客户端的cookie是不会刷新的，如果设置此参数，将会将客户的请求强制定向到另外一个后端server上，以保证服务的正常---》 stats refresh 30 #设置统计页面刷新时间间隔 option abortonclose#当服务器负载很高的时候，自动结束掉当前队列处理比较久的连接 balance roundrobin #设置默认负载均衡方式，轮询方式 #balance source#设置默认负载均衡方式，类似于nginx的ip_hash #contimeout 5000#设置连接超时时间 #clitimeout 50000 #设置客户端超时时间 #srvtimeout 50000 #设置服务器超时时间 timeout http-request10s#默认http请求超时时间 timeout queue 1m #默认队列超时时间 timeout connect 10s#默认连接超时时间 timeout client1m #默认客户端超时时间 timeout server1m #默认服务器超时时间 timeout http-keep-alive 10s#默认持久连接超时时间 timeout check 10s#设置心跳检查超时时间 frontend http_80_in bind 0.0.0.0:80#设置监听端口，即haproxy提供的web服务端口，和lvs的vip 类似 mode http#http 的7层模式 log global #应用全局的日志设置 option httplog #启用http的log option httpclose #每次请求完毕后主动关闭http通道，HAproxy不支持keep-alive模式 # 在 HTTP 头部添加 X-Forwarded-For，使得后端服务器可以获取原始请求的 Source IP option forwardfor#如果后端服务器需要获得客户端的真实IP需要配置此参数，将可以从HttpHeader中获得客户端IP # 在 HTTP 头部添加 X-Forwarded-Port，使得后端服务器可以知道原始请求的 Source Port http-request set-header X-Forwarded-Port %[dst_port] # 在使用 SSL 时添加 X-Forwarded-Proto http-request add-header X-Forwarded-Proto https if { ssl_fc } # ACL 匹配域，结果为 True or False # acl url_staticpath_end -i .html .jpg .gif # acl url_dynamic path_end -i .php acl html url_reg-i\.html$ # 根据 acls 规则得到的布尔值来决定分发的 backend use_backendhttpservers if html default_backend httpservers # 设置请求默认转发的后端服务池 backend httpservers# 定义 httpservers 服务器组。 mode http# http的7层模式 optionredispatch optionabortonclose balanceroundrobin #负载均衡的方式，轮询算法，为了看效果实验用轮询算法 # balance source#负载均衡的方式，源哈希算法 cookieSERVERID#允许插入serverid到cookie中，serverid后面可以定义 optionhttpchk GET /index.html #心跳检测 # 后端业务服务器清单 serverhttp1 10.0.0.14:80 maxconn 2000 cookie server1 weight 1check inter 1s rise 2 fall 2 serverhttp2 10.0.0.15:80 maxconn 2000 cookie server2 weight 1check inter 1s rise 2 fall 2 listenadmin_status#Frontend和Backend的组合体,监控组的名称，按需自定义名称 bind 0.0.0.0:8888#监听服务端口-HAproxy后台管理页面，这个端口可自定义设置，不可用已占用端口 # option httpchk GET /index.html # 后端真实主机监控检查方式 mode http#http的7层模式 log 127.0.0.1 local3 err #错误日志记录 stats refresh 5s #每隔5秒自动刷新监控页面 stats uri /proxy #监控页面的url访问路径，自定义访问路径 stats realm Haproxy\ welcome #监控页面的提示信息 stats auth admin:admin #监控页面的用户和密码admin,可以设置多个用户名 stats auth admin1:admin1 #监控页面的用户和密码admin1 stats hide-version #隐藏统计页面上的HAproxy版本信息 stats admin if TRUE#手工启用/禁用,后端服务器(haproxy-1.4.9以后版本)修改完配置文件，重启服务器
# 语法检查 [root@lb_master ~]# haproxy -c -f /etc/haproxy/haproxy.cfg Configuration file is valid [root@haproxy-master opt]# systemctl restart haproxy [root@haproxy-master opt]# systemctl status haproxy ● haproxy.service - HAProxy Load Balancer Loaded: loaded (/usr/lib/systemd/system/haproxy.service; disabled; vendor preset: disabled) Active: active (running) since 三 2021-04-28 16:13:56 CST; 6s ago# 状态是running说明配置成功 Main PID: 76984 (haproxy-systemd) CGroup: /system.slice/haproxy.service ├─76984 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid ├─76985 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds └─76986 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds 4月 28 16:13:56 haproxy-master systemd[1]: Started HAProxy Load Balancer. 4月 28 16:13:56 haproxy-master haproxy-systemd-wrapper[76984]: haproxy-systemd-wrapper: executing /usr/sb...Ds Hint: Some lines were ellipsized, use -l to show in full.访问10.0.0.12:8888/proxy,看到以下页面，输入配置的用户名和密码
至此，HAproxy服务搭建完毕
只有上面的搭建成功后，才能继续下面的keepalived+HAproxy搭建双主热备高可用集群
Haproxy配置详解
global部分：
通常主要定义全局配置主要用于设定义全局参数，属于进程级的配置，通常和操作系统配置有关。
global log 127.0.0.1 local2 info pidfile /var/run/haproxy.pid maxconn 4096 userhaproxy group haproxy daemon nbproc1 □ log:全局的日志配置，local0是日志设备，info 表示日志级别。其中日志级别有err、warning、info、debug四种可选。这个配置表示使用127.0.0.1上的rsyslog服务中的local0日志设备，记录日志等级为 info log指定收集哪个机器的log，log的收集是通过系统工具来实现的，在centos6版本之前以syslog来收集日志，6版本变为了rsysylog。这些都是用于收集系统的日志，local 0指定设备，info表示输出日志的级别，error级别是在报错的时候才会输出。info只要有正常信息都会进行输出 口 maxconn:设定每个haproxy进程可接受的最大并发连接数，此选项等同于Linux命令行选项"ulimit -n" maxconn：可接受的最大并发连接数（不是最大连接数），注意是针对haproxy进程来说的，相当于操作系统的ulimit -n，如果设置了maxconn 4096，那么linux ulimit -n 也要设置为大于等于4096 口 user/group:设置运行haproxy进程的用户和组，也可使用用户和组的uid和gid值来替代 口 nbproc:设置HAProxy启动时可创建的进程数,此参数要求将 HAProy运行模式设 置为"daemon"，默认只启动一个进程。根据使用经验,该值的设置应该小于服务器的CPU核数。创建多个进程能够减少每个进程的任务队列，但是过多的进程可能会导致进程的崩溃。 nbproc 1#工作进程数量cpu内核是几就写几 这个参数重要，设置haproxy启动的进程数。默认值是1，默认启动一个进程，如果访问量比较大需要将该值增加，这个值大小一般建议设置小于服务器cpu的核数，这个核数是物理核不是逻辑核，如两个4核cpu那就是8个核，也就是这个值最多设置为8，而不是通过超线程来实现。 创建过多的进程并不一定会有好的效果，进程数不能太大，也不能太小，最大不要超过cpu核数 创建过多的进程并不一定会有好的效果，进程数不能太大，也不能太小，最大不要超过cpu核数 口 pidfle:指定haproxy进程的pid文件,启动进程的用户必须有访问此文件的权限default部分：
用于设置配置默认参数，这些参数可以被用到frontend，backend，listen组件。
在此部分中设置的参数值，默认会自动引用到下面的frontend、backend、listen部分中。如果某些参数属于公用的配置，只需要在defaults部分添加一次即可。而如果frontend、backend、listen部分也配置了与defaults部分一样的参数，defaults部分参数对应的值自动被覆盖
口 mode∶设置HAPoy实例默认的运行模式，有tcp、http、heath三个可选值。 口 tcp模式∶在此模式下，客户端和服务器端之间将建立一个全双工的连接，不 会对七层报文做任何类型的检查，默认为tcp模式，经常用于SSL、SSH、SMTP 等应用。 口 http模式∶在此模式下，客户端请求在转发至后端服务器之前将会被深度分析， 所有不与 RFC格式兼容的请求都会被拒绝。 口 health模式∶目前此模式基本已经废弃，不在多说。 口 retres∶设置连接后端服务器的失败重试次数。连接失败的次数如果超过这里设置 的值，HAProy 会将对应的后端服务器标记为不可用。此参数也可在后面backend部分进行设置. #健康检查。3次连接失败就认为服务器不可用，主要通过后面的check检查 口 timeout connect∶haproxy与后端服务器连接超时时间，如果在同一个局域网可设置较小的时间 口 timeout client∶与客户端的最长空闲时间,定义客户端与haproxy连接后，数据传输完毕，不再有数据传输，即非活动连接的超时时间 口 timeout server∶定义haproxy与上游服务器非活动连接的超时时间 口 timeout http-keep-alive:使用keepAlive连接 contimeout 5000：设置成功连接到一台服务器的最长等待时间，默认单位是毫秒，新版本的haproxy使用timeout connect替代，该参数向后兼容。 clitimeout 3000：设置连接客户端发送数据时的成功连接最长等待时间，默认单位是毫秒，新版本haproxy使用timeout client替代。该参数向后兼容。 srvtimeout 3000：设置服务器端回应客户度数据发送的最长等待时间，默认单位是毫秒，新版本haproxy使用timeout server替代。该参数向后兼容。fronted部分 ：
frontend是在haproxy 1.3版本以后才引入的一个组件，同时引入的还有backend组件。通过引入这些组件，在很大程度上简化了haproxy配置文件的复杂性。forntend可以根据ACL规则直接指定要使用的后端backend。
这是HAProxy 配置文件的第三部分—fronted部分的配置 这部分通过 frortend 关键字定义了一个名为"web"的前端虚拟节点，下面介绍每个选项的含义。 口 bind *:81 监听端口，即haproxy提供web服务的端口，和lvs的vip端口类似 口 option httplog∶option httplog默认情况下haproxy不会记录http请求的，这不便于haproxy出现问题时候的排查与监控，这个就是记录http请求的日志，这个参数比较重要建议打开。 口 option forwardfor：HAProxy工作于反向代理模式，其发往服务器的请求中的客户端IP均为HAProxy主机的地址而非真正客户端的地址，这会使得服务器端的日志信息记录不了真正的请求来源，“X-Forwarded-For”首部则可用于解决此问题。HAProxy可以向每个发往服务器的请求上添加此首部，并以客户端IP为其value。（记录客户端IP在X-Forwarded-For头域中）如果后端服务器需要获得客户端真实ip需要配置的参数，可以从Http Header中获得客户端ip 口 option httpclose # 每次请求完毕后主动关闭http通道，HA-Proxy不支持keep-alive模式 口 log global∶表示使用全局的日志配置，这里的"global"表示引用在HAPoxy配置文件global部分中定义的log选项配置格式 口defaut backend∶指定默认的后端服务器池，也就是指定一组后端真实服务器，而这些真实服务器组将在backend段进行定义 口 acl html url_reg-i\.html$配置acl策略 口 use_backend httpservers ifhtml与acl策略匹配相应backend部分：
backend用于定义一个名称为htmpool的后端服务器组，根据需要可以定义多个
backend httpservers optionredispatch optionabortonclose balance roundrobin cookieSERVERID SERVERID insert indirect nocache optionhttpchk GET /index.html serverhttp1 192.168.179.103:80 maxconn 2000 cookie server1 weight 1check inter 1s rise 2 fall 2 serverhttp2 192.168.179.104:80 maxconn 2000 cookie server2 weight 1check inter 1s rise 2 fall 2option redispatch此参数用于cookie保持的环境中。在默认情况下，HAProxy会将其请求的后端服务器的serverID插入cookie中，以保证会话的session持久性。而如果后端服务器出现故障，客户端的cookie是不会刷新的，这就会造成无法访问。此时，如果设置了此参数，就会将客户的请求强制定向到另外一台健康的后端服务器上，以保证服务正常 option abortonclose此参数可以在服务器负载很高的情况下，自动结束当前队列中处理时间比较长的连接 balance设置负载均衡算法 HAProxy支持的负载均衡算法：roundrobin ：基于权重进行轮叫调度的算法
static-rr ： 基于权重进行轮叫调度的算法，不过此算法为静态算法，在运行时调整其服务器权重不会生效
source：基于请求源IP的算法。此算法先对请求的源IP进行HASH运算，然后将结果与后端服务器的权重总数相除后转发至某台匹配的后端服务器。这种方式可以使同一个客户端IP的请求始终转发到某特定的后端服务器
leastconn：此算法会将新的连接请求转发到具有最少连接数目的后端服务器。在会话时间较长的场景中推荐使用此算法 ，例如数据库负载均衡
uri:此算法会对部分或整个URI进行HASH运算，再经过与服务器的总权重相除，最后转发到某台匹配的后端服务器上
uri_param:此算法会根据URL路径中的参数进行转发，这样可保证在后端真实服务器数据不变时，同一个用户的请求始终分发到同一台机器上
hdr:此算法根据HTTP头进行转发，如果指定的HTTP头名称不存在，则使用roundrobin算法 进行策略转发
cookie SERVERID表示允许向cookie插入SERVERID，每台服务器的SERVERID可在下面的server关键字中使用cookie关键字定义 option httpchk GET /index.html心跳检测的文件； 此选项表示启用 HTTP 的服务状态检测功能。HAProxy 作为一款专业的负载均衡器，它支持对 backend 部分指定的后端服务节点的健康检查，以保证在后端 backend 中某个节点不能服务时，把从 frotend 端进来的客户端请求分配至 backend 中其他健康节点上，从而保证整体服务的可用性。“option httpchk”的用法如下： option httpchk其中，各个参数的含义如下： serverhttp1 192.168.179.103:80 maxconn 2000 cookie server1 weight 1check inter 3s rise 2 fall 3 服务器定义，cookie server1表示serverid为server1，check inter 1s是检测心跳频率，rise 3是3次正确认为服务器可用，fall 3是3次失败认为服务器不可用，weight代表权重 server http2 192.168.179.104:80 maxconn 2000 cookie server2 weight 1check inter 3s rise 2 fall 3 服务器定义，cookie server2表示serverid为server2，check inter 3s是检测心跳频率，rise 3是3次正确认为服务器可用，fall 3是3次失败认为服务器不可用，weight代表权重server：这个关键字用来定义多个后端真实服务器，不能用于 defaults 和frontend部分。使用格式为：server
[:port] [param*] 其中，每个参数含义如下：
check：表示启用对此后端服务器执行健康状态检查。
inter：设置健康状态检查的时间间隔，单位为毫秒。
rise：设置从故障状态转换至正常状态需要成功检查的次数，例如。“rise 2”表示 2 次检查正确就认为此服务器可用。
fall：设置后端服务器从正常状态转换为不可用状态需要检查的次数，例如，“fall 3”表示 3 次检查失败就认为此服务器不可用。
cookie：为指定的后端服务器设定 cookie 值，此处指定的值将在请求入站时被检查，第一次为此值挑选的后端服务器将在后
listen 部分
常常用于状态页面监控，以及后端server检查,此部分是 frontend 部分和 backend 部分的结合体。
在 HAProxy1.3 版本之前，HAProxy 的所有配置选项都在这个部分中设置。为了保持兼容性，HAProxy 新的版本仍然保留了 listen 组件的配置方式。目前在 HAProxy 中，两种配置方式任选其一即可。
这个部分通过listen 关键字定义了一个名为“admin_stats”的实例，其实就是定义了一个 HAProxy 的监控页面，每个选项的含义如下：
stats refresh：设置 HAProxy 监控统计页面自动刷新的时间。
stats uri：设置 HAProxy 监控统计页面的URL 路径，可随意指定。例如、指定“stats uri /haproxy-status”，就可以过 http://IP:9188/haproxy-status查看。
stats realm：设置登录 HAProxy 统计页面时密码框上的文本提示信息。
stats auth：设置登录 HAProxy 统计页面的用户名和密码。用户名和密码通过冒号分割。可为监控页面设置多个用户名和密码，每行一个。
stats hide-version：用来隐藏统计页面上 HAProxy 的版本信息。
stats admin if TRUE：通过设置此选项，可以在监控页面上手工启用或禁用后端真实服务器，仅在 haproxy1.4.9 以后版本有效。
# 本例配置是某个后端服务，相当于fronted与backend的结合体 listen fk_api bind *:5000 balanceroundrobin mode http option httplog logglobal option redispatch option abortonclose server fk1 172.17.67.27:5000 maxconn 2000check inter 1s rise 3 fall 3 server fk2 172.17.67.31:5000 maxconn 2000check inter 1s rise 3 fall 3Haproxy 日志的配置
两台机器都配置haproxy的日志:需要打开注释并添加 （如果有backup，backup上面也需要配置）
[root@haproxy-master ~]# yum install -y rsyslog# 如果系统没有 [root@haproxy-master ~]# vim /etc/rsyslog.conf # Provides UDP syslog reception#由于haproxy的日志是用udp传输的，所以要启用rsyslog的udp监听 $ModLoad imudp $UDPServerRun 514 找到#### RULES #### 下面添加 local2.* /var/log/haproxy.log # 重启rsyslog服务 [root@haproxy-master ~]# systemctl restart rsyslog # 重启HAproxy服务 [root@haproxy-master ~]# systemctl restart haproxy # 查看日志 [root@haproxy-master ~]# tail -f /var/log/haproxy.log#实时查看日志 Apr 28 12:12:34 haproxy-master systemd: Stopping HAProxy Load Balancer... Apr 28 12:12:34 haproxy-master haproxy-systemd-wrapper: haproxy-systemd-wrapper: exit, haproxy RC=0 Apr 28 12:12:34 haproxy-master systemd: Stopped HAProxy Load Balancer. Apr 28 12:12:34 haproxy-master systemd: Started HAProxy Load Balancer. Apr 28 12:12:34 localhost haproxy[62764]: Proxy stats started. Apr 28 12:12:34 localhost haproxy[62764]: Proxy web started. Apr 28 12:12:34 localhost haproxy[62764]: Proxy web started. Apr 28 12:12:34 localhost haproxy[62764]: Proxy httpservers started.Haproxy参数优化
随着企业网站负载增加，haproxy参数优化相当重要
优化参数含义maxconn最大连接数，根据应用实际情况进行调整，推荐使用10240daemon守护进程模式，Haproxy可以使用非守护进程模式启动，建议使用守护进程模式启动nbproc负载均衡的并发进程数，建议与当前服务器CPU核数相等或为其2倍retries重试次数，主要用于对集群节点的检查，如果节点多，且并发量大，设置为2次或3次option http-server-close主动关闭http请求选项，建议在生产环境中使用此选项timeout http-keep-alive长连接超时时间，设置长连接超时时间，可以设置为10stimeout http-requesthttp请求超时时间，建议将此时间设置为5～10s，增加http连接释放速度timeout client客户端超时时间，如果访问量过大，节点响应慢，可以将此时间设置短一些，建议设置为1min左右就可以了HAproxy+keepalived搭建双主热备高可用集群
部署keepalived
yum install -y haproxy # backup服务器部署HAproxy并修改配置文件，同上 yum install -y keepalived# master 和 backup都要部署HA1-master服务器keepalived配置文件
! Configuration File for keepalived global_defs { router_id proxy-master# 自定义id不能重复 } # 定义脚本名字和脚本执行的间隔和脚本执行的优先级变更 vrrp_script chk_haproxy { script "/etc/keepalived/check_haproxy.sh" interval 10# 每10秒执行一次检查脚本 # weight 2 } # 实例1 是MASTER服务 vrrp_instance VI_1 {# 实例名称也可以自定义，主从必须一致 state MASTER# 配置 HA1 为 Master interface eth0# 网卡名称根据自己的改 virtual_router_id 51# 虚拟路由id，主从必须一致 配置同一个 VRID，范围在 [0-255] 之间 priority 100# 优先级，MASTER比BACKUP高即可，数字差距尽量大一些 advert_int 1 authentication { auth_type PASS # 主从保持一致 auth_pass 1111 # 主从保持一致 } track_script { # 引用脚本 chk_haproxy# 脚本名称与上面定义的名称必须一致 } virtual_ipaddress { # 虚拟ip地址 10.0.0.100/8 # 根据自己的修改 } } # 实例2 是BACKUP服务器 vrrp_instance VI_2 {# 实例名称也可以自定义，主从必须一致 state BACKUP# 置 HA1 为BACKUP interface eth0# 网卡名称根据自己的改 virtual_router_id 61# 虚拟路由id，主从必须一致 priority 50# 优先级，MASTER比BACKUP高即可，数字差距尽量大一些 advert_int 1 authentication { auth_type PASS # 主从保持一致 auth_pass 1112 # 主从保持一致 } virtual_ipaddress { # 虚拟ip地址 10.0.0.200/8 # 根据自己的修改 } }
HA2-backup服务器keepalived配置文件
! Configuration File for keepalived global_defs { router_id proxy-backup# 自定义id不能重复 } # 定义脚本名字和脚本执行的间隔和脚本执行的优先级变更 vrrp_script chk_haproxy { script "/etc/keepalived/check_haproxy.sh" # 每5秒执行一次检查脚本 interval 10 # weight 2 } # 实例1 是BACUP服务 vrrp_instance VI_1 {# 实例名称也可以自定义，主从必须一致 state BACKUP# 设置 HA2 为 Backup interface eth0# 网卡名称根据自己的改 virtual_router_id 51# 虚拟路由id，主从必须一致 priority 50# 优先级地于master advert_int 1 authentication { auth_type PASS # 主从保持一致 auth_pass 1111 # 主从保持一致 } virtual_ipaddress { # 虚拟ip地址 10.0.0.100/8# 根据自己的修改 } } # 实例2 是 MASTER 服务器 vrrp_instance VI_2 {# 实例名称也可以自定义，主从必须一致 state MASTER# 设置 HA2 为 MASTER interface eth0# 网卡名称根据自己的改 virtual_router_id 61# 虚拟路由id，主从必须一致 priority 100 # 优先级，MASTER比BACKUP高即可，数字差距尽量大一些 advert_int 1 authentication { auth_type PASS # 主从保持一致 auth_pass 1112 # 主从保持一致 } track_script { # 引用脚本 chk_haproxy# # 脚本名称与上面定义的名称必须一致 } virtual_ipaddress { # 虚拟ip地址 10.0.0.200/8 # 根据自己的修改 } }
chk_haproxy脚本
以上我们只是实现了高可用，基于Haproxy的前提是Haproxy服务正常。如果有突发情况使得HAproxy服务不能启动，但是我们的keepalived服务是正常，这个时候用户是访问不到的，VIP也不会自动漂移到备用的节点服务器上。所以我们需要写一些代码来判断一下Haproxy服务是不是正常，如果不正常的话我们就将keepalived服务关掉，然后实现VIP的漂移，这个时候用户就不会出现无法访问的情况了。
# 让Keepalived以一定时间间隔执行一个外部脚本，脚本的功能是当Haproxy失败，则关闭本机的Keepalived # vim /etc/keepalived/chk_haproxy.sh #!/bin/bash # 具体端口和路径根据HAproxy提供的web服务设置来定 # 举例:如果是8080端口提供的admin页面，则应该为 curl -I :8080/admin # 或者 curl -I # /usr/bin/curl -I [:PORT][PATH] &>/dev/null # 具体端口根据HAproxy提供的web服务设置 for i in `seq 1 5` do curl -I&>/dev/null # 如果访问测试不通过 if [ $? -ne 0 ] then let m+=1 # echo "`date`${m}" >> /opt/m.txt sleep 1# 睡1秒 # 测试两次失败则重启HAproxy服务 if [ ${m} -eq 2 ] then # 重启HAproxy服务 systemctl restart haproxy # 重启成功则继续进行下一次检查 if [ $? -eq 0 ] then echo "`date`haproxy restart successfully" >> /opt/m.txt else # 重启失败则，停止keepalived服务 systemctlstopkeepalived exit fi # else fi # 测试失败3次则停止keepalived服务 if [ ${m} -ge 3 ] then # 停止keepalived服务 # /etc/init.d/keepalived stop systemctlstop keepalived exit # else fi else # 检测通过则跳出循环 break fi done # 授权脚本执行权限 chmod a+x /etc/keepalived/chk_haproxy.sh #一定要加执行权限 # 配置keepalived使用script # vim /etc/keepalived/keepalived.conf # 示例如下 ! Configuration File for keepalived global_defs { router_id director1 } # 定义脚本名字和脚本执行的间隔和脚本执行的优先级变更 vrrp_script check_haproxy { script "/etc/keepalived/chk_haproxy.sh" interval 5#每5秒执行一次 # weight 10 #脚本结果导致的优先级变更：10表示优先级+10；-10则表示优先级-10 } vrrp_instance VI_1 { state MASTER interface ens33 virtual_router_id 80 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.13.144/24 } track_script { # 引用脚本 check_haproxy } }注：必须先启动Haproxy，再启动keepalived，建议备用节点也添加上.
启动keepalived服务，主从都要启动
systemctl start keepalived systemctl enable keepalivedmaster检查ip地址
backup检查ip地址
访问vip测试
关闭master服务器的keepalived服务
[root@haproxy-master opt]# systemctl stop keepalived浏览器访问vip1：10.0.0.100vip2: 10.0.0.200均能正常访问
关闭backup服务器keepalived服务
浏览器访问vip1：10.0.0.100vip2: 10.0.0.200均能正常访问
至此，HAproxy+keepalived双主热备高可用集群搭建完毕