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參考這裡修改：
這是偶然發現的問題，設定好網橋後，發現重啟伺服器後例項的狀態可以自動恢復到重啟前，於是各種高興，但是卻發現了例項的網路聯通性問題。
前面提到過，控制節點上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例項！
北方工業大學 | 雲計算研究中心 | 姜永
動態聯通性問題 union find演算法
在給定的一張節點網路 也就是圖 中，判斷兩個節點之是否可達的問題就是連通性問題。場景 判斷兩個使用者之間是否存在間接社交關係 判斷兩台計算機之間是否建立連線等。使用最基本的陣列作為該演算法的資料結構。陣列下標 i 代表當前節點編號，id i 的值表示與該節點連通的某乙個節點。每個節點id i 的值初...
網路連通性問題排查
眾所周知，網路的基本解耦方式就是分層。針對閘道器連通性問題的排查我們可以順著網路協議站的層次進行排查。針對不同的應用層協議有不同的排查方法 1.1 通用的dns應用排查，首先如果我們使用服務的使用沒有直接使用ip位址而是使用網域名稱的話。服務無法連通，我們首先要考慮網域名稱解析服務是否存在問題。排查...
連通性問題
1 伺服器可以ping通客戶端，說明伺服器和客戶端之間的鏈路是通的。客戶端不能ping通伺服器，很可能是防火牆的原因，包括伺服器本身自帶的防火牆和伺服器與交換機之間的cisco asa 5505防火牆。防火牆的訪問規則中清除禁止ping入之類的規則，或者清除拒絕接收icmp包的規則。2 ping不通...