LVS+Keepalived实现负载均衡

---

前言

现代互联网公司必然会面对的问题就是高并发问题，一般为了解决高并发，我们都会采用一变多的模式：即将一台物理服务器改为使用多台物理服务器。那么如果每台服务器固定服务自己的一批用户，那么随着用户量的增加和使用时间的不均匀分布，避免不了的会出现资源浪费和服务器压力过大的问题。
为了解决这些问题，我们可以采用LVS+Keepalived实现高可用的负载均衡机制，让我们能利用充分每一台服务器的资源，同时解决因为服务器宕机导致客户体验不好的问题。

---

一、什么是LVS？

LVS（Linux Virtual Server）即Linux虚拟服务器，是由章文嵩博士主导的开源负载均衡项目，目前LVS已经被集成到Linux内核模块中。
该项目在Linux内核中实现了基于IP的数据请求负载均衡调度方案,客户端通过访问负载均衡服务器来请求资源，负载均衡服务器通过负载均衡算法，将客户请求发送给实际提供服务的服务器。
因为负载均衡服务器只是将客户请求的数据包直接发送给真实服务器，所以速度非常快。但是要求每一台真实服务器提供的服务必须是相同的，这样当用户从不同的真实服务器中请求回的数据才是相同的。

二、LVS的三种工作模式

1.NAT模式

如图所示
首先真实服务器web1、web2、web3（提供真实服务的服务器，Real Server 以下统称为RS）必须和LVS服务器处于同一网段（192.168.0.x），且RS必须有192.168.0.254作为网关。
其次LVS负载均衡调度器，需要有两块网卡，一块IP是192.168.0.254，与RS处于同一网段，可以直接将数据包发送给RS。并且还有一块网卡IP为124.126.147.168。这个IP是需要对外开放的，用户可以通过这个IP将请求发送到LVS服务器。因为124.126.147.168不是真实提供服务的IP地址，所以我们将其称为VIP(Virtual IP Address)。
最后，用户通过访问VIP,就可以获取自己想要的资源，整个负载均衡的过程对其是不可见的。
所以整个流程是：

用户发送数据包请求VIP——LVS服务器接到请求，将数据包中的VIP地址替换为RS的IP地址，并将数据包发送给RS——RS处理请求并将响应的数据包发送给LVS服务器——LVS服务器将响应的数据包返回给用户。

但是NAT模式也存在缺陷：用户发送的请求包和RS发送的响应包都会经过LVS服务器。由于通信网络的不对称性，请求包远远小于响应包的大小。所以LVS可以承受多个请求，但是面对多个响应是就会陷入性能瓶颈。

2.DR模式

如上图所示，DR模式的改进在于RS处会有对外隐藏对内可见的VIP（通过修改ARP协议参数实现）。
当使用DR模式时，LVS不再直接替换IP地址，而是通过MAC欺骗的方式转发请求包，优点是速度快，消耗低。
所谓MAC欺骗是指LVS服务器中会存储RS网卡的MAC地址。当LVS服务器需要转发请求包时，直接通过修改MAC地址，将包转发到RS。而RS接受到请求包以后，因为自身存在VIP,所以可以直接向用户发送响应包。降低了LVS的消耗。

3.TUN模式

主要通过数据包外再套一层数据包实现，应用较少，暂时先不讨论。

三、LVS的负载均衡算法

静态算法

静态：根据LVS本身自由的固定的算法分发用户请求。

轮询（Round Robin 简写’rr’）：轮询算法假设所有的服务器处理请求的能力都一样的，调度器会把所有的请求平均分配给每个真实服务器。（同Nginx的轮询）
加权轮询（Weight Round Robin 简写’wrr’）：安装权重比例分配用户请求。权重越高，被分配到处理的请求越多。（同Nginx的权重）
源地址散列（Source Hash 简写’sh’）：同一个用户ip的请求，会由同一个RS来处理。（同Nginx的ip_hash）
目标地址散列（Destination Hash 简写’dh’）：根据url的不同，请求到不同的RS。（同Nginx的url_hash）

动态算法

动态：会根据流量的不同，或者服务器的压力不同来分配用户请求，这是动态计算的。

最小连接数（Least Connections 简写’lc’）：把新的连接请求分配到当前连接数最小的服务器。
加权最少连接数（Weight Least Connections 简写’wlc’）：服务器的处理性能用数值来代表，权重越大处理的请求越多。Real Server 有可能会存在性能上的差异，wlc动态获取不同服务器的负载状况，把请求分发到性能好并且比较空闲的服务器。
最短期望延迟（Shortest Expected Delay 简写’sed’）：特殊的wlc算法。举例阐述，假设有ABC三台服务器，权重分别为1、2、3 。如果使用wlc算法的话，当一个新请求进来，它可能会分给ABC中的任意一个。使用sed算法后会进行如下运算：
• A：（1+1）/1=2
• B：（1+2）/2=3/2
• C：（1+3）/3=4/3
最终结果，会把这个请求交给得出运算结果最小的服务器。
最少队列调度（Never Queue 简写’nq’）：永不使用队列。如果有Real Server的连接数等于0，则直接把这个请求分配过去，不需要在排队等待运算了（sed运算）。
动态算法的实现主要是通过LVS服务器“偷窥”用户发给RS的请求，当LVS服务器接收到建立链接的数据包时对RS连接数的计数器+1。当接收到断开链接的数据包时对RS连接数的计数器-1。可以知道每个服务器现在有多少链接。

四、什么是Keepalived

Keepalived的作用是检测服务器的状态，如果有一台web服务器宕机，或工作出现故障，Keepalived将检测到，并将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作，当服务器工作正常后Keepalived自动将服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的服务器。
Keepalived是一个通用的解决单点问题的第三方应用，可以用于tomcat，nginx，LVS等多种服务器。

五、LVS+Keepalived是如何工作的

LVS+Keepalived主要是通过主备模式来解决LVS的单点问题。
Keepalived可以通过配置文件的形式，配置LVS主机和备机。同时建立健康检查机制，当主机宕机时，备机自动接管VIP。当RS宕机时，自动将RS下线。避免部分客户访问失败。
Keepalived会定期广播主机的存活情况，如果备机连续n次没有收到主机的广播。则主动去查询主机是否存活，如果确认主机已经挂掉。则根据权重选举新的主机。当主机会再去根据权重竞争主机位置。
当RS宕机时，Keepalived会重试n次，确认RS挂掉后，暂时屏蔽掉这个RS X秒。等到X秒后，当再有请求被负载到之前挂掉的RS时，再确认其是否存活。如果存活将其上线，如果没有存活则再屏蔽X秒。
但是Keepalived自身也存在单点问题，需要通过Zookeeper等其他技术解决