LVS：三种模式的原理、调度算法、及应用介绍

LVS三种模式原理(nat/dr/tun)

LVS/NAT：

  如上图，客户通过virtual IP （虚拟服务的IP地址，公网地址），访问网络服务时，请求报文到达调度器，调度器根据连接调度算法从一组真实服务器中选出一台服务器，将报文的目标地址VIP，改写成选定服务器的地址（RIP），报文的目标端口改写成选定服务器的相应端口，最后将修改后的报文发送给选出的服务器。

  同时，调度器在连接Hash表中记录这个连接，当这个连接的下一个报文到达时，从连接Hash表中可以得到原选定服务器的地址和端口，进行同样的改写操作，并将报文传给原选定的服务器。当来自真实服务器(Real server)的响应报文经过调度器时，调度器将报文的源地址和源端口改为VIP和相应的端口，再把报文发给用户。

  我们在连接上引入一个状态机，不同的报文会使得连接处于不同的状态，不同的状态有不同的超时值。在TCP连接中，根据标准的TCP有限状态机进行状态迁移；在UDP中，我们只设置一个UDP状态。不同状态的超时值是可以设置的，在缺省情况下，SYN状态的超时为1分钟，ESTABLISHED状态的超时为15分钟，FIN状态的超时为1分钟；UDP状态的超时为5分钟。当连接终止或超时，调度器将这个连接从连接Hash表中删除。

   小结：

    1、对外界可视的只有director，后端的真实服务器（real server）是不可见的；

    2、所有响应报文从real server发出后，必须再经由director才能转发到客户端

    3、director与real server，必须在同一IP网络内，且应该是私网内，real server的网关必须指向director，有测试报告显示，当后端real server在10到20台之间的时候，director容易成为整个集群系统的瓶颈，因此对大型站点来讲该方法并非最佳的负载均衡方法

    4、支持端口映射，可修改请求报文的目标PORT；

    5、vs必须是Linux系统，rs可以是任意系统；

LVS/DR：

   如上图，（备调用器zuhi，）在VS/DR中，调度器根据各个服务器的负载情况，动态地选择一台服务器，不修改也不封装IP报文，而是将数据帧的MAC地址改为选出服务器的MAC地址，再将修改后的数据帧在与服务器组的局域网上发送。

  因为数据帧的MAC地址是选出的服务器，所以服务器肯定可以收到这个数据帧，从中可以获得该IP报文。当服务器发现报文的目标地址VIP是在本地的网络设备上（将VIP设置在回环地址上Lo），服务器处理这个报文，然后根据路由表将响应报文直接返回给客户。由于是real server直接将相应报文经由回环地址发给客户端的，所以客户端既不知道real server的存在，也可以将nat模式中director瓶颈隐患处理了，适用范围较广

  小结：

    1、确保前端路由器将目标IP为VIP的请求报文发往Director：

        (a) 在前端网关做静态绑定；

        (b) 在RS上使用arptables；

        (c) 在RS上修改内核参数以限制arp通告及应答级别；

            arp_announce

            arp_ignore

    2、RS的RIP可以使用私网地址，也可以是公网地址；RIP与DIP在同一IP网络；RIP的网关不能指向DIP，以确保响应报文不会经由Director；

    3、RS跟Director要在同一个物理网络；

    4、请求报文要经由Director，但响应不能经由Director，而是由RS直接发往Client；

    5、不支持端口映射；

   但是很多人都想，假如用real server直接将相应报文发给客户端，那么VIP与DIP和RIP需要在同一网段，这样的话就需要大量的公网地址IP了，大大增加了额外的开销，可否将VIP于DIP和RIP分别设置在两个网段中，VIP用公网地址，而DIP和RIP用私网地址？答案是可以的。

   假如将VIP与DIP和RIP设置在两个IP网络中，那么Real server就要将网关指向通往公网的IP，绝对不能指向director（指向director的话与lvs/net模式还有由什么区别？）

LVS/TUN(通过IP隧道实现虚拟服务器)

   IP隧道（IP tunneling）是将一个IP报文封装在另一个IP报文的技术，这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技术亦称为IP封装技术（IP encapsulation）。IP隧道主要用于移动主机和虚拟私有网络（Virtual Private Network），在其中隧道都是静态建立的，隧道一端有一个IP地址，另一端也有唯一的IP地址。

  如下图：

    它的连接调度和管理与VS/NAT中的一样，只是它的报文转发方法不同。调度器根据各个服务器的负载情况，动态地选择一台服务器，将请求报文封装在另一个IP报文中，再将封装后的IP报文转发给选出的服务器；服务器收到报文后，先将报文解封获得原来目标地址为VIP的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。

   在这里，请求报文的目标地址为VIP，响应报文的源地址也为VIP，所以响应报文不需要作任何修改，可以直接返回给客户，客户认为得到正常的服务，而不会知道是哪一台服务器处理的。

  小结：

    1、DIP, VIP, RIP都只能是公网地址；

    2、RS的网关不能，也不可能指向DIP；

    3、请求报文要经由Director，但响应不能经由Director，而是real server直接用VIP响应客户端；

    4、不支持端口映射；

    5、RS的OS得支持隧道功能；

三种方法的优缺点比较：

三种IP负载均衡技术的优缺点归纳在下表中：

         注：以上三种方法所能支持最大服务器数目的估计是假设调度器使用100M网卡，调度器的硬件配置与后端服务器的硬件配置相同，而且是对一般Web服务。使用更高的硬件配置（如千兆网卡和更快的处理器）作为调度器，调度器所能调度的服务器数量会相应增加。当应用不同时，服务器的数目也会相应地改变。所以，以上数据估计主要是为三种方法的伸缩性进行量化比较。

大多数Internet服务都有这样的特点：

  请求报文较短而响应报文往往包含大量的数据。如果能将请求和响应分开处理，即在负载调度器中只负责调度请求而响应直接返回给客户，将极大地提高整个集群系统的吞吐量。

  所以适当的将请求报文与响应报文发散处理，是一种很好的集群对外服务性能向往扩展的思路

==================================================分界线========================================================================

LVS之调度算法

根据其调度时是否考虑各RS当前的负载状态，可分为静态方法和动态方法两种：

  静态方法：仅根据算法本身进行调度；

     RR：roundrobin，轮询，将外部的请求报文轮流分配到集群服务中的每一台Real server中（每一台是只要定义在集群中的Real server，不论是否活动还是非活动，主要是因为lvs无法对后端服务器的健康状态做检查），主要强调的是公平调度

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

    如：RS1–>weight 1

        RS2–>weight 2

       那么我们可以理解为后端一共有三台RS，分别是RS1，和两台RS2

     SH：Source Hashing，实现session sticy，将报文的源IP地址当做key，做一张hash表；将来自于同一个IP地址的请求始终发往第一次挑中的RS，从而实现会话绑定；

    DH：Destination Hashing；请求的目标地址当做key，做一张hash表，将发往同一个目标地址的请求始终转发至第一次挑中的RS，常用于缓存服务器；

   动态方法：主要根据每RS当前的负载状态及调度算法进行调度；

      LC：least connections，调度器通过“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用“最小连接”调度算法可以较好地均衡负载。（其算法为：Overhead=activeconns*256+inactiveconns）

      WLC：Weighted LC，在集群系统中的服务器性能差异较大的情况下，调度器采用“加权最少链接”调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。(其算法为：Overhead=(activeconns*256+inactiveconns)/weight

若会话值一致 , 从上而下搜索第一台服务器作响应)

      SED：Shortest Expection Delay，基于wlc算法。这个必须举例来说了：
          ABC三台机器分别权重123 ，连接数也分别是123。那么如果使用WLC算法的话一个新请求进入时它可能会分给ABC中的任意一个。使用sed算法后会进行这样一个运算
        A(1+1)/1
        B(1+2)/2
        C(1+3)/3
        根据运算结果，把连接交给C 。

       NQ：Never Queue，无需队列。如果有台 realserver的连接数＝0就直接分配过去，不需要在进行sed运算

      LBLC：Locality-Based LC，“基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。

      该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用“最少链接” 的原则选出一个可用的服务器，将请求发送到该服务器。

      LBLCR：LBLC with Replication，“带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标 IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。

                  该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。

还有另外一种，但是不属于ipvs cluster算法：FWM，FireWall Mark

   这一种发放时利用iptables，在PREROUTING链上，将规划好的，哪种协议，发往哪个IP，哪个端口的报文，全都打上标记，当ipvs cluster收到报文的时候，查看到报文上有Firewall mask，将事先定义好的Firewall mask同类发往符合规则的后端集群Real server进行报文处理。   

   此种方法时借助于防火墙标记来分类报文，而后基于标记定义集群服务；可将多个不同的应用使用同一个集群服务进行调度。