LVS集群应用配置详解

一. 目录

1. 关于集群的介绍.
   

2. 什么是负载均衡以及为什么需要负载均衡.

3. 负载均衡技术的特点.
   

4. 负载均衡集群的常见解决方案.
   

5. lvs介绍及管理工具.

6. 实现lvs集群服务的三种类型方法介绍.

7. LVS调度算法介绍.

8. ipvsadm管理工具的用法.
   

9. FWM.

10. LVS持久连接                
    

11. 实验部分(包括lvs-nat和lvs-dr类型的实现、基于lvs集群的http和https,及FWM的实现).

二. 正文

1. 关于集群的介绍

  当网站后端服务器承受不住访问的压力，提高服务器性能的解决方案会极大的增加成本时，于是就出现了横向扩展的解决方案。即增加一台或几台服务器，提供相同的服务，通过前端调度器将访问请求均匀的分配到后台服务器上。这种多台服务器组成的数组集合就叫做集群。

  集群按功能划分有三种模型： 

•  负载均衡集群（LB, loadBalance）

•  高可用性集群（HA, High Availability）

•  高性能集群（HP, High Performance）

  
  

2. 什么是负载均衡以及为什么需要负载均衡:

  由于网站中业务量的提高，访问量和数据流量的快速增长，其处理能力和计算强度也相应地增大，使得单一的服务器设备根本无法承担。负载均衡解决方案，让网站服务器轻松应对流量高峰，有效保证网站的稳定性。针对此情况而衍生出来的一种廉价有效透明的方法以扩展现有网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。这种技术就是负载均衡（Load Balance）。

3. 负载均衡技术的特点: 

• 大量的并发访问或数据流量分担到多台节点设备上分别处理，有效保证每个请求都能最快处理；

• 网络接入均衡，有效解决我国电信、网通“南北互通”问题；

• 多种负载均衡方式，有针对性的解决不同网站的压力分配问题；

• 科学的数据同步及内容分发系统；

• 完整的数据备份系统。

• ...

4. 负载均衡集群的常见解决方案:

• 硬件方面：

   1） F5: F5公司是应用交付网络（ADN）领域的全球领先厂商，全球市场份额第一。其致力于帮助全球大型的企业和服务提供商实现虚拟化、云计算和“随需应变”的IT的业务价值。F5公司总部设在华盛顿州的西雅图，并在全球各地设有分部。其产品性能好但价格昂贵。 

   2） A10: A10 公司是应用交付网络（ADN）领域的全球领先厂商，全球市场份额第三。其总部位于美国硅谷，连续多年被INC.500评为全球发展最快的企业之一。

   3） 深信服: 深信服应用交付AD产品具备服务器负载均衡、链路负载均衡、单边加速、智能优化技术、SSL加速、商业智能分析等优势功能，将用户访问请求智能匹配到最优的链路，并为用户选择响应最快的服务器，提升用户使用体验，并为企业提供科学管理的决策。

   4）Citrix NetScaler:中文名为负载均衡，指的是对于一个三层架构web应用来说，客户端的请求将通过NetScaler与后台服务器建立链接。思杰系统公司(Citrix System)是全球领先的以及最值得信赖的应用交付基础架构解决方案提供商。全球有超过21万5千家机构依靠思杰产品向身处任何地点的用户交付任何应用，其方案性能好、安全性高、成本低。

• 软件方面：

    lvs，haproxy，nginx，httpd，varnish，...  

5. lvs介绍及管理工具：

  (1) LVS全称为Linux Virtual Server，是由国内章文嵩教授牵头开发的开源项目，现在已经被收到linux2.6以上的内核版本中，不需要对系统打补丁就可以轻松实现。

  (2) LVS工作于IOS七层模型的第四层-传输层，通过对TCP, UDP, AH, EST, AH_EST, SCTP等工作在四层的协议的支持，根据目标地址和端口做出转发与否的决策，根据调度算法做出转发至哪一个端口的解决方案。

  (3) LVS将其控制程序ipvs嵌套至传输层数据流的Input钩子函数上，ipvs将发送至本调度器主机（director）上的数据流在input链上进行截流，通过对数据报文的分析根据自身的算法将数据流转发至后台真正提供服务的主机（Real Server）上，达到根据后端服务器负载能力均衡分配处理任务的效果。许多商业的集群产品，如RedHat的Piranha，Turbolinux公司的Turbo Cluster等都是基于LVS的核心代码实现的。

  (4) LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器(Director)具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。为此，在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。  

  (5) IPVS: 称之为IP虚拟服务器(IP Virtual Server，简写为IPVS),是运行在LVS下的提供负载均衡功能的一种技术。 当一个TCP连接的初始SYN报文到达时，IPVS就选择一台服务器，将报文转发给这台服务器。此后通过检查发报文的IP和TCP报文头地址，保证此连接的后继报文被转发到相同的服务器。这样，当IPVS无法检查到请求的内容而需要再选择服务器时，这就要求后端的服务器组提供相同的服务，不管请求被送到哪一台服务器，返回结果都应该是一样的。但是在有一些应用中后端的服务器可能功能不一，有的是提供HTML文档的Web服务器，有的是提供图片的Web服务器，有的是提供CGI的Web服务器。这时，就需要基于内容进行请求分发 (Content-Based Request Distribution)，同时基于内容请求分发可以提高后端服务器上访问的局部性。

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

  (7) 查看系统内核中的lvs支持的协议:

  (8) lvs中常用的的术语：  

    DIP（Director IP）: 调度器连接后台服务器的IP

    CIP（Client IP）: 客户端IP

    VIP（Director Virtual IP）: 调度器对外开放的IP

    RIP（Real Server IP）: 后台服务器IP

    RS（Real Server）: 后台提供服务的主机

    Director: 调度器或控制器

6. 实现lvs集群服务的四种类型方法介绍. 

  (1) lvs-nat

    多目标的DNAT(iptables),它通过修改请求报文的目标IP地址(同时可能会修改目标端口)至挑选出某RS的RIP地址实现转发;

 图示：

 注：

  1) LVS（Director）上面需要双网卡：DIP(内网)和VIP（外网）. 

  2) RS应该和DIP使用私网地址, 且RS的网关要指向DIP;RIP仅用于各个节点之间的通信 

  3) 请求和响应报文都要经由director转发, 极高负载的场景中, director可能会成为系统瓶颈;
  4) 支持端口映射;
  5) RS可以使用任意OS;
  6) RS的RIP和Director的DIP必须在同一IP网络; 
    

(2) lvs-dr

  通过修改请求报文的目标MAC地址进行转发。

  图示：

 注：

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

    解决方案:
      静态绑定.
      arp tables. 
      修改RS主机内核的参数. 

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

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

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

  5) Director仅仅负责处理入站请求，响应报文则由Real Server直接发往客户端;

  6) 不支持端口映射; 

  7) RS可以是大多数OS; 

  8) RS的网关不能指向DIP，而是指向外部路由;

  9) Director能够支持比NAT多很多的Real Server;

在DR模型中，由于每个节点均要配置VIP，因此存在VIP的MAC广播问题，在现在的linux内核中，都提供了相应kernel 参数对MAC广播进行管理，具体如下：

  两个内核参数：

    1) arp_ignore：定义接收到ARP请求时的响应级别;

       0：只要本地配置的有相应地址，就给予响应；   
       1：仅在请求的目标地址配置在到达的接口上的时候，才给予响应；DR模型使用

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

       0：将本地任何接口上的任何地址向外通告；   
       1：试图仅向目标网络通告与其网络匹配的地址；    
       2：仅向与本地接口上地址匹配的网络进行通告；DR模型使用

    两内核参数所在位置：/proc/sys/net/ipv4/conf/
 

(3) lvs-tun

  tun模型的数据转发原理和上面的dr模式是一样的，不过这个的应用场景主要是不同位置（不同机房）；LB是通过隧道进行了信息传输，虽然增加了负载，可是因为地理位置不同的优势，还是可以参考的一种方案；
  优点：负载均衡器只负责将请求包分发给物理服务器，而物理服务器将应答包直接发给用户。所以，负载均衡器能处理很大的请求量，这种方式，一台负载均衡能为超过100台的物理服务器提供服务，负载均衡器不再是系统的瓶颈。使用LVS-TUN方式，如果你的负载均衡器拥有100M的全双工网卡的话，就能使得整个Virtual Server能达到1G的吞吐量。
  不足：这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议；

 注：

  1） RIP,DIP,VIP都是公网地址;

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

  3） 请求报文由Director分发，但响应报文直接由RS响应给Client;

  4） 不支持端口映射；

  5） RS的OS必须得支持IP隧道，目前只有linux系统支持，windows，bsfdb等不支持；

(4) lvs-fullnat（双向转换）

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

 注：

  1） fullnat是对nat模型的改进，是一个扩展，使得RS与Director可以处于不同网络中。

  2） VIP是公网地址，RIP和DIP是私网地址，二者无需在同一网络中;

  3） RIP和DIP可以不再同一个网络中，且RIP的网关未必需要指向DIP；

  4） 支持端口映射；

  5） RS可以使用任意OS;

  6） 请求报文经由Director，响应报文也经由Director；

对DR/TUN/NAT模型的优缺点总结如下：

7. LVS调度算法介绍.

 四种静态算法，不考虑后端服务器实际负载情况：

 1) RR

  根据规则依次论调,不考虑RS的性能。轮到谁就转发给谁。

 2) WRR

  加权轮询，加入了weight（权重），可以根据RS的性能为其设置权重值，权重越大功能越强，但是无法发现当前的服务器的运行情况如何。

 3) DH

  目标地址hash，适用于前端是一个director后端是几个缓存服务器的情况，当客户端第一次访问到的是RS1的时候，DH这种算法能保证在客户端刷新后还是访问的RS1。

 4) SH

  源地址hash，用于保证响应的报文和请求的报文是同一个路径。

 六种动态算法，考虑后端服务器当前负载后再进行分配：

 1) LC

  least connection，当一个用户请求过来的时候，Director会计算一下哪台RS的连接数最小，那么这台RS就获得了下次响应客户端请求的机会，计算的方法Overhead=active*256+inactive,如果两者的结果是相同的则从LVS中的规则依次往下选择RS。这种算法也是不考虑服务器的性能的。

 2) WLC

  这个就是加了权重的LC，考虑了RS的性能，即性能好的就给的权重值大一些，性能差的给的权重值小一些。缺点就是如果Overhead相同，则会按规则表中的顺序，由上而下选择RS，Overhead=(active*256+inactive)/weight

 3) SED

  就是对WLC的情况的补充，Overhead=(active+1)*256/weight，加1，就是为了让其能够比较出大小。

 4) NQ

  即never queue，基本和SED相同，避免了SED当中的性能差的服务器长时间被空闲的弊端，它是将第一个请求给性能好的服务器，第二个请求一定是给空闲的服务器不论它的性能的好与坏。之后还是会把请求给性能好的服务器。

 5) LBLC

  它就是动态DH和LC的组合，适用于cache集群，对于从来没有来过的那些新的请求会分给当前连接数较少的那台服务器。

 6) LBLCR

  带有复制功能的LBLC，它的适用场景这里举例说明一下，比如说现在有RS1和RS2,第一次访问RS1的5个请求第二次又来了，理所应到Director将会将其交给RS1，而此时在RS2是非常闲的，所以此时最好的处理方法就是可以将后来的这5个请求分别交给RS1和RS2，所以此时就需要把客户端第一次请求的资源复制下来。（特殊情况）

8. ipvsadm管理工具的用法:
 管理集群服务:
  # ipvsadm -A|E -t|u|f service-address [-s scheduler] 
  # ipvsadm -D -t|u|f service-address
      service-address:
         tcp: -t ip:port 
         udp: -u ip:port 
         fwm: -f MARK
         -s scheduler:
            默认为wlc.
 管理集群服务中的RS:
  # ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight] [-x upper] [-y lower]
  # ipvsadm -d -t|u|f service-address -r server-address
      server-address:
           ip[:port] 
      lvs-type:
           -g: gateway, dr 
           -i: ipip, tun 
           -m: masquerade, nat 
 权重：
    -w NUM , -w表示权重，为0时就不会调度，数字越小，能力越小，性能越差;    
 清空和查看：
    # ipvsadm -C
    # ipvsadm -L|l [options]
             -n: numeric,基于数字格式显示地址和端口;
             -c: connection, 显示ipvs连接;
             --stats: 统计数据
             --rate: 速率
             --exact: 精确值
                
 保存和重载：
     # ipvsadm -R
     # ipvsadm -S [-n]              
 置零计数器：
     # ipvsadm -Z [-t|u|f service-address]

9. FWM

复习netfilter知识：

  netfilter:
    PREROUTING --> INPUT 
    PREROUTING --> FORWARD --> POSTROUTING 
    OUTPUT --> POSTROUTING  

FWM(FireWall MARK): 防火墙标记语言

为什么使用防火墙标记？

  将来自于同一个客户端的所有请求都定义到同一个RS上；如使用防火墙标记将443和80定义为同一个集群服务，这样就可以实现统一调度到后端的RS。

  比如在电商站点中，往购物车中添加商品之后需要付款,这个时候就需要访问director，发起的连接就不是http，而是https;但director会认为这是一个新的连接，很可能会被分配到其他RS服务器，这个时候购物车中就没有了商品。为了解决这种问题，就需要把用户的http请求和https请求，都调度到同一台服务器。

防火墙标记在什么时候打？

  当用户请求报文到防火墙（PREROUTING链）,防火墙就将特定报文（如：443和80），打上标记，假设标记为“10”；LVS调度的时候，就可以根据标记进行，只要请求带有标记10，就会将请求调度到同一个RS服务器。

定义方法：

(1)打标：在director上的mangle表的PREROUTING链上实现：

 语法：

  # iptables -t mangle -A PREROUTING -d $vip -p $protocol --dport $port -j MARK --set-mark n

  $vip: vip地址 
  $protocol: 协议 
  $port: 协议端口 

  n: [1-99]

(2)基于FWM定义集群服务: 

  # ipvsadm -A -f FWM -s SCHEDULER

  # ipvsadm -a -f FWM -rserver-address -g|-i|-m -w #

     PREROUTING:
            -j MARK --set-mark 10

     ipvs:
          -A -f 10

10. LVS持久连接

lvs persistence: lvs的持久连接;   

功能：无论ipvs使用何种调度方法，其都能实现将来自于同一个Client的请求始终定向至第一次调度时挑选出的RS;

和sh调度算法比较优点：  

 sh：会一直将一个用户请求定义到一个后端server，不会考虑后端服务器状态;对多个共享的同一组RS的服务器,需要统一进行绑定，sh算法无法实现;

 持久连接：第一次会根据设置的调度算法（rr，wlc……）调度到后端，在指定的会话存活时间使用持久连接，会话存活时间到期之后，还是根据调度算法进行调度。

persistence template(持久连接模板)：将多个集群服务归并到一起统一调度;

持久连接的实现方式：

   PPC：每端口持久；持久连接生效范围仅为单个集群服务；如果有多个集群服务，每服务被单独持久调度；

   PFWM：每FWM持久：持久连接生效范围为定义为同一个FWM下的所有服务；

   PCC：每客户端持久；持久连接生效范围为所有服务；定义集群服务时，其TCP或UDP协议的目标端口要使用0；

     director会将用户的任何请求都识别为集群服务,并向RS进行调度;
     TCP: 1-65535; UDP: 1-65535 

lvs persistence语法：

  ipvsadm-A -t|-u|-f service-address -s $schedular -p [n]

      无-p选项：不启用持久连接

      -p n：指定持久时长，省略时长，默认为360秒 

其他注意事项：

   关于时间同步：各节点间的时间偏差不大于1s，建议使用统一的ntp服务器进行更新时间；

   DR模型中的VIP的MAC广播问题：

11. 实验部分:   

实验一：部署lvs-nat集群

实验环境：

  实验软件:vmware workstation 

  系统：

     Director：CentOS7.3 

     Real Server(2台)：CentOS6.7

  网络拓扑图：

本文转自 羽丰1995 51CTO博客，原文链接:http://blog.51cto.com/13683137989/1888491