Linux Cluster 基础之LVS调度算法与集群类型

　　　　　　　　　　　　Linux Cluster 基础之LVS调度算法与集群类型

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：尹正杰 

版权声明：原创作品，谢绝转载！否则将追究法律责任。

一.LB Cluster

1>.什么是LB

　　LB 集群是 load balance 集群的简写，翻译成中文就是负载均衡集群。常用的负载均衡开源软件有 nginx，lvs，keepalived，HAProxy，ATS，Envoy，Traefik，Kong等；商业的硬件负载设备 F5,Netscale，Big IP，Citrix，A10等。

　　LB 集群的架构如下图，原理也很简单，就是当用户的请求过来时，会直接发到分发器（Director Server）上，然后它把用户的请求根据预先设置好的算法，智能均衡地分发到后端的真正服务器（real server）上。如果不同的机器，可能用户请求到的数据不一样，为了避免这样的情况发生，所以用到了共享存储，这样保证所有用户请求的数据是一样的。

　　如果觉得上图比较复杂，我画了一个简单的图形，如下图所示：

2>.七层LB和四层LB的区别（以OSI模型来区分，OSI是Open System Interconnection的缩写。）

七层调度器：

　　如果协议是通过应用层报文的格式来识别客户端身份并根据算法获取其中数据完成后端服务器挑选的我们将其成为七层调度器（或者应用层调度器）。比如配置负载均衡设备服务类型为http/ftp/https等，负载均衡设备将解析报文到7层，在负载均衡设备与client三次握手之后，只有收到对应七层报文，才会跟RS建立连接。 七层调度器的血线就是同事处理的连接数会小于4W个的！这是受限制与单台主机可以使用随机端口有限！那为什么七层调度器到2019年了还被人津津乐道呢？原因是大多数企业的并发量都在4万以内。只有少数一线互联网公司会超过这个数字，而且这些公司可以用CDN挡住70%以上的静态资源。

四层调度器：

　　如果协议是通过套接字（ip地址:端口号）来识别客户端身份的我们称之为四层调度器。比如配置负载均衡设备上服务类型为tcp/udp，负载均衡设备将只解析到4层，负载均衡设备与client三次握手之后就会和RS建立连接。四层调度器只是将报文丢出去即可，因此他不会受限制单台主机的可以使用的随机端口有限！具有关测试称，四层调度器可以很轻松的实现400W的并发连接数。

3>.IPVS

　　LVS全称为Linux Virtual Server，工作在ISO模型中的第四层，由于其工作在第四层，因此与iptables类似，必须工作在内核空间上。ipvs称之为IP虚拟服务器（IP Virtual Server，简写为IPVS）。是运行在LVS下的提供负载平衡功能的一种技术。因此lvs与iptables一样，是直接工作在内核中的，叫ipvs，主流的linux发行版默认都已经集成了ipvs，因此用户只需安装一个管理工具ipvsadm即可。

　　由于IPVS和iptables有很多相似之处，因此我们不建议大家在同一台服务器同时启用iptable和ipvs服务！这样可能iptable是正常工作的，但是会导致ipvs服务不正常提供的情况！

[[e-mail] ~]#
[[e-mail] ~]# modinfo ip_vs
filename:       /lib/modules/3.10.-.el7.x86_64/kernel/net/netfilter/ipvs/ip_vs.ko
license:        GPL
rhelversion:    7.2
srcversion:     E06AC544DA352A4EDFBC73D
depends:        nf_conntrack,libcrc32c
intree:         Y
vermagic:       3.10.-.el7.x86_64 SMP mod_unload modversions
signer:         CentOS Linux kernel signing key
sig_key:        :AD::6A::3C:A0:::::6C:0F::5B:8A:::6A:B3
sig_hashalgo:   sha256
parm:           conn_tab_bits:Set connections' hash size (int)
[[e-mail] ~]# 

[[e-mail] ~]# modinfo ip_vs　　　　　　　　　　　　#查看ipvs的模块信息

[[e-mail] ~]#
[[e-mail] ~]# grep -i "ip_vs" /boot/config-3.10.-.el7.x86_64
CONFIG_IP_VS=m
CONFIG_IP_VS_IPV6=y
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_AH_ESP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y
CONFIG_IP_VS_PROTO_SCTP=y
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m
CONFIG_IP_VS_SH_TAB_BITS=
CONFIG_IP_VS_FTP=m
CONFIG_IP_VS_NFCT=y
CONFIG_IP_VS_PE_SIP=m
[[e-mail] ~]#
[[e-mail] ~]# 

[[e-mail] ~]# grep -i "ip_vs" /boot/config-3.10.0-327.el7.x86_64

二.Linux Virtual Server（简称LVS）调度算法的分类

1>.静态算法

　仅根据算法本身和请求报文特征进行调度，注重起点公平。典型代表有以下几种：

>.轮询（轮替）算法（RR：round-robin）
　　调度器通过”轮询”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载｡
　　
>.权重算法（WRR：weighted round-robin）
　　调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。适用于短连接无状态的服务！
　　
>.源地址哈希（source ip hashing）
　　根据请求的目标IP地址，作为散列键(HashKey)从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。若需要记录用户的身份，该算法再合适不过啦！
　
>.目标地址哈希（destination ip hashing）
　　提高缓存命中率，最常用于缓存服务器。源地址散列”调度算法根据请求的源IP地址，作为散列键(HashKey)从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空｡

2>.动态算法

　　额外考虑后端各RS的当前的负载状态。注重结果公平。典型代表有以下几种：

>.最少连接算法（LC：least connection）
　　调度器通过”最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用”最小连接”调度算法可以较好地均衡负载。。
　　　　
>.加权最小连接算法（WLC：weighted least connection）
　　在集群系统中的服务器性能差异较大的情况下，调度器采用“加权最少链接”调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载｡调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。很适合RS为MySQL之类的服务！
　　　　
>.最短期望延迟算法（SED：Shortest Expected Delay）
　　改进了wlc算法，不考虑非活动连接数。 在WLC基础上改进，Overhead = （ACTIVE+）*/加权，不再考虑非活动状态，把当前处于活动状态的数目+1来实现，数目最小的，接受下次请求，+1的目的是为了考虑加权的时候，非活动连接过多缺陷：当权限过大的时候，会倒置空闲服务器一直处于无连接状态。
　　　　
>.最少队列调度算法（NQ：Never Queue Scheduling NQ）
　　永不排队，即无需队列。如果有台 realserver的连接数＝0就直接分配过去，不需要再进行sed运算，保证不会有一个主机很空间。在SED基础上无论+几，第二次一定给下一个，保证不会有一个主机不会很空闲着，不考虑非活动连接，才用NQ，SED要考虑活动状态连接，对于DNS的UDP不需要考虑非活动连接，而httpd的处于保持状态的服务就需要考虑非活动连接给服务器的压力。
　　　　
>.基于局部性的最少链接算法（LBLC：locality-Based Least Connections）
　　基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统｡该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器;若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用“最少链接”的原则选出一个可用的服务器，将请求发送到该服务器｡
　　　　
>.带复制的基于局部性最少连接（LBLCR:Locality-Based Least Connections with Replication）
　　带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统｡它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射｡该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按”最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器｡同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。

3>.LVS负载均衡调度算法

.轮询调度
    轮询调度（Round Robin 简称'RR'）算法就是按依次循环的方式将请求调度到不同的服务器上，该算法最大的特点就是实现简单。轮询算法假设所有的服务器处理请求的能力都一样的，调度器会将所有的请求平均分配给每个真实服务器。

.加权轮询调度
    加权轮询（Weight Round Robin 简称'WRR'）算法主要是对轮询算法的一种优化与补充，LVS会考虑每台服务器的性能，并给每台服务器添加一个权值，如果服务器A的权值为1，服务器B的权值为2，则调度器调度到服务器B的请求会是服务器A的两倍。权值越高的服务器，处理的请求越多。

.最小连接调度
    最小连接调度（Least Connections 简称'LC'）算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态的调度算法，它通过服务器当前活跃的连接数来估计服务器的情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1；当连接中断或者超时，其连接数减1。

（集群系统的真实服务器具有相近的系统性能，采用最小连接调度算法可以比较好地均衡负载。)

.加权最小连接调度
    加权最少连接（Weight Least Connections 简称'WLC'）算法是最小连接调度的超集，各个服务器相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

.基于局部的最少连接
    基于局部的最少连接调度（Locality-Based Least Connections 简称'LBLC'）算法是针对请求报文的目标IP地址的 负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的请求调度到同一台服务器，来提高各台服务器的访问局部性和Cache命中率，从而提升整个集群系统的处理能力。LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则使用'最少连接'的原则选出一个可用的服务器，将请求发送到服务器。

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

.目标地址散列调度
    目标地址散列调度（Destination Hashing 简称'DH'）算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且并未超载，将请求发送到该服务器，否则返回空。

.源地址散列调度U
    源地址散列调度（Source Hashing  简称'SH'）算法先根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且并未超载，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法的相同，它的算法流程与目标地址散列调度算法的基本相似。

.最短的期望的延迟
    最短的期望的延迟调度（Shortest Expected Delay 简称'SED'）算法基于WLC算法。举个例子吧，ABC三台服务器的权重分别为1、、 。那么如果使用WLC算法的话一个新请求进入时它可能会分给ABC中的任意一个。使用SED算法后会进行一个运算。举个例子,A：（+）/=   B：（+）/=/   C：（+）/=/   就把请求交给得出运算结果最小的服务器。

.最少队列调度
    最少队列调度（Never Queue 简称'NQ'）算法，无需队列。如果有realserver的连接数等于0就直接分配过去，不需要在进行SED运算。

三.LVS的集群类型（Type）

1>.LVS-NAT

　　简述：多目标的DNAT，通过Director修改请求报文中的目标地址和端口为LVS挑选出来的某RS的RIP和PORT实现转发。如下图所示：

特点：
　　>.RIP和DIP必须在同一网络，且应该使用私网地址，RIP的网关必须指向DIP；
　　2>.Director必须是linux操作系统，RS可以是任意系统；
　　3>.支持端口映射，可修改请求报文的目标POST；
　　4>.请求报文和响应报文都必须经过Director转发，因此较高负载下，Director易成为系统性能瓶颈；

2>.LVS-DR

　　简介：Director为请求报文重新封装一个MAC帧首部进行转发，源MAC地址是DIP所在接口的MAC，目标MAC是挑选出来的的某RS的RIP接口所在的MAC，IP首部不会发生变化(CIP/VIP)。要求DIP和RIP需要在同一个网段上！即中间最好直接使用交换机不要使用路由器进行连接！

一.核心要点：
　　1>.每个RS主机上都应有VIP，并且RIP配置在物理接口上，VIP配置在内置接口lo的别名上(lo:),来自Director的请求报文进来时，经由RIP再到lo:0再到用户空间的进程，回去时控制响应报文先经过lo:(此时源IP已封装成VIP)再由RIP离开，保证客户端接收到的报文源IP是VIP，目标IP是CIP
　　2>.让RS主机禁止响应ARP广播级别和通告级别
　　　　响应级别设定目的：当客户端请求过来时，让Director上的VIP响应，而不是让RS上的VIP响应，保证请求报文一定走Director
　　　　通告级别设定目的：当Director向RS转发时，经由的是RIP的接口，由于RS和Director都有VIP，会造成地址冲突，通过设定ARP通告级别可让其总是避免向非本网络通告(经由的是RIP接口，不会向非RIP接口的网络通告)，因此解决了地址冲突问题

二.过程：
　　1>.客户请求在前端路由器发送ARP广播来获取Director的VIP所在网卡的MAC地址，获知后，在请求报文上封装MAC首部(源MAC是路由器接口的MAC，目标MAC是Director上VIP接口的MAC)，保证将报文发送至Director
　　2>.Director接收到报文后，看到目标地址和目标MAC是自己，于是拆封MAC首部，请求报文进入INPUT链，之后发现是集群服务，于是准备向后端主机转发
　　3>.Director将请求报文(源地址CIP/目标地址VIP)再次封装一个MAC首部(源MAC是DIP的MAC/目标MAC是RIP的MAC)发往后端挑选出来的RS，RS发现目标MAC是自己，拆了MAC首部，发现目标地址是VIP，于是继续向lo:0转发，最终到达用户空间的进程给予响应，开始构建响应报文
　　4>.控制响应报文先经过lo:(此时源IP已封装成VIP)再由RIP离开，保证客户端接收到的报文源IP是VIP，目标IP是CIP;此时可能需要另外一个路由器，如图所示，RIP的网关指向此路由，向外转发

三.特点：
　　1>.RS的RIP可以使用私网地址，也可以使用公网地址；RIP和DIP在同一IP网络；RIP的网关不能指向DIP，以确保响应报文不会经由Director；
　　2>.不支持端口映射
　　3>.RS跟Director必须在同一物理网络(一旦隔开,MAC会变)；RS的网关必须不能指向DIP；
　　4>.请求报文必须由Director调度，但响应报文必须不能经由Director，而是由RS直接发往client；
　　5>.确保前端路由器将目标IP为VIP的请求报文发往Director：
　　　　5.1>.在前端网关做静态绑定；
　　　　5.2>.在RS上修改内核参数以限制ARP通告及应答级别；
　　　　5.3>.在RS上修改内核参数以限制ARP通告及应答级别（arp_announce和arp_ignore）；

3>.LVS-TUNNLE（隧道模式，存在MTU（Maximus Transfer Unit ,默认是1500）隐患）

　　简介：不修改请求报文的IP首部(源地址是CIP，目标地址是VIP)，而是在原IP首部之外再封装一个IP首部(原地址是DIP，目标地址是挑选出来的RS的RIP)，将报文发往挑选出的目标RS；RS直接响应给客户端（源IP是VIP，目标IP是CIP）。

　特点：
　　1>.RIP,DIP,VIP全是公网地址
　　2>.RS的网关不能也不可能指向DIP　　　
　　3>.请求报文经Director转发，但响应不能经由Director，即报文直接从RS发往CIP。
　　4>.不支持端口映射
　　5>.RS的OS必须支持隧道功能 

4>.LVS-FULLNAT(不是标准类型，需要安装插件)

　　简介：NAT模型的一种延伸，通过同时修改请求报文的源IP地址(CIP->DIP)和目标IP(VIP->RIP)进行转发。

特点：
　　1>.VIP是公网地址，RIP和DIP是私网地址，且通常不在同一网络中，但需要经由路由器互通。因此，RIP的网关一般不会指向DIP；
　　2>.RS收到的请求报文源IP为DIP，因此响应报文将直接响应给DIP；但Director还要将其发往Client；
　　3>.支持端口映射；
　　4>.请求报文和响应报文都经由Director；

　　参考链接1：https://blog.csdn.net/weixin_40470303/article/details/80541639

　　参考链接2：https://www.cnblogs.com/trymybesttoimp/p/6194027.html?utm_source=itdadao&utm_medium=referral