解除openstack中instance對IP的限制（在虛拟機中飄VIP）

最近公司的幾個關鍵業務跑在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)

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)

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)

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)

2 656 ACCEPT udp -- * * 0.0.0.0 255.255.255.255 udp spt:68 dpt:67

Chain nova-compute-OUTPUT (1 references)

Chain nova-compute-inst-15 (1 references)

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)

Chain nova-compute-local (1 references)

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)

Chain nova-compute-sg-fallback (2 references)

0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain nova-filter-top (2 references)

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

Bridge chain: I-tap0678bf1d-41-arp-mac, entries: 2, policy: ACCEPT

-p ARP --arp-mac-src fa:16:3e:a6:5f:70 -j RETURN

Bridge chain: I-tap0678bf1d-41-arp-ip, entries: 2, policy: ACCEPT

-p ARP --arp-ip-src 10.16.0.131 -j RETURN

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

Bridge chain: I-tap496fa038-9e-ipv4-ip, entries: 3, policy: ACCEPT

-p IPv4 --ip-src 10.16.0.111 -j RETURN

Bridge chain: I-tap496fa038-9e-arp-mac, entries: 2, policy: ACCEPT

-p ARP --arp-mac-src fa:16:3e:58:1:ac -j RETURN

Bridge chain: I-tap496fa038-9e-arp-ip, entries: 2, policy: ACCEPT

-p ARP --arp-ip-src 10.16.0.111 -j RETURN

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>

libvirt可以通過在這些xml配置的規則，去生成ebtables規則，最終是ebtables做出限制。

如何破解？

修改nova-base.xml檔案

注釋掉以下三行

然後重新開機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個選項了。

本文轉自lustlost 51CTO部落格，原文連結：http://blog.51cto.com/lustlost/1324832，如需轉載請自行聯系原作者