负载均衡----LVS

LVS集群的通用结构

LVS 集群采用 IP 负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率,将请求均衡地转移到不同的服务器上执行,且调度器自动屏蔽掉服务器的故障,从而将一组服务器构成一个高性能的、高可用的虚拟服务器。

它有三个主要组成部分:

负载调度器(load balancer),它是整个集群对外面的前端机,负责将客户的请求发送到一组服务器上执行,而客户认为服务是来自一个 IP 地址上的。它可以是用 IP 负载均衡技术的负载调度器,也可以是基于内容请求分发的负载调度器,还可以是两者的结合。

当客户请求到达时,调度器只根据负载情况从服务器池中选出一个服务器,将该请求转发到选出的服务器,并记录这个调度;当这个请求的其他报文到达,也会被转发到前面选出的服务器。

 

服务器池(server pool),是一组真正执行客户请求的服务器,执行的服务有 WEB、MAIL、FTP 和 DNS等。

服务器池的结点数目是可变的。当整个系统收到的负载超过目前所有结点的处理能力时,可以在服务器池中增加服务器来满足不断增长的请求负载。

后端存储(backend storage),它为服务器池提供一个共享的存储区,这样很容易使得服务器池拥有相同的内容,提供相同的服务。

   后端存储通常用容错的分布式文件系统,如 AFS、GFS、Coda 和 Intermezzo 等。分布式文件系统为各服务器提供共享的存储区,它们访问分布式文件系统就像访问本地文件系统一样。同时,分布式文件系统提供良好的伸缩性和可用性。

 

IP负载均衡技术

通过NAT实现虚拟服务器(VS/NAT)

在一组服务器前有一个调度器,它们是通过 Switch/HUB 相连接的。这些服务器提供相同的网络服务、相同的内容,即不管请求被发送到哪一台服务器,执行结果是一样的。

 

1 、client IP : VIP ----→  2、cip: real IP

3 、rip:cip ----→  4、vip:cip

 

客户通过 Virtual IP Address(虚拟服务的 IP 地址)访问网络服务时,请求报文到达调度器,调度器根据连接调度算法从一组真实服务器中选出一台服务器,将报文的目标地址 Virtual IP Address 改写成选定服务器的地址,报文的目标端口改写成选定服务器的相应端口,最后将修改后的报文发送给选出的服务器。同时,调度器在连接 Hash 表中记录这个连接,当这个连接的下一个报文到达时,从连接 Hash 表中可以得到原选定服务器的地址和端口,进行同样的改写操作,并将报文传给原选定的服务器。当来自真实服务器的响应报文经过调度器时,调度器将报文的源地址和源端口改为 Virtual IP Address 和相应的端口,再把报文发给用户。这样,客户所看到的只是在 Virtual IP Address 上提供的服务,而服务器集群的结构对用户是透明的。

下面,举个例子来进一步说明 VS/NAT,

VS/NAT 的配置如下表所示,所有到 访问IP 地址为 202.103.106.5 和端口为 80 的流量都被负载均衡地调度的真实服务器 172.16.0.2:80 和 172.16.0.3:8080 上。

Protocol	Virtual IP	Port	Real IP	Port	Weight
TCP	202.103.106.5	80	172.16.0.2 172.16.0.3	80 8080	1 2

从以下的例子中,我们可以更详细地了解报文改写的流程。

访问 Web 服务的报文可能有以下的源地址和目标地址：

SOURCE

202.100.1.2:3456

DEST

202.103.106.5:80

调度器从调度列表中选出一台服务器,例如是 172.16.0.3:8080。该报文会被改写为如下地址（DNAT）,并将它发送给选出的服务器。

SOURCE

202.100.1.2:3456

DEST

172.16.0.3:8080

从服务器返回到调度器的响应报文如下:

SOURCE

172.16.0.3:8080

DEST

202.100.1.2:3456

响应报文的源地址会被改写为虚拟服务的地址,再将报文发送给客户:

SOURCE

202.103.106.5:80

DEST

202.100.1.2:3456

 

这样,客户认为是从 202.103.106.5:80 服务得到正确的响应,而不会知道该请求是服务器 172.16.0.2 还是服务器 172.16.0.3 处理的。

 

通过IP隧道实现虚拟服务器(VS/TUN)

IP 隧道(IP tunneling)是将一个 IP 报文封装在另一个 IP 报文的技术,这可以使得目标为一个 IP 地址的数据报文能被封装和转发到另一个 IP 地址。IP 隧道技术亦称为 IP 封装技术(IP encapsulation)。IP 隧道主要用于移动主机和虚拟私有网络(Virtual Private Network),在其中隧道都是静态建立的,隧道一端有一个 IP 地址,另一端也有唯一的 IP 地址。我们利用 IP 隧道技术将请求报文封装转发给后端服务器,响应报文能从后端服务器直接返回给客户。

VS/TUN 的工作流程如图所示:它的连接调度和管理与 VS/NAT 中的一样,只是它的报文转发方法不同。调度器根据各个服务器的负载情况,动态地选择一台服务器,将请求报文封装在另一个 IP 报文中,再将封装后的 IP 报文转发给选出的服务器;服务器收到报文后,先将报文解封获得原来目标地址为 VIP 的报文,

服务器发现 VIP 地址被配置在本地的 IP 隧道设备上,所以就处理这个请求,然后根据路由表将响应报文直接返回给客户。

在 VS/TUN 中,请求报文的目标地址为 VIP,响应报文的源地址也为 VIP,所以响应报文不需要作任何修改,可以直接返回给客户,而不经过负载调度器，客户认为得到正常的服务,而不会知道是哪一台服务器处理的。

 

通过直接路由实现虚拟服务器(VS/DR)

VS/DR 的体系结构如图所示:调度器和服务器组都必须在物理上有一个网卡通过不分段的局域网相连,即通过交换机或者高速的 HUB 相连。VIP 地址为调度器和服务器组共享,调度器配置的 VIP 地址是对外可见的,用于接收虚拟服务的请求报文;所有的服务器把 VIP 地址配置在各自的Non-ARP 网络设备上,它对外面是不可见的,只是用于处理目标地址为 VIP 的网络请求。

在 VS/DR 中,调度器根据各个服务器的负载情况,动态地选择一台服务器,不修改也不封装 IP 报文,而是将数据帧的 MAC 地址改为选出服务器的 MAC 地址,再将修改后的数据帧在与服务器组的局域网上发送。因为数据帧的 MAC 地址是选出的服务器,所以服务器肯定可以收到这个数据帧,从中可以获得该 IP 报文。当服务器发现报文的目标地址 VIP 是在本地的网络设备上，服务器处理这个报文,然后根据路由表将响应报文直接返回给客户。

 

 

   新转发模式FULLNAT:实现LVS-RealServer间跨vlan通讯,并且in/out流都经过LVS;

 

各种方法的优缺点比较

（1）NAT的优缺点

优点：服务器可以运行任何支持 TCP/IP 的操作系统,它只需要一个 IP 地址配置在调度器上,服务器组可以用私有的 IP 地址；

不足：伸缩能力有限,当服务器结点数目升到 20 时,调度器本身有可能成为系统的新瓶颈,因为在 VS/NAT 中请求和响应报文都需要通过负载调度器；

（2）TUN的优缺点

优点：调度器只将请求调度到不同的后端服务器,后端服务器将应答的数据直

接返回给用户，因而，调度器会处理更多的请求；

不足：后端服务器必须支持“IP Tunneling”或者“IP Encapsulation”协议；

RS配置复杂(IPIP模块等)；

（3）DR的优缺点

优点：调度器只处理客户到服务器端的连接,响应数据可以直接从独立的网络路

由返回给客户；

转发效率最高；

不足：要求负载调度器与实际服务器都有一块网卡连在同一物理网段上,服务器网络设备(或者设备别名)不作 ARP 响应；

RS上绑定VIP；风险大；

 

连接调度算法

1、轮叫调度(Round-Robin Scheduling)

“轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。算法的优点是其简洁性,它无需记录当前所有连接的状态,所以它是一种无状态调度。

在系统实现时，我们引入了一个额外条件,当服务器的权值为零时，表示该服务器不可用而不被调度。这样做的目的是将服务器切出服务(如屏蔽服务器故障和系统维护)，同时与其他加权算法保持一致。

2、加权轮叫调度(Weighted Round-Robin Scheduling)

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

3、最小连接调度(Least-Connection Scheduling)

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

4、加权最少链接（Weighted Least Connections）

  在集群系统中的服务器性能差异较大的情况下，调度器采用“加权最少链接”调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

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

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

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

   “带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个 目标 IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。

   LBLCR 算法先根据请求的目标 IP 地址找出该目标 IP 地址对应的服务器组;按“最小连接”原则从该服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器;若服务器超载;则按“最小连接”原则从整个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器

组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度。

7、目标地址散列（Destination Hashing）

该算法也是针对目标 IP 地址的负载均衡,但它是一种静态映射算法,通过一个散列(Hash)函数将一个目标 IP 地址映射到一台服务器。目标地址散列调度算法先根据请求的目标 IP 地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。

8、源地址散列（Source Hashing）

   “源地址散列”调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

   在实际应用中,源地址散列调度和目标地址散列调度可以结合使用在防火墙集群中,它们可以保证整个系统的唯一出入口。

 

 

LVS 常见问题:

1. LVS/DR 如何处理请求报文的,会修改 IP 包内容吗?

 vs/dr 本身不会关心 IP 层以上的信息,即使是端口号也是 tcp/ip 协议栈去判断是否正确,vs/dr 本身主要做这么几个事:

1)接收 client 的请求,根据你设定的负载均衡算法选取一台 realserver 的 ip;

2)以选取的这个 ip 对应的 mac 地址作为目标 mac,然后重新将 IP 包封装成帧转发给这台 RS;

3)在 hashtable 中记录连接信息。

vs/dr 做的事情很少,也很简单,所以它的效率很高,不比硬件负载均衡设备差多少。

数据包、数据帧的大致流向是这样的:client --> VS --> RS --> client前面已作了回答,vs/dr 不会修改 IP 包的内容.

2. RealServer 为什么要在 lo 接口上配置 VIP,在出口网卡上配置 VIP 可以吗?

 既然要让 RS 能够处理目标地址为 vip 的 IP 包,首先必须要让 RS 能接收到这个包。在 lo 上配置 vip 能够完成接收包并将结果返回 client。

 答案是不可以将 VIP 设置在出口网卡上,否则会响应客户端的 arp request,造成 client/gateway arp table 紊乱,以至于整个 loadbalance 都不能正常工作。

3. RealServer 为什么要抑制 arp 帧?

这个问题在上一问题中已经作了说明,这里结合实施命令进一步阐述。我们在具体实施部署的时候都会

作如下调整:

echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore

echo "2">/proc/sys/net/ipv4/conf/lo/arp_announce

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

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

我相信很多人都不会弄懂它们的作用是什么,只知道一定得有。我这里也不打算拿出来详细讨论,只是

作几点说明,就当是补充吧。

echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore

echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce

这两条是可以不用的,因为 arp 对逻辑接口没有意义。

 如果你的 RS 的外部网络接口是 eth0,那么

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

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

其实真正要执行的是:

echo "1">/proc/sys/net/ipv4/conf/eth0/arp_ignore

echo "2">/proc/sys/net/ipv4/conf/eth0/arp_announce

所以我个人建议把上面两条也加到你的脚本里去,因为万一系统里上面两条默认的值不是 0,那有可能是会出问题滴。

4. LVS/DR loadbalancer(director)与 RS 为什么要在同一网段中?

从第一个问题中大家应该明白 vs/dr 是如何将请求转发给 RS 的了吧?它是在数据链路层来实现的,所以 director 必须和 RS 在同一网段里面。

5. 为什么 director 上 eth0 接口除了 VIP 另外还要配一个 ip(即 DIP)?

 如果是用了 keepalived 等工具做 HA 或者 LoadBalance,则在健康检查时需要用到 DIP

 没有健康检查机制的 HA 或者 Load Balance 则没有存在的实际意义.

6. LVS/DRip_forward 需要开启吗?

不需要。因为 director 跟 realserver 是同一个网段,无需开启转发。