LVS负载均衡技术
本篇文章主要介绍LVS
集群的负载均衡技术以及负载均衡调度算法。
负载均衡技术包括以下3
种:
NAT
:网络地址转换。TUN
:IP
隧道模式。相比NAT
性能提升10倍DR
:物理地址转换。改写请求报文的MAC
地址,将请求发送到真实服务器
负载调度算法包括以下8
种:
- 轮询调度
- 加权轮询
- 最小连接数调度
- 加权最小连接数
- 基于局部的最小连接数调度
- 带复制的基于局部性的最小连接数调度
- 目标地址哈希
- 原地址哈希
下面我们就先来看看LVS
的负载均衡技术
LVS负载均衡技术
VS/NAT
架构如下:
在一组服务器前有一个调度器,它们是通过Switch/HUB相连接的。这些服务器提供相同的网络服务、相同的内容,即不管请求被发送到哪一台服务器,执行结果是一样的。服务的内容可以复制到每台服务器的本地硬盘上,可以通过网络文件系 统(如NFS)共享,也可以通过一个分布式文件系统来提供。
当前在公有云上非常容易实现此类架构。后端服务器都在同一个局域网,提供相同的服务;服务入口是一个负载均衡器
,负载均衡器后端为真实服务器,轮询调度请求。这就是上面的架构。
更详细的请求过程如下:
- 当用户发起请求
Director Server
,此时请求的数据报文会先到内核空间的PREROUTING链
。 此时报文的源IP
为CIP
,目标IP
为VIP
PREROUTING
检查发现数据包的目标IP
是本机,将数据包送至INPUT链
IPVS
比对数据包请求的服务是否为集群服务,若是,修改数据包的目标IP
地址为后端服务器IP
,然后将数据包发至POSTROUTING链
。 此时报文的源IP
为CIP
,目标IP
为RIP
POSTROUTING链
通过选路,将数据包发送给Real Server
服务器Real Server
比对发现目标为自己的IP
,开始构建响应报文发回给Director Server
。 此时报文的源IP
为RIP
,目标IP
为CIP
Director Server
在响应客户端前,此时会将源IP
地址修改为自己的VIP
地址,然后响应给客户端。 此时报文的源IP
为VIP
,目标IP
为CIP
以上就是VS/NAT
的详细过程,和利用iptables
实现的DNAT
技术一摸一样!此过程种客户端完全无感知,客户端以为真实服务器地址就是它请求的DR地址
。
VS/NAT模式小结
优点:
- 实现简单
- 支持端口映射。
DR
端口和RS
端口可以不一致
缺点:
RS
应该使用私有地址,RS
的网关必须指向DIP
RS
和DR
需要在同一内网- 流量进出都会经过
DR
,DR
会快速成为瓶颈
VS/TUN
IP隧道
:将一个IP报文
封装在另一个IP报文
里面的技术!
TUN
模式架构如下:
它的连接调度和管理与VS/NAT
中的一样,只是它的报文转发方法不同。调度器根据各个服务器的负载情况,动态地选择一台服务器, 将请求报文封装在另一个IP
报文中,再将封装后的IP
报文转发给选出的服务器;服务器收到报文后,先将报文解封获得原来目标地址为VIP
的报文,服务器发现VIP
地址被配置在本地的IP隧道
设备上,所以就处理这个请求,然后根据路由表将响应报文直接返回给客户。
详细的请求过程如下:
- 客户端请求到达
DR
服务,此时请求的报文会先到达内核空间的PREROUTIN链
。此时报文的源IP
为CIP
,目的IP
为VIP
。 PREROUTING链
检查发现数据包的目标IP
是本机,将数据包送至INPUT链
IPVS
比对数据包请求的服务是否为集群服务,若是,在请求报文的首部再次封装一层IP报文
,封装源IP
为DIP
,目标IP
为RIP
。然后发至POSTROUTING链
。 此时源IP
为DIP
,目标IP
为RIP
POSTROUTING链
根据最新封装的IP
报文,将数据包发至RS
(此时其实是走的IP隧道
进行传输,通过公网,将数据包发送到目的RS
)。 此时源IP
为DIP
,目标IP
为RIP
RS
接收到报文后发现是自己的IP
地址,就将报文接收下来,然后开始解包,拆除掉最外层的IP
后,发现里面还有一层IP
首部,而且目标是自己的lo接口VIP
,那么此时RS
又开始处理此请求,处理完成之后,通过lo接口
送给eth0网卡
,然后向外传递。 此时的源IP
地址为VIP
,目标IP
为CIP
- 响应报文最终送达至客户端。此时的
源IP
地址为VIP
,目标IP
为CIP
- 客户端处理完成之后,可能又会向
VIP
发起下一轮请求!
详细的处理过程就是上面这样,对于客户端来说,它完全是无感知的。客户端以为真实的服务器地址就是DR地址
,客户端并不知道在DR
之后还做了几次IP隧道
转发,它也不在乎这个!
VS/TUN模式小结
优点:
- 对
RIP、VIP、DIP
的网络没有限制,可以不在同一个局域网 - 流量只会从
DR
进,但不会从DR
出,所以大大减少了DR
的负载。性能提升10倍+
缺点:
DR、RS
所有服务器都需要配置相同的虚拟IP VIP
- 所有服务器需要支持
IP隧道
技术 IP隧道
会有额外的开销和网络延迟- 不支持端口映射
RS
服务器不能回复arp
包
VS/DR
物理地址修改技术,架构如下:
它的连接调度和管理与VS/NAT
和VS/TUN
中的一样,它的报文转发方法又有不同,将报文直接路由给目标服务器。在VS/DR
中,调度器根据各个服务器的负载情况,动态地选择一台服务器,不修改也不封装IP报文
,而是将数据帧的MAC地址
改为选出服务器的MAC地址
,再将修改后 的数据帧在与服务器组的局域网上发送。因为数据帧的MAC地址
是选出的服务器,所以服务器肯定可以收到这个数据帧,从中可以获得该IP报文
。当服务器发现 报文的目标地址VIP
是在本地的网络设备上,服务器处理这个报文,然后根据路由表将响应报文直接返回给客户。
详细的请求过程如下:
- 当用户请求到达
Director Server
,此时请求的数据报文会先到内核空间的PREROUTING链
。 此时报文的源IP
为CIP
,目标IP
为VIP
PREROUTING链
检查发现数据包的目标IP
是本机,将数据包送至INPUT链
IPVS
比对数据包请求的服务是否为集群服务,若是,将请求报文中的源MAC地址
修改为DIPMAC地址
,将目标MAC地址
修改RIP的MAC地址
,然后将数据包发至POSTROUTING链
。 此时的源IP
和目的IP
均未修改,仅修改了源MAC地址
为DIP的MAC地址
,目标MAC地址
为RIP的MAC地址
- 由于
DS
和RS
在同一个网络中,所以是通过二层来传输。POSTROUTING链
检查目标MAC地址
为RIP的MAC地址
,那么此时数据包将会发至Real Server
RS
发现请求报文的MAC地址
是自己的MAC地址
,就接收此报文。处理完成之后,将响应报文通过lo接口
传送给eth0网卡
然后向外发出。 此时的源IP
地址为VIP
,目标IP
为CIP
- 响应报文最终送达至客户端
DR
模式下的转发过程比较简单,仅修改了源MAC地址
和目的MAC地址
。当然,这些对于客户端来说都是透明化的,客户端以为真实的服务器地址就是DR地址
。
VS/DR模式小结
优点:
- 该模式性能最高,可以提升到极致
- 流量只会从
DR
进,但不会从DR
出,所以大大减少了DR
的负载。性能提升100倍+
缺点:
DR服务器
和RS服务器
必须要在同一局域网,能够直接通过数据链路层进行通信DR
和RS
需要绑定同一个虚拟IP VIP
- 不支持端口映射
RS
不能回复arp
包
负载均衡技术总结
模式 | 优点 | 缺点 |
---|---|---|
NAT | 1、简单 2、支持端口映射 |
1、RS 应该使用私有地址,RS 的网关必须指向DIP 2、 RS 和DR 需要在同一内网3、流量进出都会经过 DR ,DR 会快速成为瓶颈 |
TUN | 1、对RIP、VIP、DIP 的网络没有限制,可以不在同一个局域网2、流量只会从 DR 进,但不会从DR 出,所以大大减少了DR 的负载。性能提升10倍+ |
1、DR、RS 所有服务器都需要配置相同的虚拟IP VIP 2、所有服务器需要支持 IP隧道 技术3、 IP隧道 会有额外的开销和网络延迟4、不支持端口映射 5、 RS 服务器不能回复arp 包 |
DR | 1、该模式性能最高,可以提升到极致 2、流量只会从 DR 进,但不会从DR 出,所以大大减少了DR 的负载。性能提升100倍+ |
1、DR服务器 和RS服务器 必须要在同一局域网,能够直接通过数据链路层进行通信2、 DR 和RS 需要绑定同一个虚拟IP VIP 3、不支持端口映射 4、 RS 不能回复arp 包 |
负载均衡调度算法
IPVS
在内核种的负载调度能力是以连接
为单位的!
轮询调度
轮叫调度(Round Robin Scheduling)算法就是以轮叫的方式依次将请求调度不同的服务器,即每次调度执行i = (i + 1) mod n
,并选出第i台服务器。算法的优点是其简洁性,它无需记录当前所有连接的状态,所以它是一种无状态调度。
- 无需记录当前连接状态
- 无状态调度
- 假设所有服务器的处理性能都是相同的
加权轮询调度
加权轮叫调度(Weighted Round-Robin Scheduling)算法可以解决服务器间性能不一的情况
,它用相应的权值表示服务器的处理性能,服务器的缺省权值为1
。假设服务器A
的权值为1
,B
的权值为2
,则表示服务器B
的处理性能是A
的两倍。
加权轮叫调度算法是按权值的高低和轮叫方式分配请求到各服务器。权值高的服务器先收到的连接,权值高的服务器比权值低的服务器处理更多的连接,相同权值的服务器处理相同数目的连接数。
- 无需记录当前连接状态
- 无状态调度
- 引入权重概念,权重越大,收到的请求会越多
最小连接数调度
最小连接调度(Least-Connection Scheduling)算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态调度算法,它通过服务器当前所活跃的连接数来估计服务 器的负载情况。调度器需要记录各个服务器已建立连接的数目,当一个请求被调度到某台服务器,其连接数加1
;当连接中止或超时,其连接数减一。
- 有状态
- 动态调度
- 记录各个服务器的连接数
加权最小连接数调度
加权最小连接调度(Weighted Least-Connection Scheduling)算法是最小连接调度的超集,各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1
,系统管理员可以动态地设置服务器的权 值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。
- 最小连接数调度的超集
- 调度新连接时,尽可能使连接数和权重成比例。若不行,则使用最小连接数调度
基于局部的最少连接调度
基于局部性的最少链接调度(Locality-Based Least Connections Scheduling,以下简称为LBLC)算法是针对请求报文的目标IP地址的负载均衡调度,目前主要用于Cache集群系统
,因为在Cache集群
中客户请求报文的目标IP
地址是变化的。这里假设任何后端服务器都可以处理任一请求,算法的设计目标是在服务器的负载基本平衡情况下,将相同目标IP地址的 请求调度到同一台服务器,来提高各台服务器的访问局部性和主存Cache命中率
,从而整个集群系统的处理能力。
LBLC调度算法
先根据请求的目标IP
地址找出该目标IP
地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于其一半的工作负载,则用“最少链接”的原则选出一个可用的服务器,将请求发送到该服务器。
- 需要维护一组
IP地址
---->1台后端服务器
的一个映射表。该表需要进行周期性的检查
带复制的基于局部性的最少连接调度
带复制的基于局部性最少链接调度(Locality-Based Least Connections with Replication Scheduling,以下简称为LBLCR)算法也是针对目标IP
地址的负载均衡,目前主要用于Cache集群系统
。它与LBLC算法
的不同之处是它要维护从一个目标IP
地址到一组服务器的映射,而LBLC算法
维护从一个目标IP
地址到一台服务器的映射。
对于一个“热门”
站点的服务请求,一台Cache 服务器
可能会忙不过来处理这些请求。这时,LBLC调度算法
会从所有的Cache
服务器中按“最小连接”原则选出一台Cache
服务器,映射该“热门”站 点到这台Cache
服务器,很快这台Cache
服务器也会超载,就会重复上述过程选出新的Cache
服务器。这样,可能会导致该“热门”站点的映像会出现在所有的Cache
服务器上,降低了Cache
服务器的使用效率。
LBLCR调度算法
将“热门”
站点映射到一组Cache
服务器(服务器集合),当该“热门”站点的请求负载增加时,会增加集合里的Cache
服务器,来处理不断增长的负载;当该“热门”站点的请求负载降低时,会减少集合里的Cache
服务器数目。这样,该“热门”站点的映像不太可能出现在所有的Cache
服务器上,从而提供Cache
集群系统的使用效率。
LBLCR算法
先根据请求的目标IP
地址找出该目标IP
地址对应的服务器组;按“最小连接”原则从该服务器组中选出一台服务器,若服务器没有超载, 将请求发送到该服务器;若服务器超载;则按“最小连接”原则从整个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该 服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度。
- 需要维护一组
IP地址
---->1组后端服务器
的一个映射表。该表需要进行周期性的检查
目标地址散列调度
目标地址散列调度(Destination Hashing Scheduling)算法也是针对目标IP地址的负载均衡,但它是一种静态映射算法,通过一个散列Hash函数
将一个目标IP
地址映射到一台服务器。
目标地址散列调度算法先根据请求的目标IP
地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
目标IP
地址的负载均衡- 静态映射算法,通过
hash
函数映射到一台服务器 - 主要用于防火墙集群
原地址散列调度
源地址散列调度(Source Hashing Scheduling)算法正好与目标地址散列调度算法相反,它根据请求的源IP
地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。它采用的散列函数与目标地址散列调度算法 的相同。它的算法流程与目标地址散列调度算法的基本相似,除了将请求的目标IP
地址换成请求的源IP
地址,所以这里不一一叙述。
- 和
目标地址散列调度
相同,但为源IP
总结
以上就是LVS负载技术
和LVS负载调度算法
的相关描述。如有问题,可在评论区指出。
同时可以参考lvs社区
的几篇文章,链接如下:
http://www.linuxvirtualserver.org/zh/lvs1.html
http://www.linuxvirtualserver.org/zh/lvs2.html
http://www.linuxvirtualserver.org/zh/lvs3.html
http://www.linuxvirtualserver.org/zh/lvs4.html