集群之负载均衡集群

向右看齐 2022-07-14 02:24 363阅读 0赞

一、说LVS不能不说集群，下面先来说说集群。

在没有集群以前，互联网还没有兴起，一台服务器通常能完成基本的工作，随着互联网的兴起，web应用的流行，上网的用户越来越多，一台服务器的负载越来越大，于是大家便购买更高配置的服务器，以期望能承担更大的负担，在没有集群以前确实是这么做的，这就是所谓的Scale Up.但是每升级一次花费的金钱越来越多，并且服务需终止，当这台服务器宕机时服务也终止了，没有高可用可言，并且浪费了以前的机器。集群的出现解决了这个问题，多台一般的机器组成一个集群，集体响应客户请求，实现负载均衡，当压力大的时候再添加一台机器到集群里面，所以集群的伸缩性也很好。当一台机器挂点了，通过某种方法自动屏蔽掉它，从而实现了高可用。一台机器完成不了的任务，如分析大量的日志，而用10台性能一般的机器组成的集群很快会分析完成。

根据用途可将集群分为三类：

> 1.负载均衡集群—LB Cluster (Load Balance)
> 
> 当大量用户并发访问时，将请求转发到不同的机器止实现负载均衡。
> 
> 2.高可用集群—HA Cluster (High Availability)
> 
> 服务器的状态一直被监测着，当一台主机出现问题后屏蔽掉它或备用主机代替，从而不让服务中断，实现高可用。
> 
> 3.高性能集群—HP Cluster (High performance)
> 
> 把一个任务分配到很多台机器上来完成，这样就实现了高性能

二、我们的LVS可以用来构建负载均衡集群，来说说LVS的三种模型

在说模型之前得先来说说一些术语：

ipvs:LVS是工作在四层上，根据IP来实现负载均衡。ipvs是定义再内核中的框架，工作在INPUT链上，当请求到达INPUT链时，内核发现是LVS定义在ipvs框架上的服务，修改目标IP或mac转发到FORWARD链上，再经POSTROUTING链转发到真实的主机上。

[![222227682.jpg][]][222227682.jpg]

Director调度器:用户请求先到达的主机。它根据工作模型与调度方法把请求转发到真实服务器上

RS:RealServer，真正响应用户请求服务器

VIP:Virtual IP，一般为一个公网IP，是用户直接访问的IP，此IP所在的主机不直接提供服务，所以该主机称为Virtual Server，一般为调度器，该IP称为VIP

DIP:Direct IP,与RS通信的IP

RIP:Real IP,真正响应用户的主机的IP

CIP:Client IP,客户端请求IP

1.Virtual Server via Network Address Translation（NAT）

[![222250114.jpg][]][222250114.jpg]

用户请求到达Director，Director根据ipvs上生效的规则算法修改报文的目标IP为真实服务器的RIP，然后转发到后端的RS上，RS收到报文后构建响应报文，然后再发到Director，Director再将报文的的源IP即RIP还原为VIP发给用户。整个过程就是这样，你也许会发现这个于DNAT很像。请求经过Director报文更改 \[CIP:VIP\]-->Director后-->\[CIP:RIP\] 响应报文经过Director:\[RIP:CIP\]-->Director-->\[VIP:CIP\]

NAT模式特点：

> 1.Dirctor 与 RealServer 同一网络中  
> 2.RIP通常使用Private IP  
> 3.Directory 工作在Client和RS中间，负责处理进出的全部报文  
> 4.各RS网关要指向DIP  
> 5.Directory 可实现端口映射  
> 6.任何系统可用于RS  
> 7.Director可能成为性能瓶颈

2.Virtual Server via Direct Routing（DR）

[![222307955.jpg][]][222307955.jpg]

因为NAT模型下Director很容易成为整个系统的瓶颈，所以DR模式下Director不再转发响应的报文，相对于响应报文，请求报文要小的多，这样Director就被释放出来了，具体流程是怎样的呢,我们结合上图来说：

当请求报文到达路由后，路由如果有VIP的mac地址，就直接修改目标mac为VIP的mac，如果没有就发广播请求VIP的mac，然后发给交换机，交换机把报文送到VIP后,Director根据调度算法选择一个RealServer,把报文中的目标mac改为选择的RealServer的mac，然后发回交换机，交换机根据报文目标mac将报文发向了RealServer,RealServer收到报文后，会检查报文的目标IP，发现目标IP是VIP而本机没有VIP就舍弃报文，所以RS上必须设置个VIP地址，然而这样会导致IP冲突的，我们必须解决这个问题才能实现整个流程，解决这个问题的方法有很多，常用的是让隐藏RS上的VIP，不响应关于它的任何ARP请求，也不向外发送关于VIP的ARP广播，这样就不会导致IP冲突了。这时当报文到达RS时，RS会接受报文，并响应请求，但是默认情况下，响应报文的源IP是RIP，当这个报文发到Client时，客户端检查报文会发现源IP不是自己请求的IP，会舍弃该报文，所以RS的响应报文源IP应该是VIP，这就需要在RS中加条路由，凡是目标IP是VIP的报文，先从定义VIP那设备出去，这样源IP就是VIP了。响应报文发向Switch，经由Router响应用户，不用经过Director了。这也是生产环境中最常用的。\[CIP:VIP\]:\[TMAC:VMAC\]-->Director-->\[CIP:VIP\]:\[TMAC:RMAC\]-->到达RS-->\[VIP:CIP\]:\[RMAC:TMAC\]-->各层路由后-->到达Client （TMAC指的是路由MAC)

DR模式的特点：

1.DIP和RIP必须在同一个物理网络中，它的转发机制是基于Mac地址转发

2.RIP可以使用公网地址（建议）

3.Director仅处理请求而不处理响应

4.集群节点（Real Server）的网关不能指向DIP。

5.不支持端口转换

6.绝大多数的操作系统都可以实现Real Server

7.比NAT模型的Director能带动更多的RealServer

3.Virtual Server via IP Tunneling（TUN）

[![222336963.jpg][]][222336963.jpg]

由于DR模式需要DR与RS在一个物理网络，而TUN模式就是为了解决这个限制的。具体见下流程：

当Client请求报文经过互联网到达Director后，Director根据调度算法选择一个RealServer来响应请求，但这次不是修改MAC地址了，因为RS与Director没在一个物理网内，即使修改MAC也不能传送到RealServer，所以用IP-Tunneling协议，在原来报文基础上再封装一层源IP目标IP源MAC目标MAC，就可以通过互联网传送到RS了，RS本身也支持IP-Tunneling，所以它能理解到这个报文的真正意思，它会剥掉外层的ip与mac根据里层的ip做出响应，也就是回应Client了，它也需要用VIP来响应Client所以后面的与DR一样了。\[CIP:VIP\]:\[TMAC:VMAC\]-->Director-->\[\[CIP:VIP\]:\[TMAC:RMAC\]\]:\[VMAC:TMAC\]:\[VIP:DIP\]-->互联网-->到达RS，响应-->\[VIP:CIP\]:\[RMAC:TMAC\]-->各层路由后-->到达Client  （TMAC指的是路由MAC)

TUN模式特点：  
        1.RS跟Director不必在同一网络中  
        2.RIP一定不能使用私有地址  
        3.Director只处理请求报文  
        4.响应报文不能经过Director  
        5.不能使用端口映射  
        6.仅允许支持隧道协议的OS用于RS

模式总结：NAT模式由于所有的报文都经过Director，所以Director在大规模集群中成为瓶颈，通常在6-10后就会明显，但是它实现起来容易，并且一个公网IP即可。

DR模式在生产环境中是最常用的，它不会受Director瓶颈影响，所以大规模中效率很高，但需要RS的IP为公网IP（私网IP也可以实现但与NAT模式一样会受到Director的制约），它要求DR与RS在一个物理网络中。IP-Tunneling模式不受地域限制，所以可以实现异地容灾，但是它需要DR与RS都必须支持IP-Tunneling协议，实现起来也比较麻烦，所以还不是很常用。

三、下面来说说LVS的调度算法，分为两类：静态算法与动态算法

静态：仅根据算法本身调度，不关心RS上的连接状态

RR(RoundRobin):轮调

所有的请求依次轮流分配到后端RS,如果机器性能不一致则负载均衡失去意义。

WRR:加权weight,不能反映服务器的状态

WRR在RR的基础上加上了权重，能者多劳，性能好的多分配，性能差的少分配，比例与设置的权重值成正比。

DH:Destination Hashing  hash为个保证唯一性 用于缓存

根据目标地址的hash来分配RealServer，假如A曾经访问过RS1，下次A再访问时还把A高度到RS1。

SH:Source Hashing

Director必须确保响应的数据包必须通过请求数据包所经过的路由器或者防火墙（保证原地址不变）。

动态：要将RS的连接状态记入调度考量标准

LC:Least Connetions  Overhead=active\*256+inactive

假如有10个请求根据WRR算法，RS1,RS2分别被分配了5个，但是RS2上的链接都中止了，而RS1的用户还继续访问中，再来一个请求，根据WRR算法将被负载到RS1，显然这样是符合负载均衡要求的，所以有了最小连接算法，下一个请求来时谁的连接少将会把这个请求给谁。

WLC:Weight Least Connetions Overhead=(active\*256+inactive)/weight  常用

再LC的基础上加了权重，理由与WRR一样。

SED:Overhead=（active+1）\*256/weight

假如有这种状况，RS1最多可以负载20个请求，RS2可以负载100个请求，这时RS1上已有20个连接，RS2上已有100个连接，如果再来一个请求，由于RS1在上面所以这个请求会给RS1，但是我们知道这个请求给RS2时可能影响不大，如果给RS1可能会造成RS1负载多大，所以就有了这个算法。

NQ:Never Queue

RS1最多可以负载20个请求，RS2可以负载100个请求，由于SED的算法我们可以计算，当第一个请求到来时会给RS2,第二个请求来时也会给RS2,第三个来请求来时也会给RS2，显然这是违背负载均衡原则的，NQ算法指即使RS1你性能再不济也得分配给它一个。

LBLC:Locality-Based Least connection 结合DH+RC   缓存常用

假如有这种情况：RS1,RS2各负载了10个连接，然后RS2上的连接全离开了，且不再来了，而RS1的连接都还在，再来一个请求，假如RS1在规则上面可能被分配RS1上，这是不符合负载均衡原则的

LBLCR:Locality-Based Least Replication 可以共享缓存

带复制的LBLC，RS之间通过复制共享缓存

三、LVS的持久连接

由于http是无状态的连接，客户每次请求会被当做新请求，比如我们登录了一个论坛，以刷新页面，服务器会把你当新访问，你还得重新登录，这样很不方便，尤其在电子商务类的网站上，好不容易选了好多商品准备付款，刷新了一次或者网页跳转了一次信息都丢失了。为了追踪客户的状态，才有了cookies 和session。cookies是什么？它是动态网站发给每个客户端的一个识别码SessionID，识别码是有有效期的。session中文意思是会话，服务器端发给客户端一个识别码，服务器端会也会把这个识别码保存到文件上，这个文件包含了客户端的识别码与一些客户端访问过页面的信息，所以我们登录论坛后，服务器会给我们发一个SessionID,浏览器会自己保存下来，当我们再次访问的时候，httpd请求首部会包含你的SessionID，服务器收到请求报文后会查看该SessionID,如果服务器上有该sessionID并在有效期内，则验证通过，刚才的访问状态还会存在，如果登录信息，比如购物车中的商品。

但是负载均衡以后，客户端请求可能被调度到不同的RealServer，而其他的RealServer中并没有该客户端的Session认证文件，这样就又无法追踪客户状态了，所以LVS引入了持久连接，凡是来自同一个IP的客户端都会被调度同一个RealServer,当然这个持久连接是有有效期的。持久连接有三种：

PCC Persistent client connections 将IP的所有请求都转发到一个RS

PPC persistent port connections  将IP中的一个服务转发到一个RS

PFWM persistent netfilter markedpacket persistence 将几个服务合并为一种服务转发

打个比喻吧，PCC就是所有来自一个IP的请求（不管是http还是ssh）都转发到一个RS，而PPC则是把指定的服务如Http转发到一个RS上，PFWM需要与iptables配合，mangle为定义的服务报文打上防火墙标记，凡是有该防火墙标记服务的请求的LVS都会根据他们的来源IP把他们调度到同一个RS上。

[222227682.jpg]: /images/20220714/9495230a55c645a59961f6c406663761.png
[222250114.jpg]: /images/20220714/0c03a79725d746b4b26067d5b8ec79b2.png
[222307955.jpg]: /images/20220714/bb5ff0c5605a4cfea9844701a3e0d7e2.png
[222336963.jpg]: /images/20220714/ab2455791ac54bb495b9300bfae0f5ee.png