Linux之虚拟服务器LVS搭建

导读	LVS是 Linux Virtual Server 的简称，也就是Linux虚拟服务器。这是一个由章文嵩博士发起的一个开源项目，它的官方网址是http://www.linuxvirtualserver.org，如今 LVS 已是 Linux 内核标准的一部分。使用 LVS 能够达到的技术目标是：经过 LVS 达到的负载均衡技术和 Linux 操做系统实现一个高性能高可用的 Linux 服务器集群，它具备良好的可靠性、可扩展性和可操做性。从而以低廉的成本实现最优的性能。LVS 是一个实现负载均衡集群的开源软件项目，LVS架构从逻辑上可分为调度层、Server集群层和共享存储

1、相关术语

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地址。

2、三种模式

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系统上。

3、相关调度算法

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地址对应的服务器组，按“最少链接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发到该服务器；若服务器超载，则按“最少链接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以下降复制的程度。

4、简单实验之LVS-NAT模式

实验环境：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

一、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

二、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

5、扩展 - 利用apache ab工具来模拟大量requests

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

原文来自：https://www.linuxprobe.com/linux-lvs-build.html