Linux之虚拟服务器LVS搭建

导读	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.html

2、DS配置：

a) 开启ipv4转发

# vi /etc/sysctl.conf
net.ipv4.ip_forward = 1
　　b) 安装启动ipvsadm

# yum install ipvsadm -y
# service ipvsadm start

c) 增加规则

# 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 wrr

ab命令基本参数：

-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，无法模拟其它动态调度算法的效果，暂时记录到这里。