LVS全称Linux Virtual Server(Linux虚拟服务器)，它是章文嵩博士(前淘宝基础核心软件研发负责人，现任滴滴高级副总裁)主持的开源软件项目，LVS的发展过程其实对整个Linux的发展有很大的影响，x86架构的Linux之所以能取代Unix小型机，很大一部分原因就是Linux Cluster和x86PC组合起来就是所谓的既便宜又稳定，外加强大的代名词。而作为Linux Cluster核心组件之一的LVS(当然软件前端负载均衡器还有HAproxy，Nginx)，对Linux的发展的有着不可磨灭的作用。是企业架构从Unix高端机走向Linux Cluster＋x86PC的强有力的推动者

LVS里面有两个组件：

• ipvs

结合了Netfilter的代码，是input链上面一个能根据用户定义转发数据报文的一种应用。

• ipvsadm

编写调度规则的应用，相当于iptables，它书写的规则都会由ipvs实现

ipvs和ipvsadm，它们的关系相当于netfilter和iptables 的关系一样，一个负责书写命令，一个负责实现命令。

LVS工作在ISO网络模型中的第四层，报文的IP:port来决定是否转发，因为其工作在第四层，而且是在Netfilter的input链上，所以报文未进入用户空间之前就会被转发，所以其吞吐量极大，一般实力不弱的公司会选择前端使用LVS进行调度，LVS后面再跟7层调度器HAproxy或者Nginx再进行二次调度。

LVS的工作模式 先上架构图：

• VIP：Virtual IP 虚拟IP
• heartbeat:心跳(1，代表软件 2，代表一种机制)
• Director：负载均衡器
• Real server:后端响应服务器
• DIP：Director与Real Server通信端口
• RIP:Real Server的IP

主要组成部分：

• 负载调度器(load balancer):这个整个系统的最前端，也是集群的唯一入口，所有的服务请求都会由load balancer进行调度。

Load balancer是整个集群的重中之重，所以Load balancer必须不能出问题，那这需要就是冗余来实现了，也就是所谓的高可用，保证服务的高可用，前端Load balancer会由一主一备或者一主多备组成，它们之间由heartbeat连接，平时都是主的工作，向外展示的都是一台Director。当从的感觉不到主的心跳信息之后，就会自动转换成主的(把VIP和DIP抢过来)。当然真正的实现机制不是这么简单，这里只是初略的谈一下。

• 服务器池(server pool):真正响应服务的服务器池，load balancer调度完后，服务请求就会到达各个Real Server，由各Real Server进行响应

工作原理:

Director会根据请求报文的目标IP和目标端口来判断是否转发，现实这个功能的是ipvs，它运行在Netfilter的INPUT链上(至于为什么不运行在PROROUTEING链上面，我也不知)，根据算法将需要转发的请求发往不同Real Server。

工作模式：

LVS-NAT 通过NAT实现LVS

整个集群的所有请求都会先到达VIP，由Director根据指定的算法进行调度。报文从DIP转发给Real Server，Real Server就会进行处理，然后构建响应报文，返回给Client。报文经过Director，Director就会进行NAT转换，将源IP转换成VIP，这样一来。Client就会以为自己是在和VIP进行通信,上面的架构图就是典型的LVS-NAT

• 优点： Real Server可以是任何支持TCP/IP协议的OS
• 缺点： 请求和响应的数据报文都经过Director，一般Internet服务请求报文都很小，而响应报文都会比较大。这样一来集群稍微大一点，Director就会成为集群瓶颈。一般说来后端有10台－20台Real Server，Director就会调度不过来。

LVS-FULLNET

借助NAT实现跨网段LVS，请求到达Director，Director会将其转发给在公网上面的Real Server，然后Real Server会将响应报文返回给Director，由Director转发给Client，将上面架构图中Switch

• 优点

跨网段

• 缺点

Director和Real Server在不同网络，至少我是想不到应用场景

LVS-TUN 使用IP隧道实现LVS

既然LVS-NAT中响应报文由Director转发是个问题，LVS-TUN就解决了这个问题，请求报文由Director调度，响应报文不经过Director。Director通过IP隧道将请求报文封装并转发给Real Server，后端Real Server会自己转发出去

• 优点：

响应报文无需经过Director，开销大大降低，可用用来构建超高性能集群

• 缺点：

必须要OS支持IP Tunneling或者IP Encapsulation 对公网IP需求比较大，RIP、DIP、VIP都得是公网地址

LVS-DR 通过直接路由实现LVS

和LVS—TUN不同的是，LVS-DR不需要IP-Tunneling的支持和开销，Client向VIP发起服务请求，数据包到达VIP所在网段，因为Real Server中VIP不会响应ARP广播，所以Switch只会知道Director的MAC地址和VIP对应，所以报文就会发给Director，Director会通过算法算出这个请求包应该转发给哪个Real Server。当算出来之后，Director就会将目标MAC地址改成Real Server的MAC地址，然后交给交换机转发，交换机发给Real Server。由Real Server中的VIP接收，构建响应报文之后，也是由VIP作为源IP。直接发给网关。这一来Client就会接收到源地址为VIP的响应报文

• 优点：

支持大多数操作系统

拓展型极佳，几乎没有瓶颈，如果有，也基本上是出现在网络上面，很多超大型集群都是用LVS-DR作为总负载调度器，HAproxy和Nginx作为分业务负载调度器。

• 缺点：

物理设备要有一张网卡位于同一网络(其实也算不上缺点)

主要在使用的基本就是LVS－NAT和LVS－DR，具体点就是基本上都是LVS－DR模型

调度算法:Schequling Method

LVS的性能不仅仅由模式决定，还由算法决定，采用哪种算法将决定整个系统负载均衡的表现，不同的算法有不同的应用场景，根据自己的需求进行选择

静态算法:仅根据算法本身进行调度，不考虑Real Server的即时状态

rr：Round Robin 轮询

方法：每一次把来自用户的请求轮流分配给内部中的服务器
优缺点：服务器性能可能不同，有的Real Server可能已经支撑不住了，有的Real Server性能还很充裕

wrr：Weighted RR 权重轮询

方法：根据Real Server的性能不同，可以设置其权重，这样调度到不同的Real Server上面的请求比例基本就是其权重之比了
优缺点：解决了服务器性能不同的问题，性能好的话权重可以设置的时候设置高一点，虽说解决了服务器性能不同问题，但是不同的请求其请求的资源也不同，
可能有的机器上面都是一些文本请求，有的机器上面来了很多图片请求。这样一来还是不会平静，而且还有Session问题  

sh：source hashing   源地址hash

方法:在这种算法下每一次请求到达Director都会将ClientIP RealServerIP纪录下来，这样下次这个ClinetIP的请求到达了，
且对应的Real Server是可用且为超负荷的，那么就会将这个请求转发到对应Real Server，否则返回空
优缺点：主要用来实现实现session持久机制，还是没有考虑到Real Server本身负载

dh：destination hashing 目标地址hash

方法：和sh基本相同。只是把ClientIP和RealServerIP换了一下位置。
优缺点:用来实现前端有多个防火墙的时候。同一连接永远只经过同一防火墙，还是没有考虑到后端负载

动态算法：根据算法及RS当前的复制状态

lc：Least Connection 最少连接

计算当前的负载Overhead=Active\*256+Inactive来实现
Active：TCP活动连接
Inactive：TCP非活动连接                   

wlc：Weighted LC

Overhead=（Active\*256+Inactive）/weight
有的时候服务器性能差距很大，但是是刚开始运行，所以没有连接数，Active为0
这样一来其负载都为0，导致算法被临时改成轮询。

sed：Shortest Expect Delay  最短期望延迟(改进版的wlc)

Overhead=（Active+1）\*256/weight 
当Active＝0的时候也会是性能好的服务器多承担请求

aq：Nerver Queus： 永不排队 （改进的sed）

sed算出负载，然后按负载由小到大rr(轮询)，第一遍过完
sed算出负载。。。。
sed。。
。。。    

后端为chche的时候。

lblc：Locality-based least connection 基于本地的最少连接相当于dh+lc

针对目标IP的算法，请求到达的时候，根据ClinetIP将其调度到其最近使用的服务器上面。要是对应服务器超载，就会用“最少连接”算法再找出一台服务器  

lblcr： Replicated and Locality-based least connection 基于复制的基于本地的最少连接

与lblc不同的是，它要维护的是一个ClientIP到一组Real Server的映射。该算法根据ClientIP找出其最近使用的Real Server组，然后在Real Server组中使用"最少连接"挑选出一台服务器

ipvsadm

修改集群

-A:添加一个集群服务
    -t：tcp
    -u：udp
    -f： firewall make 通常应用于将两个或以上的服务绑定为一个服务进行处理时使用
    service-address
      -t IP:port
      -u ip:port
      -f firewall_mark
    -s 调度算法，默认为wlc
    -p: timeout persistent connection 持久连接
-E：修改定义过的集群服务
-D -t|u|f service-address：删除指定的集群服务

修改Real Server

    -a：向指定的CS中添加RS
        -t|-u|-f service-address：指明将RS添加至那个Cluster Service 中
        -r：指定RS，可以包含{IP[:port]},只有支持端口映射的LVS类型才允许此处使用跟集群服务中不同的端口
        lvs类型：
            -g：Gateway，DR
            -i：ipip,TUN
            -m:masquerade（地址伪装），NAT
            默认为DR
        指定RS权重
            -w
        上限下限：
         -x：下限
         -y：上限
    -e:修改指定的RS属性
    -d  -t|u|f  service-address  -r  server-address：在指定的集群服务中删除一个指定的RS情况所有的集群服务：
    -C

保存规则（使用输出重定向）：

    ipvsadm-save
    ipvaadm -S

载入指定的规则：（使用输入重定向）

     ipvsadmin-restore
     ipvasdm -R

查看ipvs规则等

    -L [options]
        -n 使用数字格式显示IP地址，不反解
        -c：查看连接数相关信息
        --stats：显示统计数据
        --rate：数据传输速率
        --timeout：显示tcp会话时长
        --daemon:守护进程的信息
        --sort：对虚拟服务进行排序，默认为升序
        --exact：精确显示，不做单位换算
-Z：计数器清零