3、lvs调度方法详解

3、lvs类型和调度方法详解    http://www.178linux.com/13570

集群：将多台主机组织起来满足某一特定需求；

集群类型：

LB：Load Balancing, 负载均衡集群；

负载均衡器，调度器；

上游服务器(upstream server)，后端服务器，"真"服务器(real server)；

SPOF：Single Point Of Failure

HA：High Avalilability, 高可用集群；

Active：活动服务器

Passive：备用服务器

支持基于TCP，UDP，SCTP，AH，EST，AH_EST等协议的众多服务； 

负载均衡集群中设计时的要点：

(1) session保持；

    session sticky绑定：缺点是如果绑定的real server宕机，则session就不存在了。

       (source ip hash)：ip级别将来自于同一个用户的请求不做负载均衡，始终调度到同一个real server上；

               如何追踪这个用户？自行维护一个会话追踪表，根据IP地址可以追踪每一个请求的客户端，任何一个客户端请求来，在一个会话追踪模板中有哪个IP被分给哪                 个real server的记录，并会给这个IP一个倒计时的计时器，在倒计时器倒计时完之前，如果同一个IP地址请求，都可以把这个IP地址发往同一个

               real server。这种机制就叫源地址哈希即source ip hash

       (cookie ip hash)：进程级别，不管IP是什么，任何一个会话来的时候就发一个cookie，是每次客户端请求时就利用cookie，

    session cluster集群 (multicast/broadcast/unicast)；每一个real server都会把自己的session同步给另一个主机一份

         session持久化：如果一组集群全部宕机或者断电，依然可以保证session可用，这需要session服务器

    session server服务器();把所有session都存在session服务器上

(2) 数据共享；

共享存储；

NAS：Network Attached Storage (文件级别)；

SAN：Storage Area Network (块级别)；

DS：Distributed Storage；

数据同步：

rsync

...

 

四层（lvs，内核空间）、七层（haproxy, nginx, 用户空间，占用套接字文件） 

Director/RealServer

Client Request --> Director (schdulder)--> RS#

 

LVS-TYPE:

lvs-nat: MASQUERADE     RIP与DIP必须在同一网段

    修改目标IP（可选：目标端口）实现转发；请求和响应报文都要经由director转发

lvs-dr：GATEWAY   director与RS必须在同一物理网络

    修改MAC地址实现转发；请求报文经由director；

lvs-tun：IPIP    不修改请求报文的ip首部，而是通过在原有的IP首部这外再次封装一个IP首部（源IP为DIP，目标IP为RIP）

    在原有的IP报文之外再次封装一个IP首部；请求报文经由director；

lvs-fullnat：

lvs scheduler：仅根据IP和端口进行调度

静态方法：仅根据算法本身进行调度，不考虑当前服务器实际负载情况；保证起点公平

RR：round robin, 轮调，轮询，轮叫：

    调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载｡

WRR：weighted rr, 加权轮询；

    调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服      务器的负载情况,并动态地调整其权值。

SH：source ip hash, 源地址哈希；将来自于同一个IP的请求始终调度至同一个RS。

    (因为IP-VS在本地会维护一个哈希表，这张表把每一个请求的源地址K被调度到哪一个real server V，都会记录下来。表中的每个K-V有可能还会有一个计时器，SH       实现session保持的机制，会损害负载均衡的效果,因为它会将来自同一个地址的请求将始终被调度至同一个real server)

    源地址散列"调度算法根据请求的源IP地址，作为散列键(HashKey)从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，      否则返回空｡

DH：desination ip hash, 目标地址哈希；对同一个目标的请求始终发往同一个RS

    根据请求的目标IP地址，作为散列键(HashKey)从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

    正向web代理，负载均衡内网用户对互联网的请求；

Client --> Director --> Web Cache Server(正向代理)

公司有两台公网出口(防火墙主机)，内网的所有客户端都需要通过这两个接口出去访问外网，为了避免一台防火墙主机挤满了IP而另一台却很少有IP通过。那么就就对两台防火墙主机做负载均衡，在内网客户端和防火墙主机之间加一台调度器。随之带来的问题是：因为防火墙有链接追踪的功能，因此一个客户端的请求假如经过负载均衡后，通过第一个防火墙分发出去，那么就期望这个内网的请求依然通过同一个防火墙把数据报文返回进来，不然就无法实现链接追踪的功能，那么如何保证一个请求通过某一个防火墙出去，又经过同一个防火墙进来？这就需要在防火墙主机与外网之间再加一台调度器了，从不同防火墙出来的请求都经过调度器统一分发到外网中去，那么外网的响应报文就需要经过调度器，调度器此时就做地址绑定，因此请求报文的路线：内网报文-->内网调度器-->防火墙主机-->外网调度器，返回报文的路线：外网报文-->外网调度器-->防火墙主机-->内网调度器-->内网主机，这个过程中，外网调度器就会与防火墙主机进行地址绑定，由哪个防火墙出来的求情，返回报文就从哪个防火墙进去。

同一个防火墙出去的请求依然通过同一个防火墙进来，这就可以实现会话追踪机制的实现，比如访问百度，那么内网的所有主机访问百度时

都通过同一个防火墙访问外网，也通过此防火墙主机返回报文。防火墙是代为内网主机请求

 

动态方法：根据算法及各RS当前的负载状态进行评估；保证结果公平

挑选后端real server是有挑选方式是有计算机制的，首先要把各real server的当前负载情况记录下来，

计算当前主机的负载方式：  Overhead=       

RS权重为0时，表示RS不可用  

把所有权重加起来，权重之和是整体权重基数，每个服务器的权重比上这个权重之和，得到的比例大概就是调度这个服务器与整个集群所接受的所有所有请求的比例。

LC：最少链接（Least Connections）
　  调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡      负载。

Overhead=Active*256+Inactive      活动连接数*256+非活动链接数

Active:每一个服务器当前主机活动链接的数量；

Inactive：非活动连接数量

256:相比较于非活动(Inactive)链接的数量，活动链接将会占据更多的资源，所以权重比较大

RS1: 10, 100

RS2: 20, 10

WLC: weighted LC   加权最少连接(默认采用的就是这种)（Weighted Least Connections）

在集群系统中的服务器性能差异较大的情况下，调度器采用"加权最少链接"调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载｡调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。

Overhead=(Active*256+Inactive)/weight

RS1: 10, 100, 1

RS2: 20, 10, 3

缺陷是：当前10个主机，都没有响应报文，假如能力最小的排最前面，来了一个请求，那么只能第一个主机响应，所以响应的最慢，而后面响应快的主机却在空闲。

SED：Shortest Expection Delay  最短延迟调度/最短期望延迟

在WLC基础上改进，Overhead=(ACTIVE+1)*256/weight，不再考虑非活动状态，把当前处于活动状态的数目+1来实现，数目最小的，接受下次请求，+1的目的是为了考虑加权的时候，非活动连接过多缺陷：当权限过大的时候，会导致空闲服务器一直处于无连接状态。

Overhead=(Active+1)*256/weight

刚开始每台主机的活动链接数都为0，利用SED调度算法后，这里先不乘以256，因为不考虑非活动链接，就没有必要考虑非活动连接数

第一台主机的Overhead=(0+1)/1=1

第二台主机的Overhead=(0+1)/2=1/2

第三台主机的Overhead=(0+1)/3=1/3

第四台主机的Overhead=(0+1)/4=1/4

第五台主机的Overhead=(0+1)/5=1/5

按照上述计算后，第五台链接数最少，权重最大，所以直接挑选第五台响应请求，这就最大限度利用了资源

缺点：总共两台服务器，第一台权重为1，第二台权重为4，那么前三个请求会全部分给第二台

RS1: 0, 1

RS2: 0, 9

NQ: Nerver Queue永不排队

SED算法的改进；（首先挑选一个主机分配一个请求，然后挑选下一个主机分配请求，直到把所有主机轮询一遍之后，再根据SED算法进行分配)  

无需队列。如果有台realserver的连接数＝0就直接分配过去，不需要再进行sed运算，保证不会有一个主机很空闲。在SED基础上无论+几，第二次一定给下一个，保证不会有一个主机很空闲，不考虑非活动连接，才用NQ，SED要考虑活动状态连接，对于DNS的UDP不需要考虑非活动连接，而httpd的处于保持状态的服务就需要考虑非活动连接给服务器的压力。

LBLC：Locality-Based LC 基于局部/本地的最少链接（locality-Based Least Connections）

即为动态的DH算法；用到场景:只有在实现正向代理，代理本地大量客户端访问互联网时，用到缓存时才有用

正向代理情形下的cache server调度

Client --> Director --> Web Cache Server(正向代理)

基于局部性/本地的"最少链接调度算法"是针对目标IP地址的负载均衡，目前主要用于Cache集群系统｡该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器;若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用"最少链接"的原则选出一个可用的服务器，将请求发送到该服务器｡

 

LBLCR：LBLC with Replication，带复制功能的LBLC；带复制的基于局部性最少连接（Locality-Based Least-Connections with Replication）

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

ipvs的集群服务：

四层交换（四层路由）

tcp, udp, sctp, ah, esp, ah_esp

(1) 一个ipvs主机可以同时定义多个cluster service（根据tcp或udp的端口进行定义的）；

(2) 一个ipvs集群服务至少应该一个RS；(定义时指明lvs-type,以及lvs scheduler调度方法)

ipvsadm的用法：(定义哪个协议的哪个端口是集群服务，在相应的集群服务中添加哪些RS,服务和RS都可以增删查改)

管理集群服务 (规则默认是保存在内核中的) 

  • ipvsadm -A|E -t|u|f service-address [-s scheduler] 对集群服务增加或修改的
  • ipvsadm -D -t|u|f service-address  删除操作
  • -A：添加
  • -E：修改
  • -D：删除
  • service-address：
  • tcp：-t ip:port
  • udp：-u ip:port
  • fwm：-f MARK 防火墙标记：报文经由netfilter经由防火墙后，给报文加一个标记
  • -s scheduler：默认为wlc；

管理集群服务中的RS 

  • ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight] [-x upper] [-y lower] 增(-a)和改(-e)操作
  • -a：添加一个RS
  • -e：修改一个RS
  • -d：删除一个RS
  • server-address：指RS的地址
  • ip[:port] 有些支持端口映射，如果有端口映射则要给出端口号
  • lvs-type:
  • -g：gateway,dr模型（默认）
  • -i: IPIP，tun模型
  • -m: masquerade,nat模型
  • ipvsadm -d -t|u|f service-address -r server-address 删除操作

查看和清理  (集群服务和RS都可以使用，且功能效果是一样的)

ipvsadm -C 清空服务和集群服务中的RS中的规则

ipvsadm -L|l [options]  查询操作

-n：numeric，数字格式显示地址和端口；

-c：connection，显示ipvs连接；

--stats：统计数据；

--rate：速率

--exact：显示精确值

 

保存和重载

  • ipvsadm -R  重载
  • ipvsadm  -R < /PATH/FROM/SOME_RULE_FILE
  • ipvsadm-restore < /PATH/FROM/SOME_RULE_FILE
  • ipvsadm -S [-n] 保存
  • ipvsadm -S  > /PATH/TO/SOME_RULE_FILE
  • ipvsadm-save  > /PATH/TO/SOME_RULE_FILE

置零计数器

ipvsadm -Z [-t|u|f service-address]

 

 

 

posted @ 2018-09-14 15:27  Study~Column  阅读(418)  评论(0)  编辑  收藏  举报