2021-7-27-负载均衡学习记录

负载均衡

1，Linux负载均衡（lvs，nginx，haproxy）、中间价

1.1，负载均衡的概念

1、系统的扩展方式：

​ scale up：向上扩展

​ scale out：向外扩展

2、集群类型： LB（Load Balancing）、HA（high availability）

3、LB集群的实现

​ 硬件：F5、Redware

​ 软件：lvs、haproxy、nginx

4、基于工作的协议层划分：

​ 传输层：

​ Lvs：工作在内核模块中

​ HAProxy：

1.mode tcp，如果工作在应用层只能调度http协议，如果基于tcp协议它能够调度https，mysql等常用的tcp协议

2.haproxy只是模拟tcp协议，因为tcp协议工作在内核当中，而haproxy属于应用程序工作在第七层，是工作在某个套接字上的应用程序

应用层：haproxy，nginx

从负载均衡设备的角度来看，分为硬件负载均衡和软件负载均衡：

硬件负载均衡：比如最常见的F5，还有Array等，这些负载均衡是商业的负载均衡器，性能比较好，毕竟他们的就是为了负载均衡而生的，背后也有非常成熟的团队，可以提供各种解决方案，但是价格比较昂贵。

软件负载均衡：包括我们耳熟能详的Nginx，LVS，Tengine（阿里对Nginx进行的改造）等。优点就是成本比较低，但是也需要有比较专业的团队去维护。

从负载均衡的技术来看，分为服务端负载均衡和客户端负载均衡：

服务端负载均衡：当我们访问一个服务，请求会先到另外一台服务器，然后这台服务器会把请求分发到提供这个服务的服务器，当然如果只有一台服务器，那好说，直接把请求给那一台服务器就可以了，但是如果有多台服务器呢？这时候，就会根据一定的算法选择一台服务器。

客户端负载均衡：客户端服务均衡的概念貌似是有了服务治理才产生的，简单的来说，就是在一台服务器上维护着所有服务的ip，名称等信息，当我们在代码中访问一个服务，是通过一个组件访问的，这个组件会从那台服务器上取到所有提供这个服务的服务器的信息，然后通过一定的算法，选择一台服务器进行请求。

1.2，三大主流软件负载均衡器对比(LVS、Nginx、HAproxy)

1、LVS：

1. 抗负载能力强，性能高，能达到F5的60%，对内存和CPU资源消耗比较低

2. 工作在网络4层，通过VRRP协议(仅作代理分发之用)，具体的流量是由linux内核来处理，因此没有流量的产生。

3. 稳定，可靠性高，自身有完美的热备方案(Keepalived+lvs)

4. 不支持正则处理，不能做动静分离；但应用范围比较广，可以对所有应用做负载均衡

5. 支持多种负载均衡算法：rr(轮询)，wrr(带权轮询)、lc(最小连接)、wlc(带权最小连接)

6. 配置相对复杂，对网络依赖比较大，稳定性很高。

7. LVS工作模式有4种：

(1) nat 地址转换

(2) dr 直接路由

(3) tun 隧道

(4) full-nat

2、Nginx：

1. 工作在网络7层，可以针对http应用做一些分流的策略，比如针对域名，目录结构

2. Nginx对网络的依赖较小，理论上能ping通就能进行负载功能

3. Nginx安装配置比较简单，测试起来很方便

4. 也可以承担较高的负载压力且稳定，nginx是为解决c10k问题而诞生的，一般能支撑超过1万次的并发

5. 对后端服务器的健康检查，只支持通过端口来检测，不支持通过url来检测

6. Nginx对请求的异步处理可以帮助节点服务器减轻负载压力

7. Nginx仅能支持http、https和Email协议，这样就在适用范围较小。

8. 不支持Session的直接保持，但能通过ip_hash来解决。对Big request header的支持不是很好。

9. Nginx还能做Web服务器即Cache功能。

10. 支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、Ip-hash（IP哈希）

第6点补充：

squid同步处理：浏览器发起请求，而后请求会立刻被转到后端，于是在浏览器和后台之间就建立了一个通道。从请求发起直到请求完成，这条通道都是一直存在的。

nginx异步处理：浏览器发起请求，请求不会立刻转到后端，而是请求数据(header)先收到nignx上，然后nginx再把这个请求发到后端，后端处理完成后把数据返回到nginx上，nginx将数据流发到浏览器。

使用异步处理的好处：

1. 假设用户执行一个上传文件操作，因为用户网速又比较慢，因此需要花半个小时才能把文件传到服务器。squid的同步代理在用户开始上传后就和后台建立了连接，半小时后文件上传结束，由此可见，后台服务器连接保持了半个小时；而nginx异步代理就是先将此文件收到nginx上，因此仅仅是nginx和用户保持了半小时连接，后台服务器在这半小时内没有为这个请求开启连接，半小时后用户上传结束，nginx才将上传内容发到后台，nginx和后台之间的带宽是很充裕的，所以只花了一秒钟就将请求发送到了后台，由此可见，后台服务器连接保持了一秒。同步传输花了后台服务器半个小时，异步传输只花一秒，可见优化程度很大。

2. 在上面这个例子中，假如后台服务器因为种种原因重启了，上传文件就自然中断了，这对用户来说是非常恼火的一件事情，想必各位也有上传文件传到一半被中断的经历。用nginx代理之后，后台服务器的重启对用户上传的影响减少到了极点，而nginx是非常稳定的并不需要常去重启它，即使需要重启，利用kill -HUP就可以做到不间断重启nginx。

3. 异步传输可以令负载均衡器更有保障，为什么这么说呢？在其它的均衡器（lvs/haproxy/apache等）里，每个请求都是只有一次机会的，假如用户发起一个请求，结果该请求分到的后台服务器刚好挂掉了，那么这个请求就失败了；而nginx因为是异步的，所以这个请求可以重新发往下一个后台，下一个 后台返回了正常的数据，于是这个请求就能成功了。还是用用户上传文件这个例子，假如不但用了nginx代理，而且用了负载均衡，nginx把上传文件发往 其中一台后台，但这台服务器突然重启了，nginx收到错误后，会将这个上传文件发到另一台后台，于是用户就不用再花半小时上传一遍。

4. 假如用户上传一个10GB大小的文件，而后台服务器没有考虑到这个情况，那么后台服务器岂不要崩溃了。用nginx就可以把这些东西都拦在nginx上，通过nginx的上传文件大小限制功能来限制，另外nginx性能非常有保障，就放心的让互联网上那些另类的用户和nginx对抗去吧。

用异步传输会造成问题：

后台服务器有提供上传进度的功能的话，用了nginx代理就无法取得进度，这个需要使用nginx的一个第三方模块来实现。

第8点补充：

Nginx upstream支持的分配策略及原理：

1. 轮询(默认)：每个请求按照顺序逐一分配到不同的后端服务器。如后端服务器down掉，就切换到另一台并剔除down的后端主机

2. weight：指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。

3. ip_hash：每个请求按照访问ip的hash结果分配，不同ip的请求被分配到后端不同的服务器上，可以解决session的问题。

3、HAProxy:

1. 支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机；

2. 能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作

3. 支持url检测后端的服务器出问题的检测会有很好的帮助。

4. 更多的负载均衡策略比如：动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现

5. 单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。

6. HAProxy可以对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。

7. 支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、source（原地址保持）、RI（请求URL）、rdp-cookie（根据cookie）

8. 不能做Web服务器即Cache。

三大主流软件负载均衡器适用业务场景：

1. 网站建设初期，可以选用Nginx、HAProxy作为反向代理负载均衡(流量不大时，可以不选用负载均衡)，因为其配置简单，性能也能满足一般业务场景。如果考虑到负载均衡器是有单点问题，可以采用Nginx+Keepalived/HAproxy+Keepalived避免负载均衡器自身的单点问题。

2. 网站并发到达一定程度后，为了提高稳定性和转发效率，可以使用lvs，毕竟lvs比Nginx/HAProxy要更稳定，转发效率也更高。

注：nginx与HAProxy比较：nginx只支持七层，用户量最大，稳定性比较可靠。Haproxy支持四层和七层，支持更多的负载均衡算法，支持session等。

衡量负载均衡器好坏的几个重要的因素：

1. 会话率 ：单位时间内的处理的请求数

2. 会话并发能力：并发处理能力

3. 数据率：处理数据能力

1.3、中间件

在众多关于中间件的定义中，比较普遍被接受的是 IDC 表述的：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。

分类：数据访问中间件，远程调用中间件，消息中间件，交易中间件，对象中间件。

举例：

1. RMI (Remote Method Invocations, 远程调用)

2. Load Balancing(负载均衡，将访问负荷分散到各个服务器中)

3. Transparent Fail-over(透明的故障切换)

4. Clustering(集群 , 用多个小的服务器代替大型机)

5. Back-end-Integration(后端集成，用现有的、新开发的系统如何去集成遗留的系统)

6. Transaction 事务(全局 / 局部)全局事务(分布式事务)局部事务(在同一数据库联 接内的事务)

7. Dynamic Redeployment (动态重新部署 , 在不停止原系统的情况下，部署新的系统)

8. System Management(系统管理)

9. Threading(多线程处理)

10. Message-oriented Middleware 面向消息的中间件(异步的调用编程)

11. Component Life Cycle(组件的生命周期管理)

12. Resource pooling (资源池)

13. Security (安全)

14. Caching (缓存)

1.4，cookie和session

​ 1、Cookie是服务器存储在本地计算机上的小块文本，并随每个请求发送到同一服务器。 IETF RFC 2965 HTTP状态管理机制是一种通用的cookie规范。 Web服务器使用HTTP标头将cookie发送到客户端。在客户端终端，浏览器解析cookie并将其保存为本地文件，该文件自动将来自同一服务器的任何请求绑定到这些cookie。

​ 具体来说，cookie机制使用一种在客户端维护状态的方案。它是客户端会话状态的存储机制，他需要用户打开客户端的cookie支持。 Cookie的作用是解决HTTP协议中缺少无状态缺陷的问题。

​ 2、session会话机制是一种服务器端机制，它使用类似于哈希表（可能还有哈希表）的结构来保存信息。

​ 当程序需要为客户端的请求创建会话时，服务器首先检查客户端的请求是否包含会话标识符（称为会话ID）。如果包含它，它先前已为此客户端创建了一个会话。服务器根据会话ID检索会话（无法检索，将创建新会话），如果客户端请求不包含会话ID，则为客户端创建会话并生成与会话关联的会话ID。 session id应该是一个既不重复也不容易被复制的字符串。会话ID将返回给客户端以保存此响应。

​ 3、Session是保存在服务器上的数据结构，用于跟踪用户的状态。此数据可以保存在群集、数据库、文件中。

​ Cookie是客户端存储用户信息的机制。它用于记录有关用户的一些信息，是实现会话的一种方式。

2，lvs概念

2.1，lvs介绍

LVS的英文全称是Linux Virtual Server，即Linux虚拟服务器。它是我们国家的章文嵩博士的一个开源项目。在linux内存2.6中，它已经成为内核的一部分，在此之前的内核版本则需要重新编译内核。

使用 LVS 可以达到的技术目标是：通过 LVS 达到的负载均衡技术和 Linux 操作系统实现一个高性能高可用的 Linux 服务器集群，它具有良好的可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的性能。LVS 是一个实现负载均衡集群的开源软件项目，LVS架构从逻辑上可分为调度层、Server集群层和共享存储。

LVS主要用于多服务器的负载均衡。它工作在网络层，可以实现高性能，高可用的服务器集群技术。它廉价，可把许多低性能的服务器组合在一起形成一个超级服务器。它易用，配置非常简单，且有多种负载均衡的方法。它稳定可靠，即使在集群的服务器中某台服务器无法正常工作，也不影响整体效果。另外可扩展性也非常好。

LVS 由2部分程序组成，包括 ipvs 和 ipvsadm。

1. ipvs(ip virtual server)：一段代码工作在内核空间，叫ipvs，是真正生效实现调度的代码。

2. ipvsadm：另外一段是工作在用户空间，叫ipvsadm，负责为ipvs内核框架编写规则，定义谁是集群服务，而谁是后端真实的服务器(Real Server)

工作在input链上，lvs接收报文转发的流程：PREROUTING–>INPUT–>POSTROUTING

用户空间：ipvsadm：定义转发规则通过系统调用把规则发送给内核中的ipvs

lvs术语：

调度器：director server

RS: Real Server

Client IP: CIP

Director Virtual IP:VIP

Director IP: DIP

Real Server IP: RIP

2.2，lvs的三种模式

1、lvs type: lvs-nat

​ lvs-dr(direct routing)

​ lvs-tun(ip tunneling)

2、lvs-nat：

多目标的DNAT(IPTABLES):它通过修改请求报文的目标ip地址（同时可能修改目标端口）至挑选出来的某个RS的RIP地址实现转发（通过网络地址转换来实现负载均衡）

特点：

​ (1)RIP应该和DIP使用私网地址，且RS的网关应该指向DIP;

​ (2)请求和响应报文都要经过director server，因此在并发量较高的情况下，director server有可能成为瓶颈

​ (3)支持端口映射

​ (4)RS可以使用任意OS（Operating System操作系统）

​ (5)RS的RIP和director的DIP必须同一网络中

注意：在NAT模式中，Real Server的网关必须指向LVS，否则报文无法送达客户端

优点：集群中的物理服务器可以使用任何支持TCP/IP操作系统，只有负载均衡器需要一个合法的IP地址

缺点：扩展性有限。当服务器节点（普通PC服务器）增长过多时,负载均衡器将成为整个系统的瓶颈，因为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时，大量的数据包都交汇在负载均衡器那，速度就会变慢

3、lvs-dr: direct routing

它通过修改请求报文的目标mac地址进行转发

特点：

​ (1)保证前段路由器将目标ip为vip的请求发送给director server

​ 解决方案:

​ 静态绑定

​ arptables

​ 修改RS主机内核的参数

​ (2)RS的DS必须在同一个物理网络中

​ (3)请求报文经由Director调度，但响应报文一定不能经过director

​ (4)不支持端口映射

​ (5)RS可以是大多数的OS（Unix内核）

​ (6)RS的网关不能指向DIP

注意： 需要设置lo接口的VIP不能响应本地网络内的arp请求。

优点：和TUN（隧道模式）一样，负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端。与VS-TUN相比，VS-DR这种实现方式不需要隧道结构，因此可以使用大多数操作系统做为物理服务器。

DR模式的效率很高，但是配置稍微复杂一点，因此对于访问量不是特别大的公司可以用haproxy/nginx取代。日1000-2000W PV或者并发请求1万以下都可以考虑用haproxy/nginx。

缺点：所有 RS 节点和调度器 LB 只能在一个局域网里面。

4、lvs-tun(ip tunneling)

特点：

①.客户端将请求发往前端的负载均衡器，请求报文源地址是CIP，目标地址为VIP。

②.负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将在客户端请求报文的首部再封装一层IP报文,将源地址改为DIP，目标地址改为RIP,并将此包发送给RS。

③.RS收到请求报文后，会首先拆开第一层封装,然后发现里面还有一层IP首部的目标地址是自己lo接口上的VIP，所以会处理次请求报文，并将响应报文通过lo接口送给eth0网卡直接发送给客户端。

注意：需要设置lo接口的VIP不能在公网上出现。

优点：负载均衡器只负责将请求包分发给后端节点服务器，而RS将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量，这种方式，一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。

缺点：隧道模式的RS节点需要合法IP，这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议，服务器可能只局限在部分Linux系统上。

2.3，lvs支持的算法（不区分大小写）

1. 轮叫调度 rr

这种算法是最简单的，就是按依次循环的方式将请求调度到不同的服务器上，该算法最大的特点就是简单。轮询算法假设所有的服务器处理请求的能力都是一样的，调度器会将所有的请求平均分配给每个真实服务器，不管后端 RS 配置和处理能力，非常均衡地分发下去。

2. 加权轮叫 wrr

这种算法比 rr 的算法多了一个权重的概念，可以给 RS 设置权重，权重越高，那么分发的请求数越多，权重的取值范围 0 – 100。主要是对rr算法的一种优化和补充， LVS 会考虑每台服务器的性能，并给每台服务器添加要给权值，如果服务器A的权值为1，服务器B的权值为2，则调度到服务器B的请求会是服务器A的2倍。权值越高的服务器，处理的请求越多。

3. 最少链接 lc

这个算法会根据后端 RS 的连接数来决定把请求分发给谁，比如 RS1 连接数比 RS2 连接数少，那么请求就优先发给 RS1

4. 加权最少链接 wlc

这个算法比 lc 多了一个权重的概念。

5. 基于局部性的最少连接调度算法 lblc

这个算法是请求数据包的目标 IP 地址的一种调度算法，该算法先根据请求的目标 IP 地址寻找最近的该目标 IP 地址所有使用的服务器，如果这台服务器依然可用，并且有能力处理该请求，调度器会尽量选择相同的服务器，否则会继续选择其它可行的服务器

6. 复杂的基于局部性最少的连接算法 lblcr

记录的不是要给目标 IP 与一台服务器之间的连接记录，它会维护一个目标 IP 到一组服务器之间的映射关系，防止单点服务器负载过高。

7. 目标地址散列调度算法 dh

该算法是根据目标 IP 地址通过散列函数将目标 IP 与服务器建立映射关系，出现服务器不可用或负载过高的情况下，发往该目标 IP 的请求会固定发给该服务器。

8. 源地址散列调度算法 sh

与目标地址散列调度算法类似，但它是根据源地址散列算法进行静态分配固定的服务器资源。

grep -i -A 10 ‘IPVS’ /boot/config-3.10.0-957.el7.x86_64

# IPVS scheduler

CONFIG_IP_VS_RR=m

CONFIG_IP_VS_WRR=m

CONFIG_IP_VS_LC=m

CONFIG_IP_VS_WLC=m

CONFIG_IP_VS_LBLC=m

CONFIG_IP_VS_LBLCR=m

CONFIG_IP_VS_DH=m

CONFIG_IP_VS_SH=m

CONFIG_IP_VS_SED=m

静态方法：仅根据算法本身进行调度

RR:round robin,轮调

WRR:weighted RR

SH:source hash,实现session保持的机制

DH:destination hash,将同一个目标的请求始终发往同一个RS

动态方法：gun局算法及各RS的当前负载状态进行调度

LC:Least Connection

​ Overhead=Active*256 + Inactive

WLC：Weighted LC

​ Overhead=(Active*256 + Inactive)/weighted

​ overhead较小的即被挑选的主机

SED:

LBLC:

LBLCR:

3，keepalived概念

概念：

keepalived 是linux下一个轻量级的高可用解决方案，它与HACMP实现功能类似，都可以实现服务或者网络的高可用，但是又有差别：hacmp是一个专业的、功能完善的高可用软件，它提供了HA软件所需的基本功能，比如心跳检测和资源接管，检测集群中的系统服务，在集群节点间转移共享ip地址所有者等，hacmp功能强大，但是部署和使用相对麻烦，同时也是商业化软件，与hacmp相比，keepalived主要是通过虚拟路由冗余来实现高可用功能，虽然他没有hacmp功能强大，但是keepalived部署使用相对简单，所有配置只需要一个配置文件即可完成。

用途：

keepalived起初是为lvs设计的，专门用来监控集群系统中各个服务节点的状态，它根据layer3,4 & 5交换机制检测每个服务节点的状态，如果某个服务节点出现异常，或工作出现故障，keepaived将检测到，并将出现故障的服务节点从集群系统中剔除，而在故障节点恢复正常后，keepalived又可以自动将此服务节点重新加入到集群中，这些工作全部自动完成，不需要人工干预，需要人工完成的只是修复故障节点。

Keepalived软件主要是通过VRRP协议实现高可用功能的。VRRP是Virtual Router RedundancyProtocol(虚拟路由器冗余协议）的缩写，VRRP出现的目的就是为了解决静态路由单点故障问题的，它能够保证当个别节点宕机时，整个网络可以不间断地运行。

所以，Keepalived 一方面具有**配置管理LVS的功能，同时还具有对LVS下面节点进行健康检查的功能，另一方面也可实现系统网络服务的高可用功能。**

VRRP协议与工作原理：

在现实的网络环境中，主机之间的通信都是通过配置静态路由完成的，而主机之间的路由器一旦出现故障，通信就会失败，因此在这种通信模式中，路由器就成了一个单点瓶颈，为了解决这个问题就引入了VRRP协议

VRRP协议是一种主备模式的协议，通过VRRP可以在网络发生故障时透明地进行设备切换不影响主机间的数据通信，这其中涉及两个概念：物理路由器和虚拟路由器

VRRP可以将两台或者多台物理路由器设备虚拟成一个虚拟路由器，这个虚拟路由器通过虚拟IP（一个或多个）对外提供服务，二在虚拟路由器内部，是多个物理路由器协同工作，同一时间只有一台物理路由器对外提供服务，这台物理路由器被称之为主路由器（处于master状态角色）。它拥有对外提供的虚拟ip，提供各种网络功能，比如arp请求、icmp、数据转发等，二其他物理路由器不拥有对外提供的虚拟ip，也不提供对外网络功能，仅仅接收master的vrrp状态通告信息，这些路由器被统称为备份路由器（处于backup角色）。当主路由器失效时，处于backup角色的备份路由器将重新进行选举，产生一个新的主路由器进入master角色继续对外服务，整个切换过程对于用户来说完全同名

在一个虚拟路由器中，只有处于master角色的路由器会一直发送vrrp数据包，处于backup角色的路由器只接受master发过来的报文信息，用来监控master运行状态，因此，不会发生master抢占的现象，除非它的优先级更高，而当master不可用时，backup也就无法收到master发过来的报文信息，于是就认定master出现故障，接着多台backup就会进行选举，优先级最高的backup将成为新的master，这种选举并进行角色的过程非常快，因此也就保证了服务的持续可用性

keepalived的体系结构：

keepaived是一个高度模块化的软件，结构简单，但扩展性很强，下图是官方给出的keepalived的体系结构

可以看出来，keepalived的体系结构从整体上分为两层，分别是用户空间层和内核空间层。

内核空间层处于最底层，它包括ipvs和netlink两个模块。ipvs模块是keepalived引入的一个第三方模块，通过ipvs可以实现基于ip的负载均衡集群。ipvs默认包含在lvs集群软件中。

内核模块：

IPVS：主要用于通过IPVS跟lvs进行整合，是lvs的核心模块，跟lvs一块使用的

NETLINK：主要实现一些网络的功能

用户模块：主要用于高可用

checker：检查服务状态

vrrp stack：用于DS高可用

keepalived安装与配置：

yum install keepalived

yum安装keepalived默认配置文件在/etc/keepalived/keepalived.conf

配置文件主要分为三类分别是：

（1）全局配置

（2）VRRP配置

（3）LVS配置

keepalived的配置文件

第一段：global_defs，全局配置段
    global_defs {
       notification_email {
               237745635@qq.com
       }
       notification_email_from Alexandre.Cassen@firewall.loc
       smtp_server 192.168.200.1
       smtp_connect_timeout 30
       router_id id1        <<< 当前主机的ID值，这个值必须是唯一的
    }


第二段：vrrp_instance，实例配置段（虚拟服务段）
    【该段是定义虚拟服务的vip等信息】
    vrrp_instance VI_1 {       <<< 指定实例的名称
        state MASTER           <<< 指定节点的状态，MASTER表示主，BACKUP表示备用节点
        interface eth0         <<< 指定将VIP绑定在哪个网卡上
        virtual_router_id 51   <<< 虚拟路由ID，用于标识哪些个节点是一组，同一组的主机的虚拟id需要相同
        priority 100           <<< 指定该节点的优先级（主这节点的优先级大于备节点）
        advert_int 1           <<< 指定备节点在几秒之内没有接收到主节点的心跳信息，就接管其业务和资源
        authentication {       <<< 指定keepalived集群中各个主备节点做认证的方式
            auth_type PASS
            auth_pass 1111
        }
        virtual_ipaddress {   <<< 指定用于提供服务的ip地址（也就是VIP）
            10.220.5.233
        }
    }

第三段：virtual_server，虚拟主机配置段
    【该段主要是给lvs来用，用来定义后端RS节点】
    virtual_server 10.220.5.222 80 {    #指定实例对应的VIP
        delay_loop 6                    # 对后端节点做健康检查的时间间隔
        lb_algo rr                      # 指定负载均衡调度算法
        lb_kind DR                      # 指定所使用的lvs模型
        nat_mask 255.255.255.0
        persistence_timeout 50          # 同一IP的请求50秒内被分配到同一台真实主机
        protocol TCP                    # 用TCP协议对真实节点做健康检查

        real_server 10.220.5.190 80 {   # 指定一台真实服务器的IP和端口
            weight 1                    # 设置权重
            TCP_CHECK {                 # 用建立tcp连接的方式做健康检测
                connect_timeout 10      # 设置建立tcp连接的超时时间
                delay_before_retry 3    # 超时后多久重试
                nb_get_retry 3          # 重试次数
                connect_port 80         # 健康检查使用的端口号
            }
        }

real_server 10.220.5.191 80 {
    weight 1
    TCP_CHECK {
        connect_timeout 10
        nb_get_retry 3
        delay_before_retry 3
        connect_port 80
    }
}
    }

4，HAProxy基础配置

4.1，haproxy简介

HAProxy是一款提供高可用性、负载均衡以及基于TCP（第四层）和HTTP（第七层）应用的代理软件，HAProxy是完全免费的、借助HAProxy可以快速并且可靠的提供基于TCP和HTTP应用的代理解决方案。

（1）免费开源，稳定性也是非常好，这个可通过我做的一些小项目可以看出来，单Haproxy也跑得不错，稳定性可以与硬件级的F5相媲美；

（2）根据官方文档，HAProxy可以跑满10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom’s 10GbE NICs （Myri-10G PCI-Express），这个数值作为软件级负载均衡器是相当惊人的；

（3）HAProxy 支持连接拒绝：因为维护一个连接的打开的开销是很低的，有时我们很需要限制攻击蠕虫（attack bots），也就是说限制它们的连接打开从而限制它们的危害。这个已经为一个陷于小型DDoS攻击的网站开发了而且已经拯救了很多站点，这个优点也是其它负载均衡器没有的。

（4）HAProxy 支持全透明代理（已具备硬件防火墙的典型特点）：可以用客户端IP地址或者任何其他地址来连接后端服务器；这个特性仅在Linux 2.4/2.6内核打了cttproxy补丁后才可以使用；这个特性也使得为某特殊服务器处理部分流量同时又不修改服务器的地址成为可能。

（5）HAProxy现多于线上的Mysql集群环境，我们常用于它作为MySQL（读）负载均衡；

（6）自带强大的监控服务器状态的页面，实际环境中我们结合Nagios进行邮件或短信报警；

（7）HAProxy支持虚拟主机。

HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上。

在功能上，能以proxy反向代理方式实现WEB均衡负载，这样的产品有很多。包括lvs，Nginx，ApacheProxy，lighttpd等。

国内生产环境上使用Haproxy的公司很多，例如淘宝的CDN系统

HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。基于合理的配置及优化，完全可以实现单机支持数以万计的并发连接。

HAProxy支持2种主要的代理模式：第一种代理模式是"tcp"，即OSI网络模型中的第4层传输层协议；第二种代理模式是“http”，即OSI网络模型中的第7层应用层协议。在tcp模式下，HAProxy支持在客户端和服务器之间双向转发流量。http模式下，HAProxy进行协议分析，能够针对分析结果和用户配置来决定允许、拒绝、交换、增加、修改等工作策略。

4.2，haproxy的安装

1、yum安装

第一步：下载

[root@ren4 ~]# yum -y install haproxy

第二步：启动

[root@ren4 ~]# systemctl restart haproxy

第三步：查看是否启动成功（默认监听5000端口，可修改为80端口）

[root@ren4 haproxy]# lsof -i :5000

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

haproxy 38195 haproxy 5u IPv4 114916 0t0 TCP *:commplex-main (LISTEN)

haproxy的配置文件：

[root@ren4 haproxy]# rpm -qc haproxy

/etc/haproxy/haproxy.cfg

/etc/logrotate.d/haproxy

/etc/sysconfig/haproxy

4.3，haproxy添加后端节点

[root@ren4 haproxy]# vim /etc/haproxy/haproxy.cfg

backend app

balance roundrobin

server app5 192.168.11.5:80 weight 1

server app6 192.168.11.6:80 weight 3

[root@ren4 haproxy]# systemctl restart haproxy

[root@ren4 haproxy]# firewall-cmd --add-port=5000/tcp

success

4.4，后端节点准备测试文件及测试结果

节点1：192.168.11.5

[root@ren5 ~]# echo “this is 5” > /var/www/html/index.html

[root@ren5 ~]# systemctl restart httpd

[root@ren5 ~]# firewall-cmd --add-port=80/tcp

节点2：192.168.11.6

[root@ren6 html]# echo “this is 6” > /var/www/html/index.html

[root@ren6 html]# systemctl restart httpd

[root@ren6 html]# firewall-cmd --add-port=80/tcp

success

测试结果：

4.5，haproxy监控web显示配置

在defaults后添加以下内容：

defaults
    stats refresh           30s     #统计页面自动刷新时间
    stats uri               /stats    #统计页面url（注意stats后是uri）
    stats realm             baison-test-Haproxy    #统计页面密码框上提示文本
    stats auth              admin:123    #统计页面用户名和密码设置
    stats hide-version    #隐藏统计页面上HAProxy的版本信息

浏览器访问结果：

4.6，haproxy负载均衡算法

一、roundrobin，表示简单的轮询，每个服务器根据权重轮流使用，在服务器的处理时间平均分配的情况下这是最流畅和公平的算法。该算法是动态的，对于实例启动慢的服务器权重会在运行中调整。

二、static-rr，表示根据权重，建议关注；每个服务器根据权重轮流使用，类似roundrobin，但它是静态的，意味着运行时修改权限是无效的。另外，它对服务器的数量没有限制。

三、leastconn，表示最少连接者先处理，建议关注；leastconn建议用于长会话服务，例如LDAP、SQL、TSE等，而不适合短会话协议。如HTTP.该算法是动态的，对于实例启动慢的服务器权重会在运行中调整。

四、source，表示根据请求源IP，建议关注；对请求源IP地址进行哈希，用可用服务器的权重总数除以哈希值，根据结果进行分配。只要服务器正常，同一个客户端IP地址总是访问同一个服务器。如果哈希的结果随可用服务器数量而变化，那么客户端会定向到不同的服务器；该算法一般用于不能插入cookie的Tcp模式。它还可以用于广域网上为拒绝使用会话cookie的客户端提供最有效的粘连；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。

五、uri，表示根据请求的URI；表示根据请求的URI左端（问号之前）进行哈希，用可用服务器的权重总数除以哈希值，根据结果进行分配。只要服务器正常，同一个URI地址总是访问同一个服务器。一般用于代理缓存和反病毒代理，以最大限度的提高缓存的命中率。该算法只能用于HTTP后端；该算法一般用于后端是缓存服务器；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。

六、url_param，表示根据请求的URl参数'balance url_param' requires an URL parameter name
在HTTP GET请求的查询串中查找<param>中指定的URL参数，基本上可以锁定使用特制的URL到特定的负载均衡器节点的要求；该算法一般用于将同一个用户的信息发送到同一个后端服务器； 该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。

七、hdr(name)，表示根据HTTP请求头来锁定每一次HTTP请求；在每个HTTP请求中查找HTTP头<name>，HTTP头<name>将被看作在每个HTTP请求，并针对特定的节点；如果缺少头或者头没有任何值，则用roundrobin代替；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。

八、rdp-cookie(name)，表示根据据cookie(name)来锁定并哈希每一次TCP请求。为每个进来的TCP请求查询并哈希RDP cookie<name>；该机制用于退化的持久模式，可以使同一个用户或者同一个会话ID总是发送给同一台服务器。如果没有cookie，则使用roundrobin算法代替；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。
#其实这些算法各有各的用法，我们平时应用得比较多的应该是roundrobin、source和lestconn。

4.7，haproxy acl定义

访问控制列表（ACL，Access Control Lists）是应用在路由器（或三层交换机）接口上的指令列表，用来告诉路由器哪些数据可以接收，哪些数据是需要被拒绝并丢弃。
ACL的定义是基于协议的，它适用于所有的路由协议，如IP、IPX等。它在路由器上读取数据包头中的信息，如源地址、目的地址、使用的协议、源端口、目的端口等，并根据预先定义好的规则对包进行过滤，从而达到对网络访问的精确、灵活控制。
########ACL策略定义#########################
1、#如果请求的域名满足正则表达式返回true -i是忽略大小写
acl denali_policy hdr_reg(host) -i ^(www.inbank.com|image.inbank.com)$

2、#如果请求域名满足www.inbank.com 返回 true -i是忽略大小写
acl tm_policy hdr_dom(host) -i www.inbank.com

3、#在请求url中包含sip_apiname=，则此控制策略返回true,否则为false
acl invalid_req url_sub -i sip_apiname=#定义一个名为invalid_req的策略

4、#在请求url中存在timetask作为部分地址路径，则此控制策略返回true,否则返回false
acl timetask_req url_dir -i timetask

5、#当请求的header中Content-length等于0时返回 true
acl missing_cl hdr_cnt(Content-length) eq 0

#########acl策略匹配相应###################
1、#当请求中header中Content-length等于0 阻止请求返回403
block if missing_cl

2、#block表示阻止请求，返回403错误，当前表示如果不满足策略invalid_req，或者满足策略timetask_req，则阻止请求。
block if !invalid_req || timetask_req

3、#当满足denali_policy的策略时使用denali_server的backend
use_backend denali_server if denali_policy

4、#当满足tm_policy的策略时使用tm_server的backend
use_backend tm_server if tm_policy

5、#reqisetbe关键字定义，根据定义的关键字选择backend
reqisetbe ^Host:\ img dynamic
reqisetbe ^[^\ ]*\ /(img|css)/ dynamic
reqisetbe ^[^\ ]*\ /admin/stats stats

6、#以上都不满足的时候使用默认mms_server的backend
default_backend mms

4.8，编译安装的配置文件详解

###########全局配置#########
global
　　log         127.0.0.1 local2 #[日志输出配置，所有日志都记录在本机，通过local2输出]
　  
    chroot      /var/lib/haproxy #chroot运行路径
    pidfile     /var/run/haproxy.pid #haproxy 进程PID文件
    maxconn     4000 #默认最大连接数,需考虑ulimit-n限制
    user        haproxy #运行haproxy的用户
　　group       haproxy #运行haproxy的用户所在的组
　　daemon  #以后台形式运行harpoxy
　　#nbproc 1 #设置进程数量
　　#ulimit-n 819200 #ulimit 的数量限制
　　#debug #haproxy 调试级别，建议只在开启单进程的时候调试
　　#quiet

########默认配置############
defaults
　　log global
　　mode http #默认的模式mode { tcp|http|health }，tcp是4层，http是7层，health只会返回OK
　　option httplog #日志类别,采用httplog
　　option dontlognull #不记录健康检查日志信息
　　retries 2 #两次连接失败就认为是服务器不可用，也可以通过后面设置
　　#option forwardfor #如果后端服务器需要获得客户端真实ip需要配置的参数，可以从Http Header中获得客户端ip
　　option httpclose #每次请求完毕后主动关闭http通道,haproxy不支持keep-alive,只能模拟这种模式的实现
　　#option redispatch #当serverId对应的服务器挂掉后，强制定向到其他健康的服务器，以后将不支持
　　option abortonclose #当服务器负载很高的时候，自动结束掉当前队列处理比较久的链接
　　maxconn 4096 #默认的最大连接数
　　timeout connect 5000ms #连接超时
　　timeout client 30000ms #客户端超时
　　timeout server 30000ms #服务器超时
　　#timeout check 2000 #心跳检测超时
　　#timeout http-keep-alive10s #默认持久连接超时时间
　　#timeout http-request 10s #默认http请求超时时间
　　#timeout queue 1m #默认队列超时时间
　　balance roundrobin #设置默认负载均衡方式，轮询方式
　　#balance source #设置默认负载均衡方式，类似于nginx的ip_hash
　　#balnace leastconn #设置默认负载均衡方式，最小连接数

########统计页面配置########
listen stats
　　bind 0.0.0.0:1080 #设置Frontend和Backend的组合体，监控组的名称，按需要自定义名称
　　mode http #http的7层模式
　　option httplog #采用http日志格式
　　#log 127.0.0.1 local0 err #错误日志记录
　　maxconn 10 #默认的最大连接数
　　stats refresh 30s #统计页面自动刷新时间
　　stats uri /stats #统计页面url
　　stats realm XingCloud\ Haproxy #统计页面密码框上提示文本
　　stats auth admin:admin #设置监控页面的用户和密码:admin,可以设置多个用户名
　　stats auth Frank:Frank #设置监控页面的用户和密码：Frank
　　stats hide-version #隐藏统计页面上HAProxy的版本信息
　　stats admin if TRUE #设置手工启动/禁用，后端服务器(haproxy-1.4.9以后版本)

########设置haproxy 错误页面#####
#errorfile 403 /home/haproxy/haproxy/errorfiles/403.http
#errorfile 500 /home/haproxy/haproxy/errorfiles/500.http
#errorfile 502 /home/haproxy/haproxy/errorfiles/502.http
#errorfile 503 /home/haproxy/haproxy/errorfiles/503.http
#errorfile 504 /home/haproxy/haproxy/errorfiles/504.http

########frontend前端配置##############
frontend main
　　bind *:80 #这里建议使用bind *:80的方式，要不然做集群高可用的时候有问题，vip切换到其他机器就不能访问了。
　　acl web hdr(host) -i www.abc.com  #acl后面是规则名称，-i为忽略大小写，后面跟的是要访问的域名，如果访问www.abc.com这个域名，就触发web规则，。
　　acl img hdr(host) -i img.abc.com  #如果访问img.abc.com这个域名，就触发img规则。
　　use_backend webserver if web   #如果上面定义的web规则被触发，即访问www.abc.com，就将请求分发到webserver这个作用域。
　　use_backend imgserver if img   #如果上面定义的img规则被触发，即访问img.abc.com，就将请求分发到imgserver这个作用域。
　　default_backend dynamic #不满足则响应backend的默认页面

########backend后端配置##############
backend webserver #webserver作用域
　　mode http
　　balance roundrobin #balance roundrobin 负载轮询，balance source 保存session值，支持static-rr，leastconn，first，uri等参数
　　option httpchk /index.html HTTP/1.0 #健康检查, 检测文件，如果分发到后台index.html访问不到就不再分发给它
　　server web1 10.16.0.9:8085 cookie 1 weight 5 check inter 2000 rise 2 fall 3
　　server web2 10.16.0.10:8085 cookie 2 weight 3 check inter 2000 rise 2 fall 3
　　#cookie 1表示serverid为1，check inter 1500 是检测心跳频率 
　　#rise 2是2次正确认为服务器可用，fall 3是3次失败认为服务器不可用，weight代表权重

backend imgserver
　　mode http
　　option httpchk /index.php
　　balance roundrobin 
　　server img01 192.168.137.101:80 check inter 2000 fall 3
　　server img02 192.168.137.102:80 check inter 2000 fall 3

backend dynamic 
　　balance roundrobin 
　　server test1 192.168.1.23:80 check maxconn 2000 
　　server test2 192.168.1.24:80 check maxconn 2000

listen tcptest 
　　bind 0.0.0.0:5222 
　　mode tcp 
　　option tcplog #采用tcp日志格式 
　　balance source 
　　#log 127.0.0.1 local0 debug 
　　server s1 192.168.100.204:7222 weight 1 
　　server s2 192.168.100.208:7222 weight 1

erver web1 10.16.0.9:8085 cookie 1 weight 5 check inter 2000 rise 2 fall 3
　　server web2 10.16.0.10:8085 cookie 2 weight 3 check inter 2000 rise 2 fall 3
　　#cookie 1表示serverid为1，check inter 1500 是检测心跳频率
　　#rise 2是2次正确认为服务器可用，fall 3是3次失败认为服务器不可用，weight代表权重

backend imgserver
　　mode http
　　option httpchk /index.php
　　balance roundrobin
　　server img01 192.168.137.101:80 check inter 2000 fall 3
　　server img02 192.168.137.102:80 check inter 2000 fall 3

backend dynamic
　　balance roundrobin
　　server test1 192.168.1.23:80 check maxconn 2000
　　server test2 192.168.1.24:80 check maxconn 2000

listen tcptest
　　bind 0.0.0.0:5222
　　mode tcp
　　option tcplog #采用tcp日志格式
　　balance source
　　#log 127.0.0.1 local0 debug
　　server s1 192.168.100.204:7222 weight 1
　　server s2 192.168.100.208:7222 weight 1