LVS即Linux虚拟服务器

LVS实现了基于IP的数据请求负载均衡调度方案,它实现了四层交换,终端互联网用户从外部访问公司的外部负载均衡服务器,终端用户的Web请求会发送给LVS调度器,LVS根据自身的调度算法将客户端请求发送给后端主机集群中的某一台主机,LVS工作模式分为NAT模式、TUN模式、DR模式以及FULLNAT模式。


 lvs的实现原理及协议支持:

         ipvsadm/ipvs

                ipvsadmin:用户空间的命令行工具,用于管理集群服务;

                ipvs:工作内核中的netfilter INPUT钩子上;

                支持TCP,UDP,AH,EST,AH_EST,SCTP等诸多协议;

         lvs arch:

                 调度器(负载均衡器):director,dispatcher,balencer

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

    

                   防火墙数据流向:

                    PREROUTING -->INPUT

                    PREROUTING -->FORWARD-->POSTROUTING

                    OUTPUT-->POSTROUTING

LVS四种类型:

       lvs-nat:基于NAT的负载均衡模式

       lvs-dr(direct routing):基于DR的负载均衡模式

       lvs-tun(ip tunneling):基于TUN的负载均衡模式

       lvs-fullnat:基于FULLNAT的负载均衡模式

  

lvs有主备模式吗 lvs的几种模式_IP

          

根据这张图我们来详细介绍一下LVS的四种工作模式   

基本名词解释:


Client IP:CIP

            Director Virutal IP:VIP

            Director IP:DIP

            Real Server IP:RIP

             

1.LVS-NAT

          多目标的DNAT(iptables)转换;它通过修改请求报文的目标IP地址(同时可能会修改目标端口)挑选出某Real Server的RIP地址实现转发; 在LVS负载均衡调度器上请求先发送给PREROUTING-->INPUT,然后经由监听在INPUT上的LVS程序强制将请求转发给POSTROUTING

          数据报文流向:

          客户端请求报文发送给Director此时源IP为CIP,目标IP为VIP,然后经过nat转换源IP不变仍然为CIP目标IP变为RIP,之后Real Server返回的报文源IP为RIP目标IP为CIP,然后经过Director源IP变为VIP目标IP变成CIP

注意事项:

        (1)RS和DIP应该使用私网地址,且RD的网关要指向DIP;

        (2)请求和响应报文都要经由director转发;极高负载的场景中,director可能会成为系统瓶颈;

        (3)支持端口映射;

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

          (5)  RS的RIP和Director的DIP必须在同一IP网络;

                    

2. LVS-DR:  

        当数据到达LVS负载均衡调度器时,不更改目标IP地址(VIP地址),而是更改目标mac地址,将目标mac换成挑选出的real server的mac地址,(mac是由direct通过ARP广播获取),然后将报文返还给交换机,减缓及根据目标mac地址将报文发送给挑选出的Real Server。Real Server接受到报文后拆封装,此时源IP为CIP目标IP为VIP,但是因为Real Server自身配置了两个IP地址。一个RIP,一个VIP所以可以正常接受报文, 其中调度器通过DIP网卡发出的对RIP地址请求取得各Real Server的mac地址

问题:real server的RIP要跟调度器的DIP在同一网段,地址的网关要如何配置?此时数据报文在返回响应时由于Linux主机特性报文经由那个网卡发出源地址就是哪个网卡上配置的地址?那响应报文的源地址就不能是VIP这一特性了。

        将VIP配置在Real Server的本地回环地址上面,当数据报文发送到Real Server后,先到达RIP地址,然后解封装,发现是回环地址,后发给回环地址上配置VIP地址,然后发给程序进程,程序进程在处理完任务后原本是要讲响应报文发送给Real Server的RIP地址,但是现在强制将报文发送给回环地址上的VIP,然后由回环地址发送给DIP,此时就相当于数据响应报文从回环地址的VIP地址

注意事项:        

        (1)保证前端路由器将目标IP为VIP的请求报文发送给调度器;

             解决方案:

                    静态绑定,在ARP地址表中将VIP地址跟director网卡的mac绑定

                    修改RS(real server)主机内核的参数

      (2)RS的RIP可以使用私有地址:但也可以使用公网地址;

      (3)RS跟Director必须在同一物理网络中;

      (4)请求报文经由调度器调度,但响应报文一定不能经由调度器;

        (5)  不支持端口映射;

      (6)RS可以是大多数OS;

         (7) RS网关不能指向DIP;

3.LVS-TUN:

        不修改请求报文的ip首部,而是通过在原有的ip首部(cip<-->vip)外,在封装一个ip首部(dip<-->rip);请求报文发送给调度器此时源IP为CIP,目标IP为VIP,然后调度器将此报文在封装一层,源IP为DIP,目标IP为RIP,经请求报文发送给Real Server,然后拆封装,之后发现目标IP为VIP,所以Real Server要配置两个地址,同样的要将VIP配置在回环地址上面。

  注意事项:          

        (1)  RIP,DIP,VIP全得是公网地址;

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

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

      (4)不支持端口映射

      (5)RS的OS必须支持隧道功能;

    

4. LVS-FULLNAT:

     调度器通过同时修改请求报文的目标地址和源地址进行转发;

     数据报文流向:

请求报文发送给Director此时源IP为CIP,目标IP为VIP,然后经过nat转换源IP变为DIP目标IP变为RIP,之后real server返回的请求源ip为RIP目标IP为DIP经过Director源ip变为VIP目标ip变成CIP

注意事项:

      (1)VIP是公网地址;RIP和DIP是私网地址,二者无须在同一网络中;

      (2)RS接收到请求报文的源地址为DIP,因此要响应给DIP;

      (3)请求报文和响应报文都必须经由Director;

      (4)支持端口映射机制;

      (5)RS可以使用任意OS;

 

session信息的保存:

 http是无状态协议,而同一账户在访问相同的服务器的资源时要想获取以前保留的资源,必须要建立并保存session(服务器端保存的客户端会话状态)信息。

         session保持的几种方法:

               session绑定:来自于同一个用户的请求始终定向至同一个Real Server

                      source ip hash会话表经发送请求的源IP跟Real Server对应保存起来

                      cookie hash客户端发送请求在进程级别插入cookie用以表示

                session集群:

                        集群中每一台主机都有拥有全集群中所有主机用的session信息

                session服务器:

                        将session信息用KV的方式存在缓存服务器中

    

LVS 负载均衡调度算法:

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

                    RR:round robin,轮调

                    WRR:weighted rr, 

                    SH:source hash,实现session保持的机制;将来自同一个IP的请求始终调度至同一RS;

                    DH:destination hash,将对同一个目标的请求始终发往同一个RS;

          动态方法:根据算法及各RS的当前负载状态进行调度;

                    Overhead:服务器权重

                    LC:Least Connection

                             Overhead=Active*256+Inactive;挑选出最小值的一台主机为挑选出的主机

                    WLC:Wrighted LC

                             Overhead=(Active*256+Inactive)/weight

                             SED:Shortest Expection Delay

                             Overhead=(Active+1)*256/weight

                    NQ:Never Queue

                              SED算法的改进;

                    LBLC:Locality-Based LC,即为动态的DH算法;

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

                    LBLCR:locality-Based Least-Connection withRelication,带复制功能的LBLC算法;



转载于:https://blog.51cto.com/11970509/2336656