乾坤大挪移之负载均衡LVS

Posted 2020-09-01

乾坤大挪移：乃在颠倒一刚一柔、一阴一阳的乾坤二气，乾坤心法”汇集藏密与西域绝世秘传心法之精华，其功效震古烁今，至高无上。勤修之则催动任何武林上乘功法如探囊取物耳。其式寥寥数言，但气效极巨，正所谓“大道至简”也。 这“乾坤大挪移”心法，实则是运劲用力的一项极巧妙法门，（第一层）龙象成就，（第二层）十诀剑气，（第三层）逍遥乾坤，（第四层）吸劲神魔，（第五层）横空挪移，（第六层）乾坤归一，（第七层）无极心法，伪道养形，真道养神，通此道者，能存能亡，神能飞行，并能移山，形为灰土，其何识焉。若欲安神，必练元气，气在身内，神安气海，气海充盈，心安神定，静至定俱，身存年永，神灵变化，出没自在，峭壁千里，去住无碍。天地以地生人，故一日一时，未尝能离乎气，神气若存，神气若散，身乃谢焉，若欲存身，气为神母，神为气子，神气若具，天无其右……

       没错，上面说的就是倚天屠龙记中的一门武林绝学之乾坤大挪移，那乾坤大挪移跟负载均衡有毛关系呢，看过小时或者电视剧的都多少知道点张无忌的这项武功，乾坤大挪移的很大一个特点在于将那些排山倒海之外力挪移开甚至再借助这些外力打击对手，也就是借力打力，而今天要说的这个负载均衡集群同样有过之而无不及之功效。

       我想每一个运维人都理解这样一个道理，无论一台服务器的硬件配置再高，软件性能再好，面对源源不断的用户涌入，也无法抵挡的住这排山倒海的用户请求，更何况哪怕是服务器操作系统都无法突破65535这个连接数限制，如何Hold的住源源不断的用户访问是一个非常重要的问题，而今天说的大名鼎鼎的LVS就是解决这个问题的关键所在，LVS：LinuxVirtual Server，项目发起人章文嵩，这也是国人为开源领域所做的重要贡献之一，本文将重点从LVS的心法着手来深入分析LVS的实现原理和实现方式。

       LVS是什么呢？首先LVS是一种实现服务器负载均衡集群的技术，工作在TCP（传输层），可把许多低性能的服务器组合在一起形成一个超级服务器，且有多种负载均衡的方法，即使在集群的服务器中某台服务器无法正常工作，也不影响整体效果，可扩展性非常好，也正是由于这些原因，LVS可以为Web服务、Cache服务、DNS服务、FTP服务提供高可伸缩的、高可用的网络服务，那LVS是如何实现负责集群的功能呢？LVS根据目标地址和端口是否需要转发进行判断，再根据提前定义好的调度方法做出转发至后端哪一台RealServer的决策，这就是LVS的工作原理，所谓大道至简，有时候看上去很复杂的东西，其实要实现的功能确异常简单，LVS就是要实现一个这样一个功能，前端Director（调度器）只负责将用户请求根据调度算法调度到后端真实的Realserver上，从而实现无论涌入多少的用户，只需在后端添加Realserver服务器，都能够这些用户调度到后端不同的Realserver服务器上，从而实现负责均衡的效果以及灵活可扩展功能，但是如何来实现这样一个功能呢，我会从LVS的组成部分、常用术语约定、以及LVS的类型和调度算法来一一说明。

       组成部分：

       1、IPVS：工作于netfilter的INPUT链上

       2、IPVSADM：用于在ipvs上定义集群服务同时定义该集群服务对应有哪些后端Realserver，再根据所指定的调度算法做调度决策。

       注：熟悉linux的同学想必都听说过iptables（防火墙）的大名，iptables实际是通过netfilter中5个钩子函数（PROROUTING、INPUT、OUTPUT、FORWARD、POSTROUTING）来决定报文的走向，而IPVS就是工作于netfilter的INPUT链上。

 

       常用术语：

 

       lvs中的常用术语约定：

       Server:

          Director：调度器

              Real Server: RS，后端提供服务的主机

       IP：

              Client: CIP（客户端user IP）

              Director Virtual IP: VIP（调度器虚拟IP）

              DirectoryIP: DIP（调度器IP）

              Real IP: RIP（后端服务器IP）

lvs的类型：

1、LVS-net：类似于DNAT, 但支持多目标转发；

它通过修改请求报文的目标地址为根据调度算法所挑选出的某RS的RIP来进行转发；

架构特性：

(1) RS应该使用私有地址，即RIP应该为私有地址；各RS的网关必须指向DIP；

(2) 请求和响应报文都经由Director转发；高负载场景中，Director易于成为系统瓶颈；

(3) 支持端口映射；

(4) RS可以使用任意类型的OS;

(5) RS的RIP必须与Director的DIP在同一网络；

拓扑结构如下：

                

2、LVS-dr：直接路由，Director在实现转发时不修改请求的IP首部，而是通过直接封装MAC首部完成转发；目标MAC是Director根据调度方法挑选出某RS的MAC地址；拓扑结构有别有NAT类型；

dr模型中，第一个要解决的问题就是各RS在配置了VIP的场景下能够把VIP作为源地址响应给客户端，且保证又不会扰乱前端路由将请求报文发给director，如果不能保证，那调度就没有任何意义；第二个要解决的问题就是director如何将请求报文的CIP和VIP转发至后端真正的Realserver，director不修改请求报文的CIP和VIP只是将该报文外面封装一个MAC帧，这个帧的源MAC地址是DIP所对应的MAC地址，目标MAC则是选定的某个Realserver的RIP所在接口的MAC地址。

架构特性：

(1) 保证前端路由器将目标地址为VIP的请求报文通过ARP地址解析后送往Director

解决方案：

静态绑定：在前端路由直接将VIP对应的目标MAC静态配置为Director的MAC地址；

arptables：在各RS上，通过arptables规则拒绝其响应对VIP的ARP广播请求；

内核参数：在RS上修改内核参数，并结合地址的配置方式实现拒绝响应对VIP的ARP广播请求；

(2) RS的RIP可以使用私有地址；但也可以使用公网地址，此时可通过互联网上的主机直接对此RS发起管理操作；

(3) 请求报文必须经由Director调度，但响应报文必须不能经由Director;

(4) 各RIP必须与DIP在同一个物理网络中；

(5) 不支持端口映射；

(6) RS可以使用大多数的OS；

(7) RS的网关一定不能指向Director；

拓扑结构如下图：

 

3、lvs-tun:不修改请求报文IP首部，而是通过IP隧道机制在原有的IP报文之外再封装IP首部，经由互联网把请求报文交给选定的RS；

                    

架构特性：

(1) RIP, DIP, VIP都是公网地址；

(2) RS的网关不能，也不可能指向DIP;

(3) 请求报文由Director分发，但响应报文直接由RS响应给Client；

(4) 不支持端口映射；

(5) RS的OS必须得支持IP隧道;

4、lvs-fullnat：通过请求报文的源地址为DIP，目标为RIP来实现转发；对于响应报文而言，修改源地址为VIP，目标地址为CIP来实现转发；

架构特性：

(1) RIP,DIP可以使用私有地址；

(2) RIP和DIP可以不在同一个网络中，且RIP的网关未必需要指向DIP；

(3) 支持端口映射；

(4) RS的OS可以使用任意类型；

(5) 请求报文经由Director，响应报文经由Director；

调度算法：

静态方法：仅根据算法本身实现调度；静态算法关注的是起点公平。

RR: round-robin, 轮询；轮叫、轮调、轮流；

WRR：weightedround-robin, 加权轮询；

SH：Sourceip Hashing，源地址哈希；把来自同一个地址请求，统统定向至此前选定的RS;

DH：Destinationip Hashing, 目标地址哈希；把访问同一个目标地址的请求，统统定向至此前选定的某RS；

 

动态方法：根据算法及后端RS当前的负载状况实现调度；动态方法关注的是结果公平。

LC: least connection

       Overhead=Active*256+Inactive

WLC: weighted least connection

       Overhead=(Active*256+Inactive)/weight

SED：ShortedExpection Delay

       Overhead=(Active+1)*256/weight

NQ：NeverQueue，永不排队

LBLC：Local-BasedLeast Connection，动态方式的DH算法；

LBLCR：Replicated LBLC

 

以上就是LVS负载均衡集群的实现原理、LVS类型、实现方式、调度算法的内容，理解了这些对于搭建LVS集群还远远不够，这些更像是一门武功的心法，然而任何一种武功光有心法是不够的，还要有具体的招式，比如要实现LVS集群，具体都有哪些招式，细心的同学不难发现调度器Director将会成为整个系统的单点，一旦出现故障，将会影响所有的服务，还有TCP协议是一种无状态的协议，要想追踪客户端的状态，必须解决Session保持的问题，预知后事如何，且听下回分解。