实例的网络联通性问题

9月8日更新：解释及解决办法

解释

OpenStack中有两种ip地址的概念：fixed ip和floating ip。fixed ip 是实例的真实ip，在创建实例时注入，如果操作系统不支持注入如windows，OpenStack会在实例启动后通过dhcp方式把fixed ip分配给实例。floating ip是nova-network节点通过iptables 的SNAT/DNAT实现的，就是在nova-network进行floating ip到fixed ip转化，这依赖于实例能获得正确的fixed ip。在我的环境里除了nova-network使用的dnsmasq外还存在着另外的dhcp服务器，如果实例在nova-network启动前启动了，则会从其它的dhcp获取ip显然我通过fixed ip来连接实例就不行了，fixed ip不对，floating ip也就无从谈起。另外nova-network重启后不会重建与dhcp服务器有关的防火墙规则，而默认CentOS/RHEL是不开放这些端口的。这就导致nova-network重启后已有的实例无法继续使用它们获取的fixed ip。新建的实例更无法获取fixed ip了。

解决办法

移除OpenStack环境中的外部dhcp服务器，防止外部dhcp对实例的影响，关于nova-network重启的bug参考这里修改：https://github.com/openstack/nova/commit/bc621bca08d51076bd81f15e29e8b89ea946503a

这是偶然发现的问题，设置好网桥后，发现重启服务器后实例的状态可以自动恢复到重启前，于是各种高兴，但是却发现了实例的网络联通性问题。

前面提到过，控制节点上nova-network运行后，会将br100的ip设置成10.0.0.1，并通过iptables的NAT功能映射原来设置的ip地址。这样在控制节点就可以ping能实例或通过ssh连接实例，也可通过原来的ip访问控制节点。

但是重启服务器后，实例是恢复了，但运行相关服务后在控制节点用ping命令来ping各实例时却出问题了：
1.在控制节点运行除nova-compute的服务后，控制节点实例无法ping通，启动nova-compute，如果没有设置让实例随nova-compute的运行重启，仍然无法ping能，如果实例随nova-compute重启了就可以ping通。
2.如果计算节点重启在控制节点的各服务运行后，即使不启动nova-compute也行从控制节点ping通其上的实例，如果计算节点在控制节点各服务运行前启动了，其上的实例ping结果跟控制节点是一样的。
3.在控制节点和计算节点实例都能从控制节点ping能的情况下，重启控制节点并启动相关服务，无法ping通计算节点的实例，设置计算节点的实例随nova-compute重启而重启后，重启nova-compute，计算节点的实例能ping通了。

4.在控制节点和计算节点实例都能从控制节点ping能的情况下，一个一个重启控制节点的服务，测试各实例的ping结果，发现nova-scheduler终止后所有实例都无法ping通，重启后也无法ping后，即使此时重启所有nova服务包括nova-compute并让实例随其重启也无法ping通（甚至我还重启了libvirtd)，必须要重启控制节点才行。

从以上实验可以得出以下结论：

在nova相关服务运行前已经启动的实例无法ping通（需要重启实例才行），在其后启动的实例即使没有运行nova-compute也能ping通。如果nova-scheduler被终止再启动，必须要重启控制节点，否则无论如何也无法ping实例！

北方工业大学 | 云计算研究中心 | 姜永