LVS集群-DR模式及AB压力测试软件的使用方法

一、 LVS-DR和LVS-IP TUN集群概述
1、 服务概述
1.1 Direct Routing（直接路由）
director分配请求到不同的real server。real server处理请求后直接回应给用户，这样director负载均衡器仅处理客户机与服务器的一半连接。负载均衡器仅处理一半的连接，避免了新的性能瓶颈，同样增加了系统的可伸缩性。Direct Routing由于采用物理层（修改MAC地址）技术，因此所有服务器都必须在一个网段中。

1.2 IP Tunneling（IP隧道）
director分配请求到不同的real server。real server处理请求后直接回应给用户，这样director负载均衡器仅处理客户机与服务器的一半连接。IP Tunneling技术极大地提高了director的调度处理能力，同时也极大地提高了系统能容纳的最大节点数，可以超过100个节点。real server可以在任何LAN或WAN上运行，这意味着允许地理上的分布，这在灾难恢复中有重要意义。服务器必须拥有正式的公网IP地址用于与客户机直接通信，并且所有服务器必须支持IP隧道协议。

1.3 Direct Routing 和 IP Tunneling区别
Direct Routing与IP Tunneling相比，没有IP封装的开销，但由于采用物理层（修改MAC地址）技术，所有服务器都必须在一个物理网段。

2、 DR模式实际拓扑图及工作DR方式工作流程图
Lvs-dr的工作原理：Deiector收到请求，将请求转发给了我们的realserver，但是接下来的工作就是我们的realserver和我们的客户端进行通讯了，所以原理图如下。

3、 LVS DR模式工作原理
MAC转换过程
实例场景设备清单：
director分发器,IP: 192.168.54.120,
VIP : 192.168.57.126

① client基本信息： IP：192.168.57.135向目标vip发出请求，Director接收。此时IP包头及数据帧头信息如下：

② Director分发器根据负载均衡算法选择一台active的realserver(假设是192.168.57.122)，将此RIP所在网卡的mac地址作为目标mac地址，发送到局域网里。此时IP包头及数据帧头信息如下：

③ realserver(192.168.57.122)在局域网中收到这个帧，拆开后发现目标IP(VIP)与本地匹配，于是处理这个报文。随后重新封装报文，发送到局域网。此时IP包头及数据帧头信息如下：

④ 如果client与VS同一网段，那么client(192.168.57.135)将收到这个回复报文。如果跨了网段，那么报文通过gateway/路由器经由Internet返回给用户。
归纳一下：
1）接收client的请求，根据你设定的负载均衡算法选取一台realserver的ip；
2）以选取的这个ip对应的mac地址作为目标mac，然后重新将IP包封装成帧转发给这台RS；
3）在hash table中记录连接信息。
数据包、数据帧的大致流向是这样的：client --> VS --> RS --> client
以上就是对LVS/DR模式的原理介绍

为什么需要DR？ 因为NAT模式效率太低。
DR方式特点？成本？都是公网地址

网络转发：
基于2层的数据报文的转发, 要比基于3层的网络转发效率要高

lvs-DR 是基于2层的转发, 所以在LVS中所有的模式, 效率是最好的
	
1) 基于mac的数据报文转发, 是效率最好的, 但是是根据交换机的MAC地址表来实现的
	MAC表主要告诉你, 到xxxx地方该走那个端口
	如果交换不知道对方在哪儿, 这个时候, 他就要进行广播, 就问xxxx在哪儿, 如果对应的设备给了回应, 那么交换机也就更新了自己的MAC地址表 记录到xxxx需要走这个端口		
2) 2层设备不具有路由功能, 那么广播也就不具有跨路由的功能, 所有要实现mac地址广播, 必须在同一物理网段
3) vlan具有隔离广播的功能, 所有要能处理mac地址广播, 就应该在同一个VLAN中
	
因此: 如果要实现LVS-DR模式
	1) 所有的设备应该在同一个物理网段
	2) 所有的设备都应该在同一个广播域中

LVS-DR模式工作原理：
1) DR模式, 全程目标地址, 原地址不变, 因为DR模式工作于2层
2) 请求报文从客户端发出:
原地址: CIP 源MAC CMAC 目标地址: VIP 目标mac: xxx
3) 请求报文到达机房防火墙之后, 会在防火墙的内网口进行广播, 找到VIP在哪儿 然后把包丢出去
原地址: CIP 目标地址: VIP
源MAC: FMAC 目标MAC: VMAC
4) 报文到达director之后, 解包, 发现目标mac是自己, 开始解析这个报文
处理完成, 通过自定义的一个调度算法, 转发报文到达其中一台RS上
原地址: CIP 目标地址: VIP
源mac: DMAC 目标MAC: RMAC
5) 数据报文到达RS之后, 进行节封装, 发现目标mac是自己, 开始解析, 发现VIP也有,开始处理
6) 处理完成之后, 数据直接通过RS流向客户端

总结：
（1） 整个LVS-DR集群，所有的服务器的IP地址都必须在一个网段内；
（2） DR工作模式，是给予MAC地址转发，MAC地址转发工作在OSI七层的数据链路层，也就是二层，而数据链路层是不能跨网段进行数据传输的；
（3） 如果分发器的VIP地址是公网地址，那么整个DR集群的IP地址都必须是公网地址；

二、 实战：配置LVS-DR集群
1、 网络拓扑图

2、 配置IP地址
DR集群的三台服务器，全部配置为桥接模式，通过真实机进行互联。
从拓扑图中，我们可以看出分发器xuegod110有两个地址，分别配置IP地址：

配置RS1地址：
ens33和回环接口地址：
[root@xuegod120 ~]# cd /etc/sysconfig/network-scripts/
[root@xuegod120 network-scripts]# cp ifcfg-lo ifcfg-lo:1
[root@xuegod120 network-scripts]# vim ifcfg-lo:1

配置RS2地址：
ens33和回环接口地址：
[root@xuegod130 ~]# cd /etc/sysconfig/network-scripts/
[root@xuegod130 network-scripts]# cp ifcfg-lo ifcfg-lo:1
[root@xuegod130 network-scripts]# vim ifcfg-lo:1

3、 关闭两台RS服务器的ARP转发
同一个广播域：配置了多个相同的VIP 是不允许的, 要想实现，就必须让外面的网络, 无法发现这个VIP的存在。
因此 在Linux里面, 可以修改内核参数, 实现接口IP的广播不响应、不广播
arp_ignore = 1 表示只回答目标IP是访问本地网络对应接口的arp请求
arp_announce = 2 只宣告本机网卡直连网络所在的ip的arp广播

临时生效：
[root@xuegod120 ~]# echo 1 > /proc/sys/net/ipv4/conf/ens33/arp_ignore
[root@xuegod130 ~]# echo 2 > /proc/sys/net/ipv4/conf/ens33/arp_announce

永久生效：（两台RS服务器同样配置）
[root@xuegod120 ~]# vim /etc/sysctl.conf #最后添加。
net.ipv4.conf.ens33.arp_ignore = 1
net.ipv4.conf.ens33.arp_announce = 2

或：
net.ipv4.conf.ens33.arp_ignore = 1
net.ipv4.conf.ens33.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2

[root@xuegod120 ~]# sysctl –p

130没有把配置贴出来，和120配置相同

参数说明：
arp_ignore 为：1 # - 只回答目标IP地址是访问本网络接口（ens33）的ARP查询请求。
自己的理解：
在设置参数的时候将arp_ignore 设置为1，意味着当别人的arp请求过来的时候，如果接收的网卡设备上面没有这个ip，就不做出响应，默认是0，只要这台机器上面任何一个网卡设备上面有这个ip，就响应arp请求，并发送mac地址。
arp_announce （宣告） 为2
2 - 对查询目标使用最适当的本地地址。例如，如果在ens33接口上接受到了一个VIP的arp请求包。内核判断这个VIP地址是不是ens33接口上的IP一样。如果一样，则回复这个包。如果不一样，就丢弃不回应。
注：三个LVS 模式中，只有NAT模式需要开启路由转发功能，DR和TUN模式不需要开启。

4、 在分发器上配置ipvsadm规则
[root@xuegod110 ~]# ipvsadm -A -t 192.168.1.100:80 -s rr
[root@xuegod110 ~]# ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.120 -g
[root@xuegod110 ~]# ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.130 –g
5、 保存配置
[root@xuegod110 ~]# ipvsadm --save > /etc/sysconfig/ipvsadm
[root@xuegod110 ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.100:80 rr
-> 192.168.1.120:80 Route 1 0 0
-> 192.168.1.130:80 Route 1 0 0

6、 分别在两台RS服务器中安装httpd
[root@xuegod120 ~]# yum -y install httpd
[root@xuegod120 ~]# systemctl start httpd
[root@xuegod130 ~]# yum -y install httpd
[root@xuegod130 ~]# systemctl start httpd

7、 分别写入不同的内容到httpd的网页
[root@xuegod120 ~]# echo 192.168.1.120 > /var/www/html/index.html
[root@xuegod130 ~]# echo 192.168.1.130 > /var/www/html/index.html

8、 在客户端上登录测试
先登录RS的地址测试：

使用VIP地址登录测试：

使用elinks客户端访问：

三、 LVS的多种调度算法
1、 算法概述
[root@xuegod110 ~]# ipvsadm –h
-s rr 轮循法
-s wrr 带权重的循环法
-s lc 最少连接法
-s wlc 带权重的最少连接法
-s lblc 基于本地的最少连接法
-s dh 目标散列法
-s sh 源散列法
-s sed 最短预期延迟法
-s nq 永不排队法
注：调度算法配置后立即生效，就像iptables配置规则一样。

2、 算法明细说明
1）rr - round robin
— 在服务器池中无穷的循环中遍历

2）wrr - Weighted Round Robin
— 基于集群节点可以处理多少来分配给每个节点一个权重值。权重值为2的服务器将收到权重值为1的服务器的两倍的连接数量。如果服务器的权重为0 ，则不会收到新的连接请求(但当前活动的已经建立的连接将不会丢失)。

3）lc - Least-Connection
— 当新的请求到达director时，director查看活动和非活动的连接数量，以确定把请求分发给哪个服务器。
director将集群节点目前的活动连接数量x256 再加上不活动的连接数量，得到节点的开 销值。最低开销值的节点胜出，被分发给新的入站请求。（如果开销一样，则第一个节点被选中）

4）wlc - Weighted Least-Connection
— 先如上算出集群节点的开销值，然后除以分配给其的权重值，最小值节点胜出，将入站请求分发给它。

5）lblc - Locality-Based Least-Connection
— 基于局部的最小连接，当real server是缓存服务器时用得比较多
6）lblcr - Locality-Based Least-Connection with Replication
— 带复制的基于局部的最小连接，当real server是缓存服务器时用得比较多

7）dh - Destination Hashing

8）sh - Source Hashing
— 同一个ip的客户端总是分发给同一个real server。
让客户端总是能访问到自己的会话信息，这种机制叫会话保持。
基于ip地址标识客户端的缺点：很多内网用户会伪装成公网ip，来访问服务器，不能人为的控制负载均衡。

比较高级的方法是基于客户端提供我们的session id来实现会话保持。
haproxy(做负载均衡的软件)可以实现基于会话信息来判断保持会话。

扩展：
如何保持会话一致：
1)如果总是保持和一个RS会话，这台RS如果故障了，要确定另一个RS也有会话信息，所有的RS保持数据同步。
会话同步的方法:
2)所有的RS把自己的会话信息保存到数据库当中(memcached软件）。

9）sed - Shortest Expected Delay最短延时预测 (Ci+1)/Ui Ci连接数 Ui权重值
— 在wlc方法上做了轻微改进，这些服务使用tcp,而且当群节点在处理每个请求时保持
在活动状态。
计算方法： 每个休群节点的开销值是通过将活动的连接数加1计算的。然后开销值除以
分配 给每个节点的权重，以取得SED值，具有最低SED值的集群节点胜出。

10）nq - Never Queue没有队列，分配请求给空闲的服务器，没有空闲的就找响应最快的，
— 如果集群节点中没有活动的连接 ，不管每个集群节点SED计算值的结果，它始终被
分配置服务的新入站请求。

HTTP的会话(session)信息：
cookies客户端(client)自己保存缓存
会话(session)服务器(server)端保存

3、 实例
1） 测试LVS 其它调度算法，如LVS-DR wrr
[root@xuegod110 ~]# ipvsadm -C
[root@xuegod110 ~]# ipvsadm -A -t 192.168.1.100:80 -s wrr
[root@xuegod110 ~]# ipvsadm -a -t 192.168.1.100:80 -r192.168.1.120 -g -w 10
[root@xuegod110 ~]# ipvsadm -a -t 192.168.1.100:80 -r192.168.1.130 -g -w 20
[root@xuegod110 ~]# ipvsadm -L -n --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
TCP 192.168.1.100:80 0 0 0 0 0
-> 192.168.1.120:80 0 0 0 0 0
-> 192.168.1.130:80 0 0 0 0 0

测试：
在物理机上，刷新9次这个链接：http://192.168.1.63/
查看：
[root@xuegod110 ~]# ipvsadm -L -n --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
TCP 192.168.1.100:80 9 54 0 4203 0
-> 192.168.1.120:80 3 18 0 1401 0
-> 192.168.1.130:80 6 36 0 2802 0
#一共9次连接， xuegod120：xuegod130 是 1:2 关系。 说明权重越大，获得的连接说越多。

2） 如果一个real server 的权重是0，将不再分配给他客户端的请求
[root@xuegod110 ~]# ipvsadm -C
[root@xuegod110 ~]# ipvsadm -A -t 192.168.1.100:80 -s wrr
[root@xuegod110 ~]# ipvsadm -a -t 192.168.1.100:80 -r192.168.1.120 -g -w 0
[root@xuegod110 ~]# ipvsadm -a -t 192.168.1.100:80 -r192.168.1.130 -g -w 20
[root@xuegod110 ~]# ipvsadm -L -n --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
TCP 192.168.1.100:80 0 0 0 0 0
-> 192.168.1.120:80 0 0 0 0 0
-> 192.168.1.130:80 0 0 0 0 0

同样客户端访问9次测试
[root@xuegod110 ~]# ipvsadm -L -n --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
TCP 192.168.1.100:80 9 54 0 4203 0
-> 192.168.1.120:80 0 0 0 0 0
-> 192.168.1.130:80 9 54 0 4203 0
9次的访问都是在xuegod130上执行

扩展：
ipvsadm 更多参数说明
-L -n ==> 查看规则，显示内核虚拟服务器表
-L -n -c ==> 查看客户端连接分发器和real server 的情况
例1：
[root@xuegod110 ~]# ipvsadm -L -n -c
IPVS connection entries
pro expire state source virtual destination
TCP 01:33 TIME_WAIT 192.168.1.100:49698 192.168.1.70:80 192.168.1.62:80
TCP 01:26 TIME_WAIT 192.168.1.100:49690 192.168.1.70:80 192.168.1.64:80
TCP 01:57 TIME_WAIT 192.168.1.100:49739 192.168.1.70:80 192.168.1.62:80

-L -n --stats ==> 查看分发情况
-L -n --rate ==> 查看速率
-Z --zero 虚拟服务表计数器清零（清空当前的连接数量等）
例1：
[root@xuegod110 ~]# ipvsadm -Z
[root@xuegod110 ~]# ipvsadm -L -n --stats
IP Virtual Server version 1.2.1 (size=4096)

实例2：删除一条记录
[root@xuegod110 ~]# ipvsadm -d -t 192.168.1.63:80 -r 192.168.1.64
[root@xuegod110 ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.100:80 rr
-> 192.168.1.120:80 Masq 1 0 0

-C --clear 清除内核虚拟服务器表中的所有记录。

例3： 清空所有记录
[root@xuegod110 ~]# ipvsadm -C

其他查看方式：
–stats 显示统计信息
[root@xuegod110 ~]# ipvsadm -L -n --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
TCP 192.168.1.110:80 0 0 0 0 0
-> 192.168.1.120:80 0 0 0 0 0

–rate 显示速率信息
[root@xuegod110 ~]# ipvsadm -L -n --rate
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port CPS InPPS OutPPS InBPS OutBPS
-> RemoteAddress:Port
TCP 192.168.1.100:80 0 0 0 0 0
-> 192.168.1.120:80 0 0 0 0 0

-c --connection 显示LVS 目前的连接

[root@xuegod110 ~]# ipvsadm -L -n -c
IPVS connection entries
pro expire state source virtual destination

LVS的规则配置文件：/etc/sysconfig/ipvsadm
找到配置文件方法：
因为：
[root@xuegod110 ~]# ipvsadm-save>/etc/sysconfig/ipvsadm 可以保存。
LVS的规则存储配置文件：/etc/sysconfig/ipvsadm
[root@xuegod63 ~]# cat /etc/sysconfig/ipvsadm
-A -t 192.168.1.100:80 -s rr
-a -t 192.168.1.100:80 -r 192.168.1.120:80 -m -w 1
-a -t 192.168.1.100:80 -r 192.168.1.130:80 -m -w 1

四、 linux下ab网站压力测试命令
实战同时处理1000个请求，一次要执行1000个并发请求

1、 安装httpd，测试
[root@xuegod110 ~]# yum -y install httpd
[root@xuegod110 ~]# echo aaa > /var/www/html/index.html
[root@xuegod110 ~]# systemctl start httpd
[root@xuegod110 ~]# ab -n 1000 -c 1000 http://192.168.1.110/index.html
[root@xuegod110 ~]# ab -n 1000 -c 1000 http://192.168.1.110/index.html
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.1.110 (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.4.6
Server Hostname: 192.168.1.110
Server Port: 80

Document Path: /index.html
Document Length: 4 bytes

Concurrency Level: 1000
Time taken for tests: 0.903 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 262000 bytes
HTML transferred: 4000 bytes
Requests per second: 1107.23 [#/sec] (mean)
Time per request: 903.158 [ms] (mean)
Time per request: 0.903 [ms] (mean, across all concurrent requests)
Transfer rate: 283.29 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 23 28.5 1 69
Processing: 8 173 240.1 51 826
Waiting: 1 173 240.2 50 826
Total: 35 196 260.5 52 882

Percentage of the requests served within a certain time (ms)
50% 52
66% 78
75% 310
80% 479
90% 497
95% 874
98% 879
99% 881
100% 882 (longest request)

2、 命令说明
语法： ab -n 数字 -c 数字 http://链接
-n requests Number of requests to perform
#在测试会话中所执行的请求总个数。默认时，仅执行一个请求
-c concurrency Number of multiple requests to make
#一次产生的请求个数。默认是一次一个。

3、 实战：通过LVS，测试web网站的，要求同时处理1000个请求。 一次要执行1000个并发请求。

提示报错，因为服务器负担不起，所以处理故障。
在进行一次测试

可以看到，可以结束，说明web服务器的瓶颈已经测试出来。

查看LVS的执行情况：

4、 ab各项参数说明
Concurrency（并发） Level: 1000 //并发数
Time taken for tests: 2.166 seconds #整个测试花费的时间
Complete requests: 1000 //完成的请求数量
Failed requests: 0 //失败的请求数量
Write errors: 0
Total transferred: 281120 bytes #整个测试过程中总传输字节数
HTML transferred: 13052 bytes #//整个场景中的HTML内容传输量
Requests per second: 461.77 [#/sec] (mean) #每秒处理请求数。//大家最关心的指标之一，相当于服务器中的每秒事务数 ，后面括号中的 mean 表示这是一个平均值
Time per request: 2165.597 [ms] (mean) # //大家最关心的指标之二，平均请求响应时间 ，后面括号中的 mean 表示这是一个平均值
Time per request: 2.166 [ms] (mean, across all concurrent requests) #每个请求的时间：2.166[毫秒]（意思是说，在所有的并发请求） //每个请求实际运行时间的平均值。
由于对于并发请求，cpu实际上并不是同时处理的，而是按照每个请求获得的时间片逐个轮转处理的，所以基本上第一个Time per request时间约等于第二个Time per request时间乘以并发请求数

Transfer rate: 126.77 [Kbytes/sec] received #传输速率：//平均每秒网络上的流量，可以帮助排除是否存在网络流量过大导致响应时间延长的问题

Connection Times (ms) #连接时间（毫秒）
min mean[+/-sd] median max # median（中间）
Connect: 4 225 143.8 214 538
Processing: 39 484 433.5 318 1581
Waiting: 36 480 433.8 317 1580
Total: 116 709 516.3 581 1807

Percentage of the requests served within a certain time (ms) #在一定的时间内提供服务的请求的百分比（毫秒）
50% 44
66% 49
75% 285
80% 453
90% 495
95% 884
98% 899
99% 904
100% 906 (longest request)
整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中50％的用户响应时间小于44 毫秒，66％ 的用户响应时间小于49 毫秒，最大的响应时间小于906 毫秒