KVM部署LVS集群故障案例一则

云深处

　　
一、故障现象
　　KVM部署LVS（Linux Virtual Server）集群后，能够单独以HTTP方式访问RS（Real Server）的实际IP，但无法通过VIP（Virtual IP）访问。
　　二、故障分析过程
　　
1.简化架构
　　
　　在原部署环境中，采用的架构是LVS的DR（Direct Return）模式，如下图所示：

http://mmbiz.qpic.cn/mmbiz_png/3zoYydJjr10GNlB2y9VmpiaeweTEe0uFPRuzBHUU2fwcGLsAkYEHaNMoCCI1uiawzcXpHK5TUXv7u0GzXn0jQxUA/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1
                          

　　为了便于故障排查，我们简化为

http://mmbiz.qpic.cn/mmbiz_png/3zoYydJjr10GNlB2y9VmpiaeweTEe0uFPfS6R91YCuV1ial9qUYs99XiaRrCJzO7ZseMTCY7bdhFBq3MZgXicfz9EQ/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1

　　也就是在2台宿主机上，各保留一个虚拟机，角色分别是LVS的Director（调度器）和RS。
　　该架构中的服务器（及虚拟机）的IP和MAC地址如下：

角色	IP	MAC	网络结构
宿主机1	x.y.z.70	a0:d3:c1:f4:66:ac	宿主机1的eth0和Director1的eth0（在宿主机1中对应为vnet0）桥接到br0
Director1	x.y.z.200	02:00:73:b6:53:c8
宿主机2	x.y.z.73	a0:d3:c1:f9:f3:fc	宿主机2的eth0和RS2的eth0（在宿主机2中对应为vnet0）桥接到br0
RS2	x.y.z.226	02:00:73:b6:53:e2
VIP	x.y.z.208	02:00:73:b6:53:c8
Client IP	192.243.119.145

2.确认Director1是否能够正确识别到RS2提供的服务
　　在Director1上，使用如下的命令检查
　　[iyunv@Director1 ~]# ipvsadm -ln --sort
　　IP Virtual Server version 1.2.1 (size=4096)
　　Prot LocalAddress:Port Scheduler Flags
　　-> RemoteAddress:Port           Forward Weight ActiveConn InActConn
　　TCP  x.y.z.208:80 rr
　　❶-> x.y.z.226:80           Route   2      0         0        
　　由以上的输出❶可以看出，Director1能够正确识别到RS2提供的服务。

3.确认Director1是否能够正确重写MAC地址
　　在Director1上执行以下的命令：
　　[iyunv@Director1 ~]# tcpdump -vvv -nnn -e -i eth0 host 192.243.119.145
　　❶11:39:19.372804 84:78:ac:27:6c:41 > 02:00:73:b6:53:c8,ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 48, id 47264, offset 0, flags[DF], proto TCP (6), length 60)
　　192.243.119.145.51643 > x.y.z.208.80:Flags [S], cksum 0x000e (correct), seq 3639534333,win 14600, options [mss 1460,sackOK,TS val 780753501ecr 0,nop,wscale 7], length 0
　　❷11:39:19.372815 02:00:73:b6:53:c8 > 02:00:73:b6:53:e2,ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 48, id 47264, offset 0, flags[DF], proto TCP (6), length 60)
　　192.243.119.145.51643 > x.y.z.208.80:Flags [S], cksum 0x000e (correct), seq 3639534333,win 14600, options [mss 1460,sackOK,TS val 780753501ecr 0,nop,wscale 7], length 0
　　❸11:39:20.372079 84:78:ac:27:6c:41 > 02:00:73:b6:53:c8,ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 48, id 47265, offset 0, flags[DF], proto TCP (6), length 60)
　　192.243.119.145.51643 > x.y.z.208.80:Flags [S], cksum 0xfc25 (correct), seq 3639534333,win 14600, options [mss 1460,sackOK,TS val 780754501ecr 0,nop,wscale 7], length 0
　　❹11:39:20.372091 02:00:73:b6:53:c8> 02:00:73:b6:53:e2, ethertype IPv4 (0x0800), length 74: (tos 0x0,ttl 48, id 47265, offset 0, flags [DF], proto TCP (6), length 60)
　　192.243.119.145.51643 > x.y.z.208.80:Flags [S], cksum 0xfc25 (correct), seq 3639534333,win 14600, options [mss 1460,sackOK,TS val 780754501ecr 0,nop,wscale 7], length 0
　　---以下略去客户端第3、4、5次重传数据
　　从❷所示的以太网帧中，我们能够看到❶所示的以太网帧目的MAC地址被Director1重写成了RS2的MAC地址，同时源MAC地址被Director1重写成了Director1本身的MAC地址。
　　从❸和❹所示的以太网帧中，我们能够看到Client（192.243.119.145）在1s后（❸中的TSval 780754501比❶中的TSval 780753501大1000ms，TCPSequence相同）（注：TS val表示发送方的时间戳，单位是ms）进行了SYN包重传，说明Client和RS2没有正常建立TCP连接。此时，Director1仍然正确重写了MAC地址。
4.确认宿主机1是否能够正确转发虚拟机Director1重写后的帧
　　在宿主机上执行以下命令：
　　[iyunv@HOST1 ~]# tcpdump -vvv -nnn -e -i br0 host 192.243.119.145
　　❶11:39:19.430993 84:78:ac:27:6c:41 > 02:00:73:b6:53:c8,ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 48, id 47264, offset 0, flags[DF], proto TCP (6), length 60)
　　192.243.119.145.51643 > x.y.z.208.80:Flags [S], cksum 0x000e (correct), seq 3639534333,win 14600, options [mss 1460,sackOK,TS val 780753501ecr 0,nop,wscale 7], length 0
　　❷11:39:20.430238 84:78:ac:27:6c:41 > 02:00:73:b6:53:c8,ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 48, id 47265, offset 0, flags[DF], proto TCP (6), length 60)
　　192.243.119.145.51643 > x.y.z.208.80:Flags [S], cksum 0xfc25 (correct), seq 3639534333,win 14600, options [mss 1460,sackOK,TS val 780754501ecr 0,nop,wscale 7], length 0
　　---以下略去客户端第3、4、5次重传数据
　　从❶和❷所示的以太网帧中，我们能够看到宿主机1未转发虚拟机Director1重写后的以太网帧（其中❷是❶的Client重传，我们没有观察到❶和❷的MAC地址被重写的情况）。
　　很明显，问题出在宿主机1上，它没有转发Director1重写后的以太网帧。
　　我们来看看为什么会发生这个问题。
5.检查宿主机1上虚拟机Director1的网络配置
　　在宿主机1上执行以下命令：
　　[iyunv@HOST1 ~]# virsh dumpxml r2-10105
　　<interfacetype='bridge'>
　　<mac address='02:00:73:b6:53:c8'/>
　　<source bridge='br0'/>
　　<target dev='vnet0'/>
　　<modeltype='virtio'/>
　　❶<filterref filter='clean-traffic'>
　　❷<parameter name='IP' value='x.y.z.200'/>
　　</filterref>
　　<aliasname='net0'/>
　　<address type='pci'domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
　　</interface>
　　从❶和❷中，我们看到Director1被引用了一个名为'clean-traffic'的过滤策略，同时给变量IP赋值为Director1的IP地址x.y.z.200。
　　在宿主机1上执行以下命令：
　　[iyunv@HOST1 ~]# virsh nwfilter-dumpxml clean-traffic
　　<filter name='clean-traffic' chain='root'>
　　<uuid>8c2059f9-d00f-4d1d-b96e-69e7d2b41c0f</uuid>
　　<filterreffilter='no-mac-spoofing'/>
　　❸<filterreffilter='no-ip-spoofing'/>
　　<rule action='accept'direction='out' priority='-650'>
　　<macprotocolid='ipv4'/>
　　</rule>
　　<filterreffilter='allow-incoming-ipv4'/>
　　<filterreffilter='no-arp-spoofing'/>
　　<rule action='accept'direction='inout' priority='-500'>
　　<macprotocolid='arp'/>
　　</rule>
　　<filterreffilter='no-other-l2-traffic'/>
　　<filterreffilter='qemu-announce-self'/>
　　</filter>
　　[iyunv@HOST1 ~]# virsh nwfilter-dumpxml no-ip-spoofing
　　<filter name='no-ip-spoofing' chain='ipv4-ip' priority='-710'>
　　<uuid>bf7be725-1486-410f-8a8b-42c82b952261</uuid>
　　<rule action='return'direction='out' priority='100'>
　　<ip srcipaddr='0.0.0.0'protocol='udp'/>
　　</rule>
　　<rule action='return'direction='out' priority='500'>
　　❹<ipsrcipaddr='$IP'/>
　　</rule>
　　❺<rule action='drop' direction='out' priority='1000'/>
　　</filter>
　　从❸、❹、❺中，我们看到在宿主机1中把Director1的发出的数据包的源地址限定为x.y.z.200，任何从Director1发出的数据包，如果源IP为其他，则被过滤掉（drop）。
　　注意：
　　在LVS的DR模式部署中，Director会重写来自客户端的以太网帧的源MAC地址和目的MAC地址，但会保留源IP地址和目的IP地址，因此Director发出的数据包得源IP地址并不是在这个虚拟机上配置的IP地址，也就是进行了IP的伪装（spoofing）。恰好被宿主机1上对它限制给过滤了。
　　三、故障解决方法
　　
　　根据以上的分析，我们知道，为了能够在KVM集群中配置DR模式的LVS集群，我们必须禁用’no-ip-spoofing’的过滤策略。
　　方法是：
　　1）执行：
　　virsh edit r2-10105
　　2）删除以下内容：
　　<filterref filter='clean-traffic'>
　　<parameter name='IP'value='x.y.z.200'/>
　　</filterref>
　　3）重启虚拟机。
　　4）我们采用以下的步骤抓包验证。
　　[iyunv@HOST1 ~]#  tcpdump -i br0 -s 0 host 192.243.119.145 -vvv-nnn -s 0 -e
　　tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size65535 bytes
　　❶16:39:37.842828 84:78:ac:27:6c:41 > 02:00:73:b6:53:c8,ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 48, id 59437, offset 0, flags[DF], proto TCP (6), length 60)
　　192.243.119.145.48377 > x.y.z.208.80:Flags [S], cksum 0x8721 (correct), seq 2886813932, win 14600, options [mss1460,sackOK,TS val 885170369 ecr 0,nop,wscale 7], length 0
　　❷16:39:37.842990 02:00:73:b6:53:c8 > 02:00:73:b6:53:e2,ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 48, id 59437, offset 0, flags[DF], proto TCP (6), length 60)
　　192.243.119.145.48377 > x.y.z.208.80:Flags [S], cksum 0x8721 (correct), seq 2886813932, win 14600, options [mss1460,sackOK,TS val 885170369 ecr 0,nop,wscale 7], length 0
　　---以下略去其他正常数据通信
　　从❶和❷所示的以太网帧中，我们能够看到宿主机1转发了虚拟机Director1重写后的以太网帧。因此，这个问题得以完美解决。
　　四、再探原理
　　
　　通过这个故障案例，我们对KVM的网络过滤策略有了更深的理解。那么，这些过滤策略到底是如何在系统里面生效的呢？
　　通过在宿主机上配置iptables、ebtables，宿主机能够对虚拟机进行网络限制。其中，iptables实现对四层TCP、UDP端口的网络流量过滤；ebtables对二层MAC地址、三层IP地址进行过滤。如下是在宿主机1上对虚拟机进行MAC地址限定、源IP限定的规则：
　　[iyunv@HOST1 ~]# ebtables -t nat --list
　　Bridge table: nat
　　Bridge chain: PREROUTING, entries: 1, policy: ACCEPT
　　-i vnet0 -j libvirt-I-vnet0 #宿主机vnet0入流量走libvirt-I-vnet0策略
　　Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
　　Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT
　　-o vnet0 -j libvirt-O-vnet0 #宿主机vnet0出流量走libvirt-O-vnet0策略
　　Bridge chain: libvirt-I-vnet0, entries: 9, policy: ACCEPT
　　-j I-vnet0-mac
　　-p IPv4 -j I-vnet0-ipv4-ip
　　-p IPv4 -j ACCEPT
　　-p ARP -j I-vnet0-arp-mac
　　-p ARP -j I-vnet0-arp-ip
　　-p ARP -j ACCEPT
　　-p 0x8035 -j I-vnet0-rarp
　　-p 0x835 -j ACCEPT
　　-j DROP
　　Bridge chain: libvirt-O-vnet0, entries: 4, policy: ACCEPT
　　-p IPv4 -j O-vnet0-ipv4
　　-p ARP -j ACCEPT
　　-p 0x8035 -j O-vnet0-rarp
　　-j DROP
　　Bridge chain: I-vnet0-mac, entries: 1, policy: ACCEPT
　　-s 2:0:73:b6:53:c8 -j RETURN #限定源MAC地址
　　-j DROP
　　Bridge chain: I-vnet0-ipv4-ip, entries: 3, policy: ACCEPT
　　-p IPv4 --ip-src 0.0.0.0 --ip-proto udp -j RETURN
　　-p IPv4 --ip-src x.y.z.200 -j RETURN #限定源IP地址
　　-j DROP
　　Bridge chain: O-vnet0-ipv4, entries: 1, policy: ACCEPT
　　-j ACCEPT
　　五、总结
　　
　　在KVM环境中部署LVS集群时，要特别注意宿主机上iptables、ebtables对虚拟机的影响。因为此时，虚拟机并不是使用用户态的的应用程序进行代理，而是使用了网络地址转换（NAT模式）、MAC地址重写（DR模式）等“非常规”方法。
　　通过这个案例，我们同时可以知道，在遇到未知可能涉及到网络方便的问题时，使用网络分析技术可以提供有效的信息来帮助我们定位和排除问题。
　　阅读原文