LVS专题：LVS的工作模型和调度算法介绍
LVS专题: LVS的工作模型和调度算法介绍
LVS专题: LVS的工作模型和调度算法介绍
静态调度算法(4种)
动态调度算法(6种):
NAT实现原理:
DR实现原理:
TUN实现原理：
FULLNAT实现原理:
前言
什么是负载均衡?
什么是LVS?
LVS的架构:
LVS的实现模型:
LVS的调度算法
总结
前言
本文大概介绍一下LVS的工作方式和实现的模型以及调度算法,流程图方面只上了两张图, 如果有需要LVS各工作模式的流程图请看张小凡:LVS原理详解
什么是负载均衡?
当单台服务器性能不足时我们有两种对其进行扩展的方式, 分别是向上扩展和向外扩展 向上扩展:
向上扩展意思是提升服务器的硬件性能来应对性能不足的问题
向外扩展：
向外扩展意思是新增服务器和现有服务器组成集群来应对性能不足的问题
在这两种解决方案中, 我们一般情况下都选择向外扩展,
因为向上扩展所付出的代价和得到性能的提升不成正比, 大多时候提升服务器一倍的性能需要花费三倍的价格
向外扩展也有很多问题, 例如：如何协调两台服务器提供一服务, 用户在两台服务器进行轮调时如何保存其的session信息….
我们可以将向外扩展数台服务器组成一个负载均衡集群, 前端通过负载均衡调度器来对用户请求通过调度算法合理分发到后端服务器中, 来达到负载均衡的目的.
负载均衡有软件和硬件的实现方式
硬件：F5 BIG IP, NetScaler
软件:
四层: LVS
七层: HAproxy, Nginx, Varnish....
什么是LVS?
LVS(Linux Virtual Server)是目前阿里巴巴首席科学家章文嵩博士在大学期间的一款开源的负载均衡软件, 可实现四层的负载均衡。
为了更好地理解LVS, 我们解释一下相应的术语:
Director: 负载均衡调度器, 负责在前端接受用户请求根据特定的算法转发到后端Real Server
Real Server: 后端提供服务的服务器
VIP: Director接受用户请求的IP地址
DIP: Director和Real Server联系的IP地址
RIP: Real Server的IP地址
CIP: Client IP, 客户端的IP地址
LVS的架构:
LVS其实由两个组件组成, 在用户空间的ipvsadm和内核空间的ipvs, ipvs工作在INPUT链上, 如果有请求报文被ipvs事先定义，就会将请求报文直接截取下根据其特定的模型修改请求报文, 再转发到POSTROUTING链上送出TCP/IP协议栈
其实ipvs提供了一个API, 即使我们不使用ipvsadm这个命令行工具, 也可以使用其他工具对其规则进行定义.
LVS的实现模型:
LVS为了在不同场景中使用而提供了4种实现模型: 分别为
NAT, DR, TUN, FULLNAT. 我们分别对其进行介绍:
NAT实现原理:
NAT模型其实就是一个多路的DNAT, 客户端对VIP进行请求, Director通过事先指定好的调度算法计算出应该转发到哪台RS上, 并修改请求报文的目标地址为RIP,通过DIP送往RS. 当RS响应客户端报文给CIP, 经过Director时, Director又会修改源地址为VIP并将响应报文发给客户端. 这段过程对于用户来说是透明的.
NAT模型工作流程
1、客户端请求VIP
2、Director接受到请求, 根据调度算法得出该转发的RS, 将请求报文的目标IP地址修改成对应RS的IP地址并转发
3、RS接收并响应请求给CIP, 经过Director时, 源地址被修改成VIP地址
实现NAT模型有几点需要注意的:
1、RS和Director必须要在同一个IP网段中
2、RS的网关必须指向DIP
3、可以实现端口映射
4、请求报文和响应报文都会经过Director
5、RS可以是任意操作系统
6、DIP和RIP只能是内网IP
DR实现原理:
DR模型是一个较为复杂的模型. DR模型比较诡异, 因为VIP在Director和每一个RS上都存在, 客户端对VIP(Director)请求时, Director接收到请求, 会将请求报文的源MAC地址和目标MAC地址修改为本机DIP所在网卡的MAC地址和指定的RS的RIP所在网卡的MAC地址, RS接收到请求报文后直接对CIP发出响应报文, 而不需要通过Director
DR模型工作流程
1、客户端请求VIP
2、Director接收到请求报文, 修改请求报文的源MAC地址和目标MAC地址, 使用DIP所在网卡发送给调度算法得出的RIP
3、RIP接收到DIP发过来的报文后, 发现本机的确有VIP, 遂响应报文给CIP
可能很多朋友还听不明白, 所以我们提供了LVS-DR WORK_FLOW便于大家理解
实现DR模型有一个最为关键的问题, 大家都知道Linux主机配置一个IP地址会向本网络进行广播来通告其他主机或网络设备IP地址对应的MAC地址, 那么VIP分别存在于Director和RS, IP不就冲突了么, 我们该如何解决这个问题？
事实上LVS并不能帮助我们解决这个麻烦的问题:
我们有很多种方法可以解决上面的问题:
1、网络设备中设置VIP地址和DIrector的MAC地址进行绑定
2、Linux系统中有一个软件可以实现对ARP广播进行过滤, arptables
3、可以修改内核参数来实现, arp_ignore, arp_announce
实现DR模型需要注意的:
1、RS和Director可以不在同一IP网段中, 但是一定要在同一物理网络中
2、请求报文必须经过Director, 但是响应报文一定不能通过Director
3、RS的网关不能是Director
4、不能实现端口映射
5、RS可以是大部分操作系统
6、DIP和RIP可以是公网地址
TUN实现原理：
TUN模型通过隧道的方式在公网中实现请求报文的转发, 客户端请求VIP(Director), Director不修改请求报文的源IP和目标IP, 而是在IP首部前附加DIP和对应RIP的地址并转发到RIP上, RS收到请求报文, 本地的接口上也有VIP, 遂直接响应报文给CIP
TUN的工作流程
1、客户端请求VIP
2、Director接收到请求, 通过调度算法得出转发的RS,将请求报文的IP首部外附加DIP和对应RS的IP地址，发给对应RS
3、RS接收到请求, 发现本机的确有VIP地址, 遂响应报文给CIP
实现TUN模型需要注意的:
1、RIP,DIP,VIP都是公网地址
2、RS的网关不能指向DIP
3、请求报文必须通过Director, 响应报文一定不能经过Director
4、不支持端口映射
5、RS的操作系统必须支持隧道功能
FULLNAT实现原理:
FULLNAT是近几年才出现的, 客户端请求VIP(Director), Director修改请求报文的源地址(DIP)和目标地址(RIP)并转发给RS, FULLNAT模型一般是Director和RS处在复杂的内网环境中的实现
FULLNAT工作流程
1、客户端请求VIP
2、Director接受到请求, 通过调度算法得出转发的RS, 将源地址修改为DIP, 目标地址修改为对应RIP, 转发给RS
3、RS接受到请求后, 响应请求给DIP, DIP将响应报文源地址改为VIP, 目标地址改为CIP, 响应给CIP
实现FULLNAT模型需要注意的:
1、VIP是公网地址, DIP和RIP是内网地址, 但是无需在同一网络中
2、请求报文需要经过Director, 响应报文也要通过Director
3、RIP接收到的请求报文的源地址为DIP,目标地址为RIP
4、支持端口映射
5、RS可以是任意的操作系统
LVS的调度算法
lvs主要功能将用户请求转发到后端的服务器, 但是Director根据什么来转发到哪个RS上呢？事实上LVS支持10种调度算法计算该将用户请求调度到哪一台RS上.
调度算法分为两种: 静态和动态
静态调度算法: 根据算法本身进行调度, 不考虑RS的状态
动态调度算法: 根据算法和RS的实时负载进行调度
静态调度算法(4种)
RR：Round Robin, 轮询 将用户请求轮询到各个RS上
WRR: Weighted Round Robin, 加权轮轮询, 根据每一台RS的权重将用户请求轮询分发到各个RS上
SH: Source Hash, 源地址哈希， 将同一客户端的请求转发到同一个RS上
DH: Destination Hash, 将同一类型的请求转发到同一个RS上
动态调度算法(6种):
LC：least connections, 最小连接. 公式: Active*256+Inactive
WLC：Weighted Least Connections, 加权最小连接. 公式: (Active*256+Inactive)/Weighted
SED：Shortest Expection Delay, 最短延迟预期. 公式: (Active+1)*256/Weighted
NQ：Never Queue, 永不排队, 对sed算法的改进
LBLC：Locality-Based Least-Connections, 基于局部的最少链接, 即为动态的dh算法
LBLCR：locality-based least-connections replication, 带复制功能的lblc