解除openstack中instance对IP的限制（在虚拟机中飘VIP）

cheun

　　最近公司的几个关键业务跑在openstack中的虚拟机中，想把几个虚拟机做成负载均衡和高可用集群。
　　

　　对于负载均衡，G版本已经集成了haproxy插件，对haproxy的配置做了一层封装，可以很方便的通过quantum去创建一个负载均衡池，为相同或者不同宿主机上的虚拟机提供负载均衡的能力。
　　

　　在这个模式下，haproxy是运行在宿主机上的。
　　遗憾的是，目前还不能通过openstack做到haproxy的高可用。
　　

　　想要做高可用，只能在虚拟机中去飘VIP了
　　

　　但是创建了虚拟机之后，在这个虚拟机实例中只能使用指定的IP。
　　这就导致想在虚拟机中部署高可用去飘VIP是不可行的。
　　

　　可以理解，在公有云环境下，是不可能让用户在虚拟机中随意去配置额外地址的。
　　但我们是私有云环境，这个规则对私有云环境下很是麻烦。

在openstack中创建虚拟机，通过nova boot的--nic选项指定网卡和IP地址： 　　--nic net-id=${NETWORK_ID},v4-fixed-ip=${Host_IP}

　　

　　之前一直以为是iptables规则导致的。于是去看了一遍宿主机中的iptables规则

root@node1:~# iptables -vnL 　　Chain INPUT (policy ACCEPT 3556K packets, 744M bytes) 　　 pkts bytes target prot opt in out source destination 　　1778K 372M nova-compute-INPUT all -- * * 0.0.0.0/0 0.0.0.0/0 　　 　　Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) 　　 pkts bytes target prot opt in out source destination 　　 150 13488 nova-filter-top all -- * * 0.0.0.0/0 0.0.0.0/0 　　 6 1392 nova-compute-FORWARD all -- * * 0.0.0.0/0 0.0.0.0/0 　　 　　Chain OUTPUT (policy ACCEPT 4208K packets, 567M bytes) 　　 pkts bytes target prot opt in out source destination 　　4202K 567M nova-filter-top all -- * * 0.0.0.0/0 0.0.0.0/0 　　2106K 284M nova-compute-OUTPUT all -- * * 0.0.0.0/0 0.0.0.0/0 　　 　　Chain nova-compute-FORWARD (1 references) 　　 pkts bytes target prot opt in out source destination 　　 4 1312 ACCEPT udp -- * * 0.0.0.0 255.255.255.255 udp spt:68 dpt:67 　　 2 80 ACCEPT all -- brq3eefcd79-07 * 0.0.0.0/0 0.0.0.0/0 　　 0 0 ACCEPT all -- * brq3eefcd79-07 0.0.0.0/0 0.0.0.0/0 　　 　　Chain nova-compute-INPUT (1 references) 　　 pkts bytes target prot opt in out source destination 　　 2 656 ACCEPT udp -- * * 0.0.0.0 255.255.255.255 udp spt:68 dpt:67 　　 　　Chain nova-compute-OUTPUT (1 references) 　　 pkts bytes target prot opt in out source destination 　　 　　Chain nova-compute-inst-15 (1 references) 　　 pkts bytes target prot opt in out source destination 　　 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 　　 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 　　 0 0 nova-compute-provider all -- * * 0.0.0.0/0 0.0.0.0/0 　　 0 0 ACCEPT udp -- * * 10.16.0.102 0.0.0.0/0 udp spt:67 dpt:68 　　 0 0 ACCEPT all -- * * 10.16.0.0/24 0.0.0.0/0 　　 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 1:65535 　　 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 1:65535 　　 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 　　 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 code 8 　　 0 0 nova-compute-sg-fallback all -- * * 0.0.0.0/0 0.0.0.0/0 　　 　　Chain nova-compute-inst-17 (1 references) 　　 pkts bytes target prot opt in out source destination 　　 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 　　 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 　　 0 0 nova-compute-provider all -- * * 0.0.0.0/0 0.0.0.0/0 　　 0 0 ACCEPT udp -- * * 10.16.0.102 0.0.0.0/0 udp spt:67 dpt:68 　　 0 0 ACCEPT all -- * * 10.16.0.0/24 0.0.0.0/0 　　 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 1:65535 　　 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 1:65535 　　 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 　　 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 code 8 　　 0 0 nova-compute-sg-fallback all -- * * 0.0.0.0/0 0.0.0.0/0 　　 　　Chain nova-compute-local (1 references) 　　 pkts bytes target prot opt in out source destination 　　 0 0 nova-compute-inst-15 all -- * * 0.0.0.0/0 10.16.0.111 　　 0 0 nova-compute-inst-17 all -- * * 0.0.0.0/0 10.16.0.131 　　 　　Chain nova-compute-provider (2 references) 　　 pkts bytes target prot opt in out source destination 　　 　　Chain nova-compute-sg-fallback (2 references) 　　 pkts bytes target prot opt in out source destination 　　 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 　　 　　Chain nova-filter-top (2 references) 　　 pkts bytes target prot opt in out source destination 　　2106K 284M nova-compute-local all -- * * 0.0.0.0/0 0.0.0.0/0

　　

　　分析一下这些openstack自动生成的规则，可以看到input，forword和output链默认都是accept状态。分析每条链对数据包的跳转和过滤，如果在虚拟机中配置新的地址，是不会被过滤的。
　　

　　经过一番折腾，最终发现限制IP的原因是ebtables在起作用

root@node1:~# ebtables -t nat -L 　　Bridge table: nat 　　 　　Bridge chain: PREROUTING, entries: 2, policy: ACCEPT 　　-i tap0678bf1d-41 -j libvirt-I-tap0678bf1d-41 　　-i tap496fa038-9e -j libvirt-I-tap496fa038-9e 　　 　　Bridge chain: OUTPUT, entries: 0, policy: ACCEPT 　　 　　Bridge chain: POSTROUTING, entries: 0, policy: ACCEPT 　　 　　Bridge chain: libvirt-I-tap0678bf1d-41, entries: 4, policy: ACCEPT 　　-j I-tap0678bf1d-41-mac 　　-p IPv4 -j I-tap0678bf1d-41-ipv4-ip 　　-p ARP -j I-tap0678bf1d-41-arp-mac 　　-p ARP -j I-tap0678bf1d-41-arp-ip 　　 　　Bridge chain: I-tap0678bf1d-41-mac, entries: 2, policy: ACCEPT 　　-s fa:16:3e:a6:5f:70 -j RETURN 　　-j DROP 　　 　　Bridge chain: I-tap0678bf1d-41-ipv4-ip, entries: 3, policy: ACCEPT 　　-p IPv4 --ip-src 0.0.0.0 --ip-proto udp -j RETURN 　　-p IPv4 --ip-src 10.16.0.131 -j RETURN 　　-j DROP 　　 　　Bridge chain: I-tap0678bf1d-41-arp-mac, entries: 2, policy: ACCEPT 　　-p ARP --arp-mac-src fa:16:3e:a6:5f:70 -j RETURN 　　-j DROP 　　 　　Bridge chain: I-tap0678bf1d-41-arp-ip, entries: 2, policy: ACCEPT 　　-p ARP --arp-ip-src 10.16.0.131 -j RETURN 　　-j DROP 　　 　　Bridge chain: libvirt-I-tap496fa038-9e, entries: 4, policy: ACCEPT 　　-j I-tap496fa038-9e-mac 　　-p IPv4 -j I-tap496fa038-9e-ipv4-ip 　　-p ARP -j I-tap496fa038-9e-arp-mac 　　-p ARP -j I-tap496fa038-9e-arp-ip 　　 　　Bridge chain: I-tap496fa038-9e-mac, entries: 2, policy: ACCEPT 　　-s fa:16:3e:58:1:ac -j RETURN 　　-j DROP 　　 　　Bridge chain: I-tap496fa038-9e-ipv4-ip, entries: 3, policy: ACCEPT 　　-p IPv4 --ip-src 0.0.0.0 --ip-proto udp -j RETURN 　　-p IPv4 --ip-src 10.16.0.111 -j RETURN 　　-j DROP 　　 　　Bridge chain: I-tap496fa038-9e-arp-mac, entries: 2, policy: ACCEPT 　　-p ARP --arp-mac-src fa:16:3e:58:1:ac -j RETURN 　　-j DROP 　　 　　Bridge chain: I-tap496fa038-9e-arp-ip, entries: 2, policy: ACCEPT 　　-p ARP --arp-ip-src 10.16.0.111 -j RETURN 　　-j DROP

　　ebtables是linux专门做二层数据链路层过滤的。
　　

　　在通过nova创建虚拟机后，会生成libvirt的一个xml配置文件
　　路径在：/etc/libvirt/nwfilter/nova-base.xml
　　里面定义了以下规则，这些规则限制了在虚拟机上的地址，在二层上就做了过滤

<filter name='nova-base' chain='root'> 　　 <uuid>12ec8693-253a-7db0-7cd3-f8cc0a1e1b02</uuid> 　　 <filterref filter='no-mac-spoofing'/> 　　 <filterref filter='no-ip-spoofing'/> 　　 <filterref filter='no-arp-spoofing'/> 　　 <filterref filter='allow-dhcp-server'/> 　　</filter>

　　

　　然后为每个虚拟机创建一个xml文件，每个虚拟机的xml配置中包含了nova-base.xml中的配置
　　打开其中一个虚拟机的xml配置，可以看到，这个配置文件中只放行了指定IP在二层上可以通过，所以其它手动配置的地址是不可用的。
　　cat /etc/libvirt/nwfilter/nova-instance-instance-0000000f-fa163e5801ac.xml

<filter name='nova-instance-instance-0000000f-fa163e5801ac' chain='root'> 　　 <uuid>972d18be-2db0-4bf2-2853-a0a61beac036</uuid> 　　 <filterref filter='nova-base'> 　　 <parameter name='DHCPSERVER' value='10.16.0.102'/> 　　 <parameter name='IP' value='10.16.0.111'/> 　　 <parameter name='PROJMASK' value='255.255.255.0'/> 　　 <parameter name='PROJNET' value='10.16.0.0'/> 　　 </filterref> 　　</filter>

　　

　　libvirt可以通过在这些xml配置的规则，去生成ebtables规则，最终是ebtables做出限制。
　　

　　如何破解？
　　修改nova-base.xml文件
　　注释掉以下三行
<filterref filter='no-mac-spoofing'/>
<filterref filter='no-ip-spoofing'/>
<filterref filter='no-arp-spoofing'/>
　　然后重启libvirt进程，libvirt会重新读取xml中的配置，生成新的ebtables规则。
　　修改后，我通过新建虚拟机，重启nova-computer进程，或者直接重启宿主机，这个base文件都不会发生变化了。
　　

　　还有就是修改nova源码（未测试）
　　源码位置在
　　/usr/lib/python2.7/dist-packages/nova/virt/libvirt/firewall.py
　　第198行（G版本中）

　　去掉no-mac-spoofing,no-ip-spoofing,no-arp-spoofing这三行，以后生成nova-base.xml文件就可以不包含这3个选项了。