应用负载均衡之LVS(三):使用ipvsadm以及详细分析VS/DR模式

2018-02-27 08:58:55来源:cnblogs.com作者:骏马金龙人点击

分享

LVS系列文章:http://www.cnblogs.com/f-ck-need-u/p/7576137.html


本文目录:
1. 使用ipvsadm
 1.1 安装ipvsadm
 1.2 ipvsadm语法
2.实现VS/NAT模式的负载均衡
3 VS/DR模式的数据包流向分析
4.实现VS/DR模式的负载均衡(CIP、VIP、RIP同网段)
5.实现VS/DR模式的负载均衡(CIP、VIP、RIP不同网段)
 5.1 CIP、RIP不同网段时为何特殊?
 5.2 反向路径过滤rp_filter参数的作用
 5.3 实现VS/DR模式的负载均衡(CIP、RIP不同网段)

1.使用ipvsadm

ipvsadm是ipvs的命令行管理工具,可以定义、删除、查看virtual service和Real Server的属性。

1.1 安装ipvsadm

可以直接yum安装。以下是编译安装ipvsadm的过程,对于内核版本2.6.xx,需要安装的ipvsadm版本要大于1.24。

# 下载ipvsadmwget http://www.linuxvirtualserver.org/software/kernel-2.6/ipvsadm-1.26.tar.gz -P /tmpcd /tmp# 安装依赖包yum -y install libnl* popt*# 安装ipvsadm,注意不需要./configuretar xf ipvsadm-1.26.tar.gz cd ipvsadm-1.26make && make install

编译安装完之后,会在/etc/init.d/ (CentOS6)或/usr/lib/systemd/system/ (CentOS7)目录下自动生成ipvsadm服务管理脚本,这和一般的编译不一样,比较人性化。

安装ipvsadm后,生成以下文件。

[root@xuexi ~]# rpm -ql ipvsadm/etc/sysconfig/ipvsadm-config/usr/lib/systemd/system/ipvsadm.service/usr/sbin/ipvsadm            # ipvs规则管理工具/usr/sbin/ipvsadm-restore    # ipvs规则恢复工具/usr/sbin/ipvsadm-save       # ipvs规则保存工具/usr/share/doc/ipvsadm-1.27/usr/share/doc/ipvsadm-1.27/README/usr/share/man/man8/ipvsadm-restore.8.gz/usr/share/man/man8/ipvsadm-save.8.gz/usr/share/man/man8/ipvsadm.8.gz

1.2 ipvsadm语法

使用ipvsadm --help可以查看使用方法。ipvs的更多功能以及ipvsadm的更详细用法,请man ipvsadm

ipvsadm的选项中,大写选项管理虚拟服务virtual service,小写选项管理关联了虚拟服务的真实服务器RealServer,"-L"和"-l"除外,它们同义。(1).管理virtual services:    添加:-A  -t|u|f service-address [-s scheduler]            -t:tcp协议的集群            -u:udp协议的集群                service-address格式为IP:PORT            -f:firewall-mark防火墙标记                service-address:a num for mark            -s:调度算法    修改:-E -t|u|f service-address [-s scheduler]     和-A使用方法一样    删除:-D -t|u|f service-address示例:# ipvsadm -A -t 172.16.10.20:80 -s rr   (对外的地址,也就是VIP)(2).管理virtual service中的RealServer:    添加:-a  -t|u|f service-address -r server-address [-g|i|m] [-w weight]        -t|u|f service-address:指定Real server所绑定的virtual service        -r server-address:某RS地址,在NAT模型中,可IP:PORT实现端口映射,即端口无需等于VIP对应的port        -g|i|m:指定lvs的类型,有三种:            -g:gataway即DR类型(默认的模型)            -i:--ipip,即TUN类型            -m:masquerade地址伪装即NAT        -w:指定权重(需要调度算法支持权重)    修改:-e和-a用法一样    删除:-d  -t|u|f service-address -r server-address表示从哪个virtual service中删除哪个realserver示例:# ipvsadm -a -t 172.16.10.20:80 -r 192.168.100.9 -m# ipvsadm -a -t 172.16.10.20:80 -r 192.168.100.10 -m (3).查看:      -L或者-l:列出状态信息,配合以下选项用于显示更精确数据        -n:只显示数字格式,不反解IP地址和端口        --stats:显示统计信息        --rate:显示速率信息(每秒的值)        --timeout:显示tcp/tcpfin/udp的会话超时时间长度        --daemon:显示进程状态和多播端口(不太用)        --sort:对-n列出来的进行排序(按协议、IP、端口号升序排序)        -c:显示当前ipvs的连接状况(不能和stats选项同用)(4).其他项:-Z:清空统计数据-C:删除一个或所有virtual service,连同与之绑定的real server也删除-S:保存规则  ipvsadm -S > /path/to/somefile 或者使用ipvsadm-save > /path/to/somefile-R:载入规则  ipvsadm -R < /path/to/somefile 或者使用ipvsadm-restore < /path/to/somefile    service ipvsadm save    service ipvsadm restore

2.实现VS/NAT模式的负载均衡

实验环境如下:

其中:
CIP:172.16.10.22
VIP:172.16.10.21
DIP:192.168.100.17
RIP1:192.168.100.39
RIP2:192.168.100.23

在开始操作前,先回顾下VS/NAT模式的相关内容:

请求过程:CIP-->VIP--ip_forward-->DIP-->RIP响应过程:RIP-->DIP--ip_forward-->VIP-->CIP

由于director接收到CIP发送的数据包后,需要转发给Real Server进行处理,但Real Server的RIP和DIP是同一网段的,因此Director必须将VIP接口上收到的数据包转发给DIP,也就是说Director需要开启ip_forward功能

当RS处理完成后,响应数据需要先转发给Director,但因为响应数据的目标地址为CIP,因此需要将RS的网关指向Director的DIP,这样CIP目的的数据包才能保证交给director进行处理并返回给客户端。

因此,如下操作Director:假设该实验中的VS/NAT采用wrr调度算法。

echo 1 >/proc/sys/net/ipv4/ip_forwardipvsadm -A -t 172.16.10.21:80 -s wrripvsadm -a -t 172.16.10.21:80 -r 192.168.100.39 -m -w 2ipvsadm -a -t 172.16.10.21:80 -r 192.168.100.23 -m -w 3

如下操作各RS:

yum -y install httpdecho "from RS1:192.168.100.39" >/var/www/html/index.html  # 在RS1上操作echo "from RS2:192.168.100.23" >/var/www/html/index.html  # 在RS2上操作service httpd startroute add default gw 192.168.100.17

然后在客户端Win2003上的浏览器上输入http://172.16.10.21进行测试,同时测试调度算法的比例。可以使用下面的命令查看统计数据:

[root@xuexi ~]# ipvsadm -lnIP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags  -> RemoteAddress:Port           Forward Weight ActiveConn InActConnTCP  172.16.10.21:80 wrr  -> 192.168.100.23:80            Masq    3      0          0     -> 192.168.100.39:80            Masq    2      0          0   [root@xuexi ~]# ipvsadm -ln --statsIP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port               Conns   InPkts  OutPkts  InBytes OutBytes  -> RemoteAddress:PortTCP  172.16.10.21:80                    25      113       95    10293     8913  -> 192.168.100.23:80                  15       67       55     6059     4921  -> 192.168.100.39:80                  10       46       40     4234     3992

注意点:
(1).建议不要使用win7/win8/win10作为客户端进行测试,而是使用win server类系统或直接使用unix系统测试。
(2).调度算法是对连接进行调度,而不是对数据包、字节等调度,因此查看统计数据时,应该比较的是Conns列的比例。另外,如果连接数大致满足比例,但数据包或者字节数却远不符合比例(高的多或低的多),那么可能对应的那台RS主机性能比其它RS的性能要好或差。

实验完成后,删除Director上的virtual service,并重新设置RS上的默认路由。

ipvsadm -Croute del default gw 192.168.100.17   # 在RS1和RS2上操作

3.VS/DR模式的数据包流向分析

如图:

在分析数据包流向前,需要厘清一个容易产生疑惑的要点:在VS/DR模式下,TCP连接是客户端和RS之间建立的,Director只是负责改造、转发建立TCP连接时的数据包给后端RealServer;当TCP连接建立完成后,就有了客户端和服务端(RS)的概念,这时客户端将直接和RS进行数据通信,而Director已经退出舞台,不再负责改造、转发请求数据包。也就是说,Director改造、转发的数据包只有客户端第一次发送的syn包,其它数据包和它无关。可以想象,这样的Director相比NAT模式,性能高的不是一点点。

  • (1).当客户端发起http://VIP的请求时,数据包的源和目标地址为CIP-->VIP。这个数据包最终会到达Director。
  • (2).当Director收到请求数据包后,将根据调度算法选择一台后端RealServer作为调度的目标。于是修改数据包的目标MAC地址为该RealServer的RIP所在MAC地址。数据包将转发给该RS,此时数据包的源和目标IP地址仍然为CIP-->VIP,但源和目标MAC地址为DIP_MAC-->RIP_MAC
    • 需要注意的是,Director要将数据包交给RS,需要从VIP接口转发给DIP接口,因此Director需要开启ip_forward功能。但如果VIP和DIP/RIP处于同一个网段,则无需开启该转发功能,因为VIP接口可以直接和RIP接口通信,这时DIP没有存在的必要。
  • (3).被调度到的RS收到Director转发的数据包后,发现目标IP地址已经配置在自身内核,因此会收下该数据包。之后会处理请求,并构建响应数据。
  • (4).RS将响应数据响应给客户端,该响应数据包的源和目标IP地址为VIP-->CIP
    • 由于RS上的VIP一般配置在lo的别名接口上,它无法和外界直接通信,因此数据包最终会从普通网卡上流出,如RIP所在接口。根据TCP/IP协议,响应数据包的源MAC地址也将是普通网卡(如RIP所在接口)的MAC地址。这一细节在后面配置CIP、VIP、RIP不同网段时会引出一种特殊问题,详情见后文。

4.实现VS/DR模式的负载均衡(CIP、VIP、RIP同网段)

CIP、VIP和RIP同网段时,配置非常简单,几乎无需考虑额外的路由问题,也都无需分析数据包流向问题。

实验环境如下:

其中:
CIP:192.168.100.46
VIP:192.168.100.11
DIP:192.168.100.17(由于VIP和RIP同网段,因此它是多余的)
RIP1:192.168.100.47
RIP2:192.168.100.23

配置过程:
如下操作各RS:

# (1).提供web服务和测试页面yum -y install httpdecho "from RS1:192.168.100.47" >/var/www/html/index.html  # 在RS1上操作echo "from RS2:192.168.100.23" >/var/www/html/index.html  # 在RS2上操作service httpd start# (2).设置arp参数echo 1 >/proc/sys/net/ipv4/conf/all/arp_ignoreecho 2 >/proc/sys/net/ipv4/conf/all/arp_announce# (3).设置VIPifconfig lo:0 192.168.100.11/32 uproute add -host 192.168.100.11 dev lo:0

如下操作Director:由于VIP和RIP同网段,因此无需开启ip_forward

ipvsadm -Cipvsadm -A -t 192.168.100.11:80 -s wrripvsadm -a -t 192.168.100.11:80 -r 192.168.100.47:80 -g -w 2ipvsadm -a -t 192.168.100.11:80 -r 192.168.100.23:80 -g -w 1

测试时,建议不要使用win7/win8/win10作为客户端,而是使用win server类系统或直接使用unix系统测试。

5.实现VS/DR模式的负载均衡(CIP、VIP、RIP不同网段)

5.1 CIP、RIP不同网段时为何特殊?

考虑实际的生产环境,由于公网地址有限,一般只给web server的负载均衡系统分配一个公网地址。这个公网地址可能直接分配给VIP,这样CIP、VIP、RIP两两都处于不同网段;还可能分配给路由器或防火墙,然后VIP和RIP都是用私网地址,这样VIP/RIP同网段,但它们和CIP不同网段。

不管公网地址分配给谁,CIP、RIP总是不同网段的。这时需要考虑以下几个问题:

  1. RS将响应数据响应给客户端,该响应数据包的源和目标IP地址为VIP-->CIP,但因为是从RIP所在网卡流出的,这个响应数据包的源MAC地址为MAC_RIP;
  2. 由于RIP和CIP不同网段,因此RS需要借助某个路由设备来转发这个数据包;
  3. 由于RS上的VIP被隐藏,DIP/RIP所在网段的所有主机(包括这个路由设备)上缓存的关于VIP的arp记录都是Director上的(即VIP<-->MAC_V),即使重新发起arp请求,也只能获取到这样的对应关系。因此,响应数据包的源IP、源MAC的对应关系和路由设备arp缓存中记录不一致,这个响应数据包是"非法"数据包。就像同宿舍的人都知道你和你的身份证号码,但如果有一个人拿着你的身份证去找你的舍友办事,他肯定知道这个人是冒充的;
  4. 这个路由设备发现数据包的源MAC地址、源IP和它arp缓存中的记录不一致,它会丢弃这个数据包吗?分三种情况:
    • (1).如果这个数据包的目标IP就是自身的,它会收下这个数据包并处理。当RIP和Client的某个网卡同网段时,就是这种情况,此时Client就是最终的路由目标。
    • (2).如果这个数据包被路由到普通的路由设备上,路由设备默认会将这个数据包丢弃,因为会检查源地址。这称为"reverse path filter"(反向路径过滤)功能。Linux上控制该功能的参数为rp_filter。
    • (3).如果这个数据包被路由到Director所在主机(Linux)上,默认会丢弃这个数据包,因为源IP地址正好在本机上。但可以为内核打上forward_shared补丁,以便使用forward_shared和rp_filter参数来开启转发源IP地址为自身地址数据包的功能。转发时,需要设置转发接口为VIP所在接口,这样数据包的源MAC地址和VIP相互对应,之后的路由过程会一路顺畅。
      根据第四点的三种情况,RS上的路由表可以按需设置成三种情况。当然,第一种情况在实际环境中是不可能的。第二种情况设置很简单,但路由设备关闭源IP地址检查功能后,将更容易受到DDos攻击。第三种情况可以忽略,不仅要重新编译内核,更重要的是VS/DR模式的优点本就在于让Director专注于调度工作来实现高性能。

因此,本文将以第二种情况来做实验测试。第三种情况可参考网上一篇博文:LVS-DR VIP和RIP不同网段的配置方法。

5.2 反向路径过滤rp_filter参数的作用

以下是Linux内核文档中关于rp_filter变量的描述:

rp_filter - INTEGER    0 - No source validation.    1 - Strict mode as defined in RFC3704 Strict Reverse Path        Each incoming packet is tested against the FIB and if the interface        is not the best reverse path the packet check will fail.        By default failed packets are discarded.    2 - Loose mode as defined in RFC3704 Loose Reverse Path        Each incoming packet's source address is also tested against the FIB        and if the source address is not reachable via any interface        the packet check will fail.    Current recommended practice in RFC3704 is to enable strict mode    to prevent IP spoofing from DDos attacks. If using asymmetric routing    or other complicated routing, then loose mode is recommended.    The max value from conf/{all,interface}/rp_filter is used    when doing source validation on the {interface}.    Default value is 0. Note that some distributions enable it    in startup scripts.

大致说明下:rp_filter参数有三个值,0、1、2,Linux上默认为1。

  • 0:不开启源地址校验。
  • 1:开启严格的反向路径校验。对每个进来的数据包,校验其反向路径是否是最佳路径。如果反向路径不是最佳路径,则直接丢弃该数据包。
  • 2:开启松散的反向路径校验。对每个进来的数据包,校验其源地址是否可达,即反向路径是否能通(通过任意网口),如果反向路径不通,则直接丢弃该数据包。这个值是只是为了防止转发无效或冒充的源IP地址,如192.16.10这样的不完整IP。
  • 取/proc/sys/net/ipv4/conf/{all,interface}/rp_filter中的最大值生效。注意,对lo接口设置该参数是无意义的。

对于CIP、RIP不同网段的VS/DR模式来说,当RS将响应数据包(ack+syn)交给Linux路由设备,数据包源IP是VIP,源MAC地址是RIP_MAC。Linux充当路由设备时:

如果设置rp_filter=1(默认),会反向检查源IP是否是最佳路径。显然,由于Linux Router上只能获取到Director上的VIP<-->MAC_VIParp缓存记录,因此反向检查时总是查找到Director上去,但这不是到RIP_MAC的路径,因此丢弃该数据包。

如果设置rp_filter=2,由于Router反向检查时能和VIP能互相通信(尽管是和Director上的VIP通信),因此数据包保留。

如果设置rp_filter=0,则完全不检查源地址,直接转发。

一般情况下,保持默认值比较安全,这样可以防止DDos攻击。如果有修改该参数的需要,则应该将其设置为2。无可奈何的情况下才设置为0。

5.3 实现VS/DR模式的负载均衡(CIP、VIP不同网段)

实验环境如下:之所以Client-->Router-->Director给出了虚线,是因为这里CIP和VIP同网段,它会直接和Director通信,而不会经过Router,但这并不影响结果。

为了测试的便利性,将Director自身也设置为一个RS,其RIP设置为127.0.0.1。

因此:
CIP:172.16.10.22
Route IP1:172.16.10.23
Route IP2:192.168.100.32
VIP:172.16.10.21
DIP:192.168.100.17
RIP1:192.168.100.47
RIP2:192.168.100.23
RIP3:127.0.0.1(在Director上的RIP)

配置过程:
如下操作各RS:不包括Director上的本地RS

# (1).提供web服务和测试页面yum -y install httpdecho "from RS1:192.168.100.47" >/var/www/html/index.html  # 在RS1上操作echo "from RS2:192.168.100.23" >/var/www/html/index.html  # 在RS2上操作service httpd start# (2).设置arp参数echo 1 >/proc/sys/net/ipv4/conf/all/arp_ignoreecho 2 >/proc/sys/net/ipv4/conf/all/arp_announce# (3).设置VIPifconfig lo:0 172.16.10.21/32 uproute add -host 172.16.10.21 dev lo:0# (4).修改RS数据包流出的网关为Router,以保证能和外界客户端通信route del defaultroute add default gw 192.168.100.32

如下操作Router:开启转发功能,但暂时不设置rp_filter,以查看实验结果

echo 1 > /proc/sys/net/ipv4/ip_forward

最后如下操作Director:

echo 1 > /proc/sys/net/ipv4/ip_forwardipvsadm -Cipvsadm -A -t 172.16.10.21:80 -s wrripvsadm -a -t 172.16.10.21:80 -r 192.168.100.47:80 -g -w 1ipvsadm -a -t 172.16.10.21:80 -r 192.168.100.23:80 -g -w 1ipvsadm -a -t 172.16.10.21:80 -r 127.0.0.1:80 -g -w 1# 提供本地RSyum -y install httpdecho "from RS3:127.0.0.1" >/var/www/html/index.htmlservice httpd start# 添加目标地址为CIP的路由,以便调度到本地RS时,数据包能经过Router转发,而非Director直接返回给Clientroute add -host 172.16.10.22 gw 172.16.10.23

测试时,只有当调度到RS3时,才能得到正确的响应结果,而调度器调度到RS1和RS2时,将无法得到正确的响应。实际上是客户端和RS1、RS2无法建立TCP连接。

查看Director上的状态。

[root@xuexi ~]# ipvsadm -ln -cIPVS connection entriespro expire state       source             virtual            destinationTCP 14:58  ESTABLISHED 172.16.10.22:1683  172.16.10.21:80    127.0.0.1:80TCP 00:57  SYN_RECV    172.16.10.22:1679  172.16.10.21:80    192.168.100.23:80TCP 00:55  SYN_RECV    172.16.10.22:1681  172.16.10.21:80    192.168.100.47:80

注意,这里显示的状态是RS上的TCP连接状态,不是Director的。SYN_RECV表示RS1/RS2发送的syn+ack得不到客户端的回应。如果在Router和Client机器上抓包分析的话,会发现syn+ack数据包到Router上就断了,Client根本就没收到syn+ack。

正如前面的分析,只有调度到RS3时,响应数据包的源MAC地址、源IP地址和Router上的arp缓存记录是对应的。默认rp_filter=1反向检查时,这正好是最佳路径。而调度到RS1和RS2时,Router反向检查时由于只能检查到Director上的VIP,因此数据包会被丢弃。

现在,将Router上和RS通信的接口rp_filter设置为2。

echo 2 >/proc/sys/net/ipv4/conf/eth0/rp_filter

再测试时,发现无论是RS1、RS2、RS3都能正确响应结果。

回到Linux系列文章大纲:http://www.cnblogs.com/f-ck-need-u/p/7048359.html
回到网站架构系列文章大纲:http://www.cnblogs.com/f-ck-need-u/p/7576137.html
回到数据库系列文章大纲:http://www.cnblogs.com/f-ck-need-u/p/7586194.html
转载请注明出处:http://www.cnblogs.com/f-ck-need-u/p/8472744.html

注:若您觉得这篇文章还不错请点击右下角推荐,您的支持能激发作者更大的写作热情,非常感谢!

最新文章

123

最新摄影

闪念基因

微信扫一扫

第七城市微信公众平台