共计 5346 个字符，预计需要花费 14 分钟才能阅读完成。
| 导读 | LVS 是 Linux Virtual Server 的简称，也就是 Linux 虚拟服务器。这是一个由章文嵩博士发起的一个开源项目，它的官方网址是 http://www.linuxvirtualserver.org，现在 LVS 已经是 Linux 内核标准的一部分。使用 LVS 可以达到的技术目标是：通过 LVS 达到的负载均衡技术和 Linux 操作系统实现一个高性能高可用的 Linux 服务器集群，它具有良好的可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的性能。LVS 是一个实现负载均衡集群的开源软件项目，LVS 架构从逻辑上可分为调度层、Server 集群层和共享存储 |
1. DS：Director Server。指的是前端负载均衡器节点。2. RS：Real Server。后端真实的工作服务器。3. VIP：向外部直接面向用户请求，作为用户请求的目标的 IP 地址。4. DIP：Director Server IP，主要用于和内部主机通讯的 IP 地址。5. RIP：Real Server IP，后端服务器的 IP 地址。6. CIP：Client IP，访问客户端的 IP 地址。1. 直接路由模式（DR）
原理：负载均衡器和 RS 都使用同一个 IP 对外服务｡但只有 DR 对 ARP 请求进行响应，所有 RS 对本身这个 IP 的 ARP 请求保持静默。也就是说，网关会把对这个服务 IP 的请求全部定向给 DR，而 DR 收到数据包后根据调度算法，找出对应的 RS，把目的 MAC 地址改为 RS 的 MAC（因为 IP 一致）并将请求分发给这台 RS。这时 RS 收到这个数据包, 处理完成之后，由于 IP 一致，可以直接将数据返给客户，则等于直接从客户端收到这个数据包无异，处理后直接返回给客户端。由于负载均衡器要对二层包头进行改换, 所以负载均衡器和 RS 之间必须在一个广播域，也可以简单的理解为在同一台交换机上。
优点：负载均衡器只是分发请求，应答包通过单独的路由方法返回给客户端。
缺点：要求负载均衡器的网卡必须与物理网卡在一个物理段上。
2. NAT 模式（NAT）
原理：就是把客户端发来的数据包的 IP 头的目的地址，在负载均衡器上换成其中一台 RS 的 IP 地址，并发至此 RS 来处理，RS 处理完成后把数据交给经过负载均衡器，负载均衡器再把数据包的原 IP 地址改为自己的 IP，将目的地址改为客户端 IP 地址即可。期间，无论是进来的流量, 还是出去的流量，都必须经过负载均衡器。
优点：集群中的物理服务器可以使用任何支持 TCP/IP 操作系统。
缺点：扩展性差。当服务器节点（普通 PC 服务器）增长过多时，负载均衡器将成为整个系统的瓶颈，因为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时，大量的数据包都交汇在负载均衡器处，导致负载均衡器变慢以至于整个链路变慢。
3. IP 隧道模式（TUN）
原理：隧道模式就是，把客户端发来的数据包，封装一个新的 IP 头标记 (仅目的 IP) 发给 RS，RS 收到后，先把数据包的头解开，还原数据包，处理后直接返回给客户端，不需要再经过负载均衡器。注意，由于 RS 需要对负载均衡器发过来的数据包进行还原，所以说必须支持 IPTUNNEL 协议。因此，在 RS 的内核中，必须编译支持 IPTUNNEL 这个选项。
优点：负载均衡器只负责将请求包分发给后端节点服务器，而 RS 将应答包直接发给用户，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量，这种方式，一台负载均衡器能够为很多 RS 进行分发。而且跑在公网上就能进行不同地域的分发。
缺点：隧道模式的 RS 节点需要合法 IP，这种方式需要所有的服务器支持“IP Tunneling”(IP Encapsulation)协议，服务器可能只局限在部分 Linux 系统上。
1. LVS 负载均衡的调度算法一（静态）
轮循调度（rr, Round Robin）
调度器通过“轮循”调度算法将外部请求按顺序轮流分配到集群中的真实机器上，它均等的对待每一台服务器，而不管服务器实际的连接数和系统负载。
加权轮循（wrr, Weighted Round Robin）
调度器通过“加权轮循”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器能处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态的调整其权值。
目标地址散列（DH, Destination Hashing）
“目标地址散列”调度算法根据请求的目标 IP 地址，作为散列键（Hash Key）从静态分配的散列列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
源地址散列（SH, Source Hashing）
“源地址散列”调度算法根据请求的源 IP 地址，作为散列键（Hash Key）从静态分配的散列表找到对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
2. LVS 负载均衡的调度算法二（动态）
最少链接（LC, Least Connections）
调度器通过“最少链接”调度算法动态的将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用“最少连接”调度算法可以较好的均衡负载。
OL(Over Load)=active * 256 + deactive
加权最少链接（WLC, Weighted Least Connections）
在集群系统中的服务器性能差异较大的情况下，调度器采用“加权最少连接”调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态的调整其权值。
OL(Over Load)=(active * 256 + deactive) / weighted
最短的期望延迟（SED, Shortest Expected Delay Scheduling）
最少队列调度（NQ, Never Queue Scheduling）
无需排队。如果有台 Real Server 的连接数等于 0 就直接分配过去，不需要再进行 SED 运算。
基于局部性的最少链接（LBLC, Locality-Based Least Connections）
“基于局部性的最少连接”调度算法是针对目标 IP 地址的负载均衡，目前主要用于 Cache 集群系统。该算法根据请求的目标 IP 地址找出该目标 IP 最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用“最少连接”的原则选出一个可用的服务器，将请求发送到该服务器。
带复制的基于局部性最少链接（LBLCR, Locality-Based Least Connections with Repilcation）
“带复制的基于局部性最少连接”调度算法也是针对目标 IP 地址的负载均衡，目前主要用于 Cache 集群系统。它与 LBLC 算法的不同之处是它要维护从一个目标 IP 地址到一组服务器的映射，而 LBLC 算法维护从一个目标 IP 地址到一台服务器的映射。该算法根据请求的目标 IP 地址找出该目标 IP 地址对应的服务器组，按“最少连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发到该服务器；若服务器超载，则按“最少连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。
实验环境：CentOS6.5，关闭 iptables/selinux
Client: 172.16.1.100
Director Server:
eth0 - 192.168.1.100
eth1 - 172.16.1.101 (VIP)
RealServer01: 192.168.1.101
RealServer02: 192.168.1.102
1、RS 配置：
a. 两台 RS 的网卡配置中网关均配置为 DS 的 eth0 IP: 192.168.1.100
b. 因为没有做共享存储，只在各自的主页文件中加入不同信息以示区别：RealServer01 # echo "RealServer01" > /var/log/index.html
RealServer02 # echo "RealServer02" > /var/log/index.html2、DS 配置：
a) 开启 ipv4 转发
# vi /etc/sysctl.conf
net.ipv4.ip_forward = 1
b) 安装启动 ipvsadm
# yum install ipvsadm -y
# service ipvsadm startc) 增加规则
# ipvsadm -A -t 172.16.1.101:80 -s rr
# ipvsadm -a -t 172.16.1.101:80 -r 192.168.1.101 -m -w 1
# ipvsadm -a -t 172.16.1.101:80 -r 192.168.1.102 -m -w 2
d) 查看并保存[root@director ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 172.16.1.101:80 rr
-> 192.168.1.101:80 Masq 1 0 0
-> 192.168.1.102:80 Masq 2 0 0
[root@director ~]# service ipvsadm save
ipvsadm: Saving IPVS table to /etc/sysconfig/ipvsadm: [确定]e) 在 Client 测试的结果
rr 调度算法结果：
wrr 调度算法结果：
# ipvsadm -E -t 172.16.1.101:80 -s wrrab 命令基本参数：
-n 执行的请求数量
-c 并发请求个数
其它参数：-t 测试所进行的最大秒数
-p 包含了需要 POST 的数据的文件
-T POST 数据所使用的 Content-type 头信息
-k 启用 HTTP KeepAlive 功能，即在一个 HTTP 会话中执行多个请求，默认时，不启用 KeepAlive 功能测试案例：
# yum -y install httpd-tools
# ab -c 10 -n 10000 http://172.16.1.101/index.html
# 测试完成进度
Benchmarking 172.16.1.101 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: Apache/2.2.15
Server Hostname: 172.16.1.101
Server Port: 80
Document Path: /index.html # 请求的资源
Document Length: 14 bytes #返回的长度
Concurrency Level: 10 # 并发个数
Time taken for tests: 0.262 seconds # 总请求时间
Complete requests: 1000 # 总请求数
Failed requests: 0 # 失败的请求数
Write errors: 0
Total transferred: 280840 bytes
HTML transferred: 14042 bytes
Requests per second: 3816.98 [#/sec] (mean) # 平均每秒的请求数
Time per request: 2.620 [ms] (mean) # 平均每个请求消耗的时间
Time per request: 0.262 [ms] (mean, across all concurrent requests)
Transfer rate: 1046.84 [Kbytes/sec] received # 传输速率
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.4 1 3
Processing: 1 2 0.6 1 7
Waiting: 0 1 0.6 1 4
Total: 1 3 0.8 2 7
Percentage of the requests served within a certain time (ms)
50% 2 # 50% 的 requests 都在 2ms 内完成
66% 3
75% 3
80% 3
90% 4
95% 4
98% 4
99% 5
100% 7 (longest request)说明：由于缺乏实际 requests，无法模拟其它动态调度算法的效果，暂时记录到这里。
