LVS的环境怎么搭建

LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统，目的在于使用集群技术和Linux操作系统实现一个高性能、高可用的服务器。它具有良好的可靠性，可拓展性和可操作性。从而以低廉的成本实现最优的性能。

一、相关术语

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

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

实验环境：CentOS6.5，关闭iptables/selinuxClient: 172.16.1.100Director Server:  eth0 - 192.168.1.100  eth2 - 172.16.1.101 (VIP)RealServer01: 192.168.1.101RealServer02: 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.confnet.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 -nIP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port           Forward Weight ActiveConn InActConnTCP  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 saveipvsadm: Saving IPVS table to /etc/sysconfig/ipvsadm:      [确定]

e) 在Client测试的结果 rr调度算法结果：

wrr调度算法结果：

# ipvsadm -E -t 172.16.1.101:80 -s wrr

五、扩展 – 利用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 

# 测试完成进度Benchmarking 172.16.1.101 (be patient)Completed 100 requestsCompleted 200 requestsCompleted 300 requestsCompleted 400 requestsCompleted 500 requestsCompleted 600 requestsCompleted 700 requestsCompleted 800 requestsCompleted 900 requestsCompleted 1000 requestsFinished 1000 requestsServer Software:        Apache/2.2.15Server Hostname:        172.16.1.101Server Port:            80Document 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:           0Total transferred:      280840 bytesHTML transferred:       14042 bytesRequests 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   maxConnect:        0    1   0.4      1       3Processing:     1    2   0.6      1       7Waiting:        0    1   0.6      1       4Total:          1    3   0.8      2       7Percentage 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%      5100%      7 (longest request)

说明：由于缺乏实际requests，无法模拟其它动态调度算法的效果，暂时记录到这里。