LVS之理论详解

1.  为什么要使用集群

    1.  集群的特点

        1.  高性能

            请求少的时候,单台服务器性能要好,但是请求量大高并发的,集群架构要好。

        2.  价格有效性

        3.  可伸缩性

            当服务器负载,压力增长时,系统能被扩展来满足需求,且不降低服务质量。

        4.  高可用性

        5.  可管理性

        6.  可编程性

    2.  集群的分类

        1.  负载均衡集群LBC或者LB.

            分担访问量。

            高可用性。

            常用开源软件:LVS,Haproxy,Nginx

        

        2.  高可用性集群HAC或者HA.

            当一台机器宕机另外一台机器接管(IP资源和服务资源)

            常用开源软件:keepalived,heartbeat

        

        3.  高性能计算集群HPC.

        4.  网络计算

2.  常用的集群软硬件

     开源集群软件:lvs,keepalived,haproxy,nginx,heartbeat

     商业集群硬件:F5,Netscaler,Radware,A10

3.  企业运维中集群软硬件产品如何选型

     1.  当企业业务重要,技术力量又薄弱,并且希望出钱购买产品及更好的服务时,可以选择硬件负载均衡产品,此类公司多位传统的大型非互联网企业,如:银行,证券,金融等领域。对于门户网站,一般采取硬件软件结合。

     2.  中小型互联网企业,一般采用免费开源软件解决问题。

4.  负载均衡集群介绍

     1.  搭建负载均衡服务的需求

        1.  把单台计算机无法承受的大规模的并发访问或数据流量分担到多台节点设备上分别处理,减少用户等待响应的时间,提升用户体验。

        2.  单个重负载的运算分担到多台节点设备上做并行处理。

        3.  任意一个或多个节点设备宕机,不影响业务。

     2.  LVS介绍

        Linux Virtual Server全称,意为Linux虚拟服务器,是一个虚拟的服务器集群系统。章文嵩博士开发主导的项目。

        LVS是一种集群(Cluster)技术,采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率,将请求均衡地转移到不同的服务器上执行,且调度器自动屏蔽掉服务器

        的故障,从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的,而且无需修改客户端和服务器端的程序。

        http://www.linuxvirtualserver.org/zh/lvs1.html

     3.  IPVS发展史

        早在2.2内核,IPVS就以内核补丁的形式出现。

        从2.4.23版本开始,IPVS软件就是合并到Linux内核的常用版本的内核补丁的集合。

        从2.4.24版本以后,IPVS已经成为Linux官方内核的一部分。

     4.  IPVS软件工作层次图

        

        LVS负载均衡调度技术是在Linux内核中实现的。

     5.  LVS体系结构

        负载均衡器接受所有入站客户端请求,并根据调度算法决定哪个集群节点应该处理请求。

        

     6.  LVS集群的相关术语介绍

        VIP:向客户端计算机提供服务器的IP地址。

        RIP:集群下节点上的IP地址。

        DIP:用于连接内外网络的IP地址,物理网卡上的IP地址。

        CIP:客户端IP地址。

       7.  LVS工作过程

        客户请发送向负载均衡服务器发送请求。负载均衡器接受客户的请求,然后先是根据LVS的调度算法(8种)来决定要将这个请求发送给哪个节点服务器。然后依据自己的工作模式(3种)来看应该如何把这些客户的请求如何发送给节点服务器,节点服务器又应该如何来把响应数据包发回给客户端。    

5.  LVS集群的工作模式

      1.  VS/NAT  网络地址转换

         通过网络地址转换,调度器重写请求报文的目标地址,根据预设的调度算法,将请求分派给后端的真实服务器;真实服务器的响应报文通过调度器时,报文的源地址被重写,再返回给客户,完成整个负载调度过程。

          1.  NAT模式的流程示意图

              

          2.  NAT模式,调度过程IP包详细图

                           

客户发出请求,发送请求给链接调度器的VIP,调度器将请求报文中的目标Ip地址改为RIP。这样服务器RealServer将请求的内容发给调度器,调度器再将报文中的源IP地址改为VIP;
1) 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP;
2) PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链;
3) IPVS比对数据包请求的服务是否为集群服务,若是,修改数据包的目标IP地址为后端服务器IP,然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP,目标IP为RIP
4) POSTROUTING链通过选路,将数据包发送给Real Server;
5) Real Server比对发现目标为自己的IP,开始构建响应报文发回给Director Server。 此时报文的源IP为RIP,目标IP为CIP;
6) Director Server在响应客户端前,此时会将源IP地址修改为自己的VIP地址,然后响应给客户端。 此时报文的源IP为VIP,目标IP为CIP;

          3.  NAT模式优缺点

              1) NAT技术将请求的报文和响应的报文都需要通过LB进行地址改写,因此网站访问量比较大的时候LB负载均衡调度器有比较大的瓶颈,一般要求最多之能10-20台节点。

              2) 只需要在LB上配置一个公网IP地址就可以了。

              3) 每台内部的节点服务器的网关地址必须是调度器LB的内网地址。

              4) NAT模式支持对IP地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。                                

              5)在调度服务器上还需要开启路由转发。

      2.  VS/TUN

           采用NAT技术时,由于请求和响应报文都必须经过调度器地址重写,当客户请求越来越多时,调度器的处理能力将成为瓶颈。为了解决这个问题,调度器把请求报文通过IP隧道转发至真实服务器,而真实服务器将响应直接返回给客户,所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多,采用 VS/TUN技术后,集群系统的最大吞吐量可以提高10倍。

          1.  TUN模式过程详解

                  

1)客户请求数据包,目标地址VIP发送到LB上;
2)LB接收到客户请求包,进行IP Tunnel封装。即在原有的包头加上IP Tunnel的包头。然后发送出去;
3)RS节点机器根据IP Tunnel包头信息 (此时就又一种逻辑上的隐形隧道,只有LB和RS之间懂)收到请求包,然后解开IP Tunnel包头信息,得到客户的请求包并进行响应处理。
4)响应处理完毕之后,RS服务器使用自己的出公网的线路,将这个响应数据包发送给客户端。源IP地址还是VIP地址。(RS节点服务器需要在本地回环接口配置VIP);

          2.  模式图

                

 

 

1)  当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP 。
2)  PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链;
3)  IPVS比对数据包请求的服务是否为集群服务,若是,在请求报文的首部再次封装一层IP报文,封装源IP为为DIP,目标IP为RIP。然后发至POSTROUTING链。 此时源IP为DIP,目标IP为RIP;
4)  POSTROUTING链根据最新封装的IP报文,将数据包发至RS(因为在外层封装多了一层IP首部,所以可以理解为此时通过隧道传输)。 此时源IP为DIP,目标IP为RIP;
5)  RS接收到报文后发现是自己的IP地址,就将报文接收下来,拆除掉最外层的IP后,会发现里面还有一层IP首部,而且目标是自己的lo接口VIP,那么此时RS开始处理此请求,处理完成之后,通过lo接口送给eth0网卡,然后向外传递。 此时的源IP地址为VIP,目标IP为CIP;
6)  响应报文最终送达至客户端;

          3.  TUN模式优缺点

              1)  RIP、VIP、DIP全是公网地址
              2)  RS的网关不会也不可能指向DIP
              3)  不支持端口映射
              4)  RS的系统必须支持隧道  

      3.  VS/DR  

         VS/DR通过改写请求报文的MAC地址,将请求发送到真实服务器,而真实服务器将响应直接返回给客户。同VS/TUN技术一样,VS/DR技术可极大地提高集群系统的伸缩性。这种方法没有IP隧道的开销,对集群中的真实服务器也没有必须支持IP隧道协议的要求,但是要求调度器与真实服务器都有一块网卡连 在同一物理网段上。

          1.  DR模式过程

                       

VS/DR模式的工作流程图如上图所示,它的连接调度和管理与NAT和TUN中的一样,它的报文转发方法和前两种不同。DR模式将报文直接路由给目标真实服务器。
在DR模式中,调度器根据各个真实服务器的负载情况,连接数多少等,动态地选择一台服务器,不修改目标IP地址和目标端口,也不封装IP报文,而是将请求报文的数据帧的目标MAC地址改为真实服务器的MAC地址。
然后再将修改的数据帧在服务器组的局域网上发送。因为数据帧的MAC地址是真实服务器的MAC地址,并且又在同一个局域网。那么根据局域网的通讯原理,真实复位是一定能够收到由LB发出的数据包。
真实服务器接收到请求数据包的时候,解开IP包头查看到的目标IP是VIP。(此时只有自己的IP符合目标IP才会接收进来,所以我们需要在本地的回环借口上面配置VIP。 另外: 由于网络接口都会进行ARP广播响应,但集群的其他机器都有这个VIP的lo接口,都响应就会冲突。所以我们需要把真实服务器的lo接口的ARP响应关闭掉。)然后真实服务器做成请求响应,之后根据自己的路由信息将这个响应数据包发送回给客户,并且源IP地址还是VIP。

          2.  模式图  

              

 

 

1)  当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP;
2)  PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链;
3)  IPVS比对数据包请求的服务是否为集群服务,若是,将请求报文中的源MAC地址修改为DIP的MAC地址,将目标MAC地址修改RIP的MAC地址,然后将数据包发至POSTROUTING链。 此时的源IP和目的IP均未修改,仅修改了源MAC地址为DIP的MAC地址,目标MAC地址为RIP的MAC地址;
4)  由于DS和RS在同一个网络中,所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址,那么此时数据包将会发至Real Server;
5)  响应报文最终送达至客户端;

          3.  DR模式优缺点

              1)  在前端路由器做静态地址路由绑定,将对于VIP的地址仅路由到Director Server
              2)  arptables:在arp的层次上实现在ARP解析时做防火墙规则,过滤RS响应ARP请求。修改RS上内核参数(arp_ignore和arp_announce)将RS上的VIP配置在网卡接口的别名上,并限制其不能响应对VIP地址解析请求。
              3)  RS可以使用私有地址;但也可以使用公网地址,此时可以直接通过互联网连入RS以实现配置、监控等;
              4)  RS的网关一定不能指向DIP;
              5)  RS跟Dirctory要在同一物理网络内(不能由路由器分隔);
              6)  请求报文经过Directory,但响应报文一定不经过Director
              7)  不支持端口映射;
              8)  RS可以使用大多数的操作系统;

      4.  三种负载均衡方式比较

1)NAT模式-网络地址转换
VS/NAT 的优点是服务器可以运行任何支持TCP/IP的操作系统,它只需要一个IP地址配置在调度器上,服务器组可以用私有的IP地址。缺点是它的伸缩能力有限,当服务器结点数目升到20时,调度器本身有可能成为系统的新瓶颈,因为在VS/NAT中请求和响应报文都需要通过负载调度器。
如果负载调度器成为系统新的瓶颈,可以有三种方法解决这个问题:混合方法、VS/TUN和 VS/DR。在DNS混合集群系统中,有若干个VS/NAT负调度器,每个负载调度器带自己的服务器集群,同时这些负载调度器又通过RR-DNS组成简单的域名。但VS/TUN和VS/DR是提高系统吞吐量的更好方法。
对于那些将IP地址或者端口号在报文数据中传送的网络服务,需要编写相应的应用模块来转换报文数据中的IP地址或者端口号。这会带来实现的工作量,同时应用模块检查报文的开销会降低系统的吞吐率。 2)TUN模式-IP隧道模式 在TUN 的集群系统中,负载调度器只将请求调度到不同的后端服务器,后端服务器将应答的数据直接返回给用户。
这样负载调度器就可以处理大量的请求,它甚至可以调度百台以上的服务器(同等规模的服务器),而它不会成为系统的瓶颈。即使负载调度器只有100Mbps的全双工网卡,整个系统的最大吞吐量可超过 1Gbps。
所以,VS/TUN可以极大地增加负载调度器调度的服务器数量。VS/TUN调度器可以调度上百台服务器,而它本身不会成为系统的瓶颈,可以用来构建高性能的超级服务器。
VS/TUN技术对服务器有要求,即所有的服务器必须支持"IP Tunneling"或者"IP Encapsulation"协议。目前,VS/TUN的后端服务器主要运行Linux操作系统,我们没对其他操作系统进行测试。
因为"IP Tunneling"正成为各个操作系统的标准协议,所以VS/TUN应该会适用运行其他操作系统的后端服务器。 3)DR模式 跟VS/TUN方法一样,VS/DR调度器只处理客户到服务器端的连接,响应数据可以直接从独立的网络路由返回给客户。
这可以极大地提高LVS集群系统的伸缩性。跟VS/TUN相比,这种方法没有IP隧道的开销,但是要求负载调度器与实际服务器都有一块网卡连在同一物理网段上,服务器网络设备(或者设备别名)不作ARP响应,或者能将报文重定向(Redirect)到本地的Socket端口上。

          

      4.  FULLNAT模式-淘宝网最新开源的

       

    FULLNAT的重点是session管理。

6.  LVS的调度算法

    1.  固定调度算法:rr,wrr,dh,sh      

        rr(轮询)
          轮询调度:这种是最简单的调度算法,就是将请求A一个,B一个,A一个,B一个 ...... 循环的发。就算A主机挂掉了,调度器还是会将请求发送到A。十分均衡。

        wrr(权重, 即加权轮询)
          加权轮询调度:这种算法是在rr基础上实现的,只不过加了权重,权重范围为1-100,假设A的服务器性能好,就给A的权重设置的高一点,设为2,而B主机是1。这样就实现A二个,B一个,A二个,B一个 ...... 循环的发。这样照顾到了服务器性能。

        sh(源地址哈希)
          源地址散列:主要是实现将此前的session(会话)绑定。将此前客户的源地址作为散列键,从静态的散列表中找出对应的服务器,只要目标服务器是没有超负荷的就将请求发送过去。就是说某客户访问过A,现在这个客户又来了,所以客户请求会被发送到服务过他的A主机。

        dh(目的地址哈希)
          目的地址散列:以目的地址为关键字查找一个静态hash表来获得需要的RS。以目标地址为标准挑选。 功能是和sh近似的,但应用场景不同; 举个dh调度算法的例子:假设1号客户访问了web集群的一个动态页面,调度器将请求转发个A服务器,A服务器的PHP将这个动态请求运行了一遍,生成了缓存并回应1号客户。这下2号客户也访问了这个动态页面,调度器应该将请求发给A。毕竟A已经跑过这段程序了,有缓存,对吧。所以这既是dh算法)

    2.  动态调度算法:wlc,lc,lblc,lblcr,SED,NQ       

        lc(最少链接)
          最少连接调度:这种算法是看A,和B的主机谁的连接少,请求就发给谁。
          简单算法:active*256+inactive  (谁小发给谁)

        wlc(加权最少链接)LVS的理想算法
          加权最少链接:这种算法就是比lc多了一个加权。
          简单算法:( active*256+inactive )/weight    (谁小就发给谁)

        sed(最短期望延迟)
          基于wlc算法,假设A,B的权重分别是1,2 。而A的链接数为1,B的链接数为2 。这样的话,用wlc算法得出的结果一样,而明显B的权重大,B的能力较强。用sed算法的话,就可以避免wlc出现的问题。
          简单算法:(active+1)*256/weight (活动的连接数+1)*256/除以权重  谁小发给谁
            A:(1+1)/1
            B:(2+1)/2  (B小,交给B)

        nq(不用排队)
          基于sed算法:在sed的基础上,若谁的链接数为0,直接将请求发送给它!

        LBLC(基于局部性的最少连接)类似于dh,目标地址hash
          这个算法主要用于Cache集群系统,因为Cache集群的中客户请求报文的目标IP地址的变化,将相同的目标URL地址请求调度到同一台服务器,来提高服务器的访问的局部性和Cache命中率。从而调整整个集群的系统处理能力。但是,如果realserver的负载处于一半负载,就用最少链接算法,将请求发送给活动链接少的主机。

        LBLCR(带复制的基于局部性的最少链接)
          该算法首先是基于最少链接的,当一个新请求收到后,一定会将请求发给最少连接的那台主机的。但这样又破坏了cache命中率。但这个算法中,集群服务是cache共享的,假设A的PHP跑了一遍,得到缓存。但其他realserver可以去A那里拿缓存,这是种缓存复制机制。

    3.  LVS调度算法的生产环境选型

        1)  一般的网络服务,如http,nginx,mysql等常用的LVS调度算法为:
            a. 基本轮询调度rr
            b. 加权最小连接调度wlc
            c. 加权轮询调度wrc

        2)  基于局部性的最小连接lblc和带复制的给予局部性最小连接lblcr主要适用于web cache和DB cache;

        3)  源地址散列调度SH和目标地址散列调度DH可以结合使用在防火墙集群中,可以保证整个系统的出入口唯一;

7.  LVS特别注意事项

    1)  关于时间同步:各节点间的时间偏差不大于1s,建议使用统一的ntp服务器进行更新时间;
    2)  DR模型中的VIP的MAC广播问题:
        在DR模型中,由于每个节点均要配置VIP,因此存在VIP的MAC广播问题,在现在的linux内核中,都提供了相应kernel 参数对MAC广播进行管理,具体如下:
        arp_ignore: 定义接收到ARP请求时的响应级别;
          0:只要本地配置的有相应地址,就给予响应;
          1:仅在请求的目标地址配置在到达的接口上的时候,才给予响应;DR模型使用

        arp_announce:定义将自己地址向外通告时的通告级别;

          0:将本地任何接口上的任何地址向外通告;

          1:试图仅向目标网络通告与其网络匹配的地址;

          2:仅向与本地接口上地址匹配的网络进行通告;DR模型使用

    

           

      

   

 

posted @ 2018-03-18 19:27  奋斗史  阅读(201)  评论(0)    收藏  举报