负载均衡集群

负载均衡（Load Balance）：可以利用多个计算机和组合进行海量请求处理，从而获得很高的处理效率，也可以用多个计算机做备份（高可用），使得任何一个机器坏了整个系统还是能正常运行。通过负载均衡使请求可以在计算机集群中尽可能平均地分摊处理。每个节点都可以承担一定的处理负载，并且可以实现处理负载在节点之间的动态分配，以实现负载均衡。

一、负载均衡分类

负载均衡根据所采用的设备对象（软/硬件负载均衡），应用的OSI网络层次（网络层次上的负载均衡）等来分类。

在实际应用中，比较常见的就是四层负载及七层负载。

1、四层负载均衡(基于IP+端口的负载均衡)

所谓四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP），直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作.

实现四层负载均衡的软件：

- lvs：重量级的四层负载软件
- nginx：轻量级的四层负载软件，带缓存功能，正则表达式较灵活
- haproxy：模拟四层转发，较灵活

实现四层负载均衡的硬件：

- F5：硬件负载均衡器，功能很好，但是成本很高。

2、七层负载均衡(基于虚拟的URL或主机IP的负载均衡)

在四层负载均衡的基础上，再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别来决定是否要进行负载均衡

以常见的TCP为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，只能先代理的服务器和客户端建立连接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载均衡设备在这种情况下，更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。

实现七层负载均衡的软件：

- haproxy：天生负载均衡技能，全面支持七层代理，会话保持，访问控制；
- nginx：只在http协议和mail协议上功能比较好，性能与haproxy差不多；
- apache：功能较差
- Mysql proxy：功能尚可。

3、四层负载与七层负载的区别

	四层负载均衡（layer 4）	七层负载均衡（layer 7）
基于	基于IP Port	URL
类似于	路由器	代理服务器
复杂度	低	高
性能	高；无需解析内容	中；需要算法识别 URL，Cookie 和 HTTP head 等信息
安全性	低，无法识别 DDoS等攻击	高
额外功能	无	会话保持，图片压缩，防盗链等

总结：从上面的对比看来四层负载与七层负载最大的区别就是效率与功能的区别。四层负载架构设计比较简单，无需解析具体的消息内容，在网络吞吐量及处理能力上会相对比较高，而七层负载均衡的优势则体现在功能多，控制灵活强大。在具体业务架构设计时，使用七层负载或者四层负载还得根据具体的情况综合考虑。

二、LVS实现四层负载均衡

1、LVS介绍

LVS 是` Linux Virtual Server`的简称，也就是 Linux 虚拟服务器, 是一个由章文嵩博士发起的自由软件项目，它的官方站点是www.linuxvirtualserver.org。`现在LVS已经是 Linux标准内核的一部分，因此性能较高。`

2、LVS优势与不足

1)优势

高并发连接：LVS基于内核网络层面工作，有超强的承载能力和并发处理能力。单台LVS负载均衡器，可支持上万并发连接。
稳定性强：是工作在网络4层之上仅作分发之用，这个特点也决定了它在负载均衡软件里的性能最强，稳定性最好，对内存和cpu资源消耗极低。
成本低廉：硬件负载均衡器少则十几万，多则几十万上百万，LVS只需一台服务器和就能免费部署使用，性价比极高。
配置简单：LVS配置非常简单，仅需几行命令即可完成配置，也可写成脚本进行管理。
支持多种算法：支持多种论调算法，可根据业务场景灵活调配进行使用
支持多种工作模型：可根据业务场景，使用不同的工作模式来解决生产环境请求处理问题。
应用范围广：因为LVS工作在4层，所以它几乎可以对所有应用做负载均衡，包括http、数据库、DNS、ftp服务等等

2)不足

工作在4层，不支持7层规则修改，不适合小规模应用

3、LVS核心组件和专业术语

1)核心组件

LVS的管理工具和内核模块 ipvsadm/ipvs
ipvsadm:用户空间的命令行工具，用于管理集群服务及集群服务上的RS等；
ipvs:工作于内核上的程序，可根据用户定义的集群实现请求转发；

2)专业术语

VS:Virtual Server --虚拟服务
Director,Balancer --负载均衡器、分发器
RS:Real Server --后端请求处理服务器
CIP:Client IP --客户端IP
VIP:Director Virtual IP --负载均衡器虚拟IP
DIP:Director IP --负载均衡器IP
RIP:Real Server IP --后端请求处理服务器IP(真实后端服务器IP)

3)LVS负载均衡工作模式

LVS/NAT:网络地址转换模式，进站/出站的数据流量经过分发器(IP负载均衡，他修改的是IP地址) --利用三层功能
LVS/DR:直接路由模式，只有进站的数据流量经过分发器(数据链路层负载均衡，因为他修改的是目的mac地址)--利用二层功能mac地址
LVS/TUN:隧道模式，只有进站的数据流量经过分发器

4、LVS四种工作模式原理以及优缺点比较

1.NAT模式(VS-NAT)

原理：

(1).客户端访问集群的VIP，请求WEB资源(请求报文：源地址为CIP，目标地址为VIP)；

(2).Director收到客户端的请求报文，会修改请求报文中的目标地址(VIP)为RIP，并且将请求根据相应的调度算法送往后端WEB服务器(请求报文：源地址CIP，目标地址为RIP)；

(3).WEB服务器收到请求，检查报文是访问自己的而自己也提供WEB服务，就会响应这个请求报文，并发送给Director(响应报文：源地址RIP，目标地址CIP)；

(4).Director收到WEB服务器的响应报文，会根据自己内部的追踪机制，判断出用户访问的是VIP，此时会修改源地址为VIP并响应客户端请求(响应报文：源地址VIP，目标地址CIP)。期间,无论是进来的流量,还是出去的流量,都必须经过负载均衡器｡

优点：

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

缺点：

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

2.直接路由(Direct routing)模式 (VS-DR)

原理：

是通过二层数据链路层来传输，修改的是mac地址
负载均衡器和RS都使用同一个VIP对外服务｡但只有DR对ARP请求进行响应,所有RS对本身这个VIP的ARP请求保持静默｡也就是说,网关会把对这个服务VIP的请求全部定向给DR,而DR收到数据包后根据调度算法,找出对应的RS,把目的MAC地址改为RS的MAC（因为IP一致）并将请求分发给这台RS｡这时RS收到这个数据包,处理完成之后，由于VIP一致，可以直接将数据返给客户，则等于直接从客户端收到这个数据包无异,处理后直接返回给客户端｡

优点：

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

缺点：

（只能说是不足）要求负载均衡器的物理网卡必须与后端服务器的物理网卡在一个网段段上。

3.IP隧道(Tunnel)模式(VS-TUN)

原理：

互联网上的大多Internet服务的请求包很短小，而应答包通常很大。那么隧道模式就是，把客户端发来的数据包，封装一个新的IP头标记(仅目的IP)发给RS,RS收到后,先把数据包的头解开,还原数据包,处理后,直接返回给客户端,不需要再经过负载均衡器｡注意,由于RS需要对负载均衡器发过来的数据包进行还原,所以说必须支持IPTUNNEL协议｡所以,在RS的内核中,必须编译支持IPTUNNEL这个选项

优点：

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

缺点：

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

4.LVS模式的区别

lvs-nat：请求和响应报文都经由Director

lvs-dr与lvs-tun：请求报文要经由Director，但响应报文由RS直接发往Client

5、LVS `ipvsadm` 命令的使用

1)LVS-server 安装LVS管理软件

yum install -y ipvsadm

2)命令选项

-A --add-service #在服务器列表中新添加一条新的虚拟服务器记录
-a --add-server  #在服务器表中添加一条新的真实主机记录
-t --tcp-service #说明虚拟服务器提供tcp服务
-u --udp-service #说明虚拟服务器提供udp服务
-r --real-server #真实服务器地址
-m --masquerading #指定LVS工作模式为NAT模式
-w --weight #真实服务器的权值
-g --gatewaying #指定LVS工作模式为直接路由器模式（也是LVS默认的模式）
-s --scheduler #使用的调度算法，默认调度算法是 wlc

固定调度算法：rr，wrr，dh，sh
动态调度算法：wlc，lc，sed，nq，lblc，lblcr
固定调度算法：即调度器不会去判断后端服务器的繁忙与否，一如既往得将请求派发下去。
动态调度算法：调度器会去判断后端服务器的繁忙程度，然后依据调度算法动态得派发请求。

#常用的算法是:rr、wrr、wlc、lc

-C -clear #清除内核虚拟服务器表中的所有记录。
-S -save #保存虚拟服务器规则到标准输出，输出为-R 选项可读的格式
-d -delete-server #删除一条虚拟服务器记录中的某条真实服务器记录
-L|-l –list #显示内核虚拟服务器表
--numeric, -n：#以数字形式输出地址和端口号

6、LVS负载均衡集群实战

1)环境准备

1.准备虚拟机

- 准备三台纯净的虚拟机

1.LVS-server	//负载均衡器

2.real-server1		//后端真实服务器
  real-server2		//后端真实服务器

2.`LVS-server` 安装lvs管理软件

yum install -y ipvsadm

程序包：ipvsadm（LVS管理工具）

主程序：/usr/sbin/ipvsadm

规则保存工具：/usr/sbin/ipvsadm-save  > /path/to/file

配置文件：/etc/sysconfig/ipvsadm-config

3.LVS/DR模式

DR模式的组网要求LVS和Real server在同一网段二层互通。因为LVS DR模式在负载均衡转发报文时，只修改目的mac为real server的mac，lvs要能将报文转发给real server，就必须满足LVS和real server是同网段二层互通。

实验说明

网络使用NAT模式
DR模式要求Director DIP 和所有RealServer RIP必须在同一个网段及广播域
所有节点网关均指定真实网关

2)LVS/DR模式实施

1.集群中所有主机关闭`防火墙`和`selinux`

[root@lvs-server ~]#setenforce 0		//关闭selinux
[root@lvs-server ~]#systemctl stop firewalld	//关闭防火墙
[root@lvs-server ~]#systemctl disable firewalld		//永久关闭防火墙

2.Director分发器配置

配置VIP

1设置VIP

[root@lvs-server ~]#ip addr add dev ens33 192.168.246.160/32

为什么RS上lo配置的VIP掩码为32位
这是由于lo设备的特殊性导致，如果lo绑定VIP/24，则该设备会响应该网段所有IP(192.168.246.0-254)的请求，而不是只响应192.168.246.160这一个地址。,就算是不设置为32也是可以的，只不过会影响访问

2安装ipvsadm

RHEL确保LoadBalancer仓库可用

[root@lvs-server ~]#yum install -y ipvsadm

3启动服务

[root@lvs-server ~]#service ipvsadm start

注意:启动如果报错: /bin/bash: /etc/sysconfig/ipvsadm: 没有那个文件或目录

需要手动生成文件

[root@lvs-server ~]#ipvsadm -S > /etc/sysconfig/ipvsadm 	//推荐这种

或者

[root@lvs-server ~]#ipvsadm --save > /etc/sysconfig/ipvsadm

之后再重新启动

[root@lvs-server ~]#service ipvsadm start

定义LVS分发策略

-A：添加VIP
-t：用的是tcp协议
-a：添加的是lo的vip地址
-r：转发到real-serve rip
-s：算法
-L|-l –list #显示内核虚拟服务器表
--numeric, -n：#以数字形式输出地址和端口号
-g --gatewaying #指定LVS工作模式为直接路由器模式（也是LVS默认的模式）
-S -save #保存虚拟服务器规则到标准输出，输出为-R 选项可读的格式
rr：轮循
如果添加ip错了，删除命令如下:
[root@lvs-server ~]#ip addr del 192.168.246.193 dev ens33

看懂之后

清除内核虚拟服务器表中的所有记录

[root@lvs-server ~]# ipvsadm -C

添加VIP 使用tcp协议 使用轮询算法

[root@lvs-server ~]# ipvsadm -A -t 192.168.246.160:80 -s rr

添加lo的VIP地址和转发到real-server rip

[root@lvs-server ~]# ipvsadm -a -t 192.168.246.160:80 -r 192.168.246.161 -g
[root@lvs-server ~]# ipvsadm -a -t 192.168.246.160:80 -r 192.168.246.162 -g

保存到文件中

[root@lvs-server ~]# ipvsadm -S > /etc/sysconfig/ipvsadm

查看内核虚拟服务器表

[root@lvs-server ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.246.160:80 rr
  -> 192.168.246.161:80           Route   1      0          0         
  -> 192.168.246.162:80           Route   1      0          0

配置real-server

两台real-server都这样配置

yum install -y epel* && yum install -y nginx

按顺序添加不同的主机名以示区分

事实上随意填，只是为了区分是否负载均衡成功

echo "这里填信息" >> /usr/share/nginx/html/index.html

在lo接口上绑定VIP

ip addr add dev lo 192.168.246.160/32

忽略arp广播

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

因为：realServer的vip有了，接着就是同一个网段中拥有两个vip, 客户端在网关发送arp广播需找vip时需要让realServer不接受响应.

设置为1，意味着当别人的arp请求过来的时候，如果接收的设备没有这个ip，就不做出响应(这个ip在lo上，lo不是接收设备的进口)

匹配精准IP地址回包

echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

使用最好的ip来回应，什么是最好的ip？同一个网段内子网掩码最长的

启动nginx

systemctl start nginx
systemctl enable nginx		//设置开机自启

测试

打开浏览器访问 http://192.168.246.160

或者
再开一台纯净机器
elinks -dump http://192.168.246.160		//-dump非交互模式

此时刷新会发现可能刷着刷着就不变了，那是因为nginx有个缓存时间

实际生产环境中，到这里已经完成了，这个并不需要修改

我们做实验自然可以去修改看看的

同样是两台real-server都需要去做的

vim /etc/nginx/nginx.conf

找到这一行

 keepalive_timeout   65;
 
 把65 修改为 0
 
 然后保存退出

重启nginx

systemctl restart nginx

7、LVS的调度算法

LVS的调度算法分为静态和动态两类

1)静态算法 (4种)

只根据算法进行调度而不考虑后端服务器的实际连接情况和负载情况

①.RR：

轮叫调度（Round Robin）、轮询

将客户端请求平均分发到每台Real Server

②.WRR：

加权轮叫（Weight RR）

调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。

③.DH：

目标地址散列调度（Destination Hash ）

将同样的请求发送给同一个server,一般用于缓存服务器.即将同一类型的请求分配给同一个后端服务器，例如将以 .jgp、.png等结尾的请求转发到同一个节点。这种算法其实不是为了真正意义的负载均衡，而是为了资源的分类管理。这种调度算法主要应用在使用了缓存节点的系统中，提高缓存的命中率。

④.SH：

源地址 hash（Source Hash）

源地址散列”调度算法根据请求的源IP地址，
简单的说就是有将同一客户端的请求发给同一个real server,如果后端服务器工作正常没有超负荷的话。这可以解决session共享的问题，但是这里有个问题，很多企业、社区、学校都是共用的一个IP，这将导致请求分配的不均衡。

2)动态算法(6种)

前端的调度器会根据后端真实服务器的实际连接情况来分配请求

①.LC：

最少链接（Least Connections）

调度器通过”最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用”最小连接”调度算法可以较好地均衡负载。

②.WLC：

加权最少连接(默认采用的就是这种)（Weighted Least Connections）

根据Real Server 权重值，选择连接数最少的服务器。

③.SED：

最短期望延迟调度（Shortest Expected Delay ）

不考虑非活动连接，谁的权重大，我们优先选择权重大的服务器来接收请求，但会出现问题，就是权重比较大的服务器会很忙，但权重相对较小的服务器很闲，甚至会接收不到请求，所以便有了下面的算法nq。

④.NQ：

永不排队/最少队列调度（Never Queue Scheduling NQ）

无需队列。如果有台realserver的连接数＝0就直接分配过去，保证不会有一个主机很空间。

⑤.LBLC：

基于局部性的最少链接（locality-Based Least Connections）

　基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统｡该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器;若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用“最少链接”的原则选出一个可用的服务器，将请求发送到该服务器｡

⑥. LBLCR：

带复制的基于局部性最少连接（Locality-Based Least Connections with Replication）

　带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统｡它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射｡该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按”最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器｡同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。