OpenStack虛擬機網絡問題

當發現你的OpenStack虛擬機網絡有問題，不妨先試一下這16個步驟

 

1. Security Group所有打開，這是最基本的，可是不少人容易忘記

 

其實遇到過無數這種場景了，Debug了半天網絡問題，各類手段都用上了，最後發現安全組居然沒有打開。

 

 

 

 

2. 經過界面查看虛擬機的log，也能夠在compute節點上查看console.log文件，看看裏面是否有DHCP獲取IP成功的日誌

 

在界面上能夠看控制檯日誌

 

 

在compute節點上能夠查看

 

/var/lib/nova/instances/6323a941-de10-4ed3-9e2f-1b2b25e79b66/console.log

 

若是沒有日誌，則說明image有問題

 

在grub裏面

linux /boot/vmlinuz-3.2.0-49-virtual root=UUID=6d2231e4-0975-4f35-a94f-56738c1a8150 ro console=ttyS0

 

GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0「

 

update-grub

 

3. 若是虛擬機連不上DHCP Server，則須要準備一個不使用metadata server，而是用用戶名密碼能夠登陸的image

 

這種Image很好作，本身動手作一個就能夠了，啓動鏡像後去掉cloud-init相關配置，而後設置一個默認的用戶名密碼。

 

4. 經過VNC登陸

 

 

5. 若是VNC登陸不進去，說明VNC配置的有問題，方法一從新配置VNC

 

 

VNC Proxy的功能：

• 將公網(public network)和私網(private network)隔離

• VNC client運行在公網上，VNCServer運行在私網上，VNC Proxy做爲中間的橋樑將兩者鏈接起來

• VNC Proxy經過token對VNC Client進行驗證

• VNC Proxy不只僅使得私網的訪問更加安全，並且將具體的VNC Server的實現分離，能夠支持不一樣Hypervisor的VNC Server但不影響用戶體驗

 

VNC Proxy的部署

• 在Controller節點上部署nova-consoleauth 進程，用於Token驗證

• 在Controller節點上部署nova-novncproxy 服務，用戶的VNC Client會直接鏈接這個服務

• Controller節點通常有兩張網卡，鏈接到兩個網絡，一張用於外部訪問，咱們稱爲public network，或者API network，這張網卡的IP地址是外網IP，如圖中172.24.1.1，另一張網卡用於openstack各個模塊之間的通訊，稱爲management network，通常是內網IP，如圖中10.10.10.2

• 在Compute節點上部署nova-compute，在nova.conf文件中有下面的配置

• vnc_enabled=True

• vncserver_listen=0.0.0.0 //VNC Server的監聽地址

• vncserver_proxyclient_address=10.10.10.2 //nova vnc proxy是經過內網IP來訪問vnc server的，因此nova-compute會告知vnc proxy用這個IP來鏈接我。

• novncproxy_base_url=http://172.24.1.1:6080/vnc_auto.html //這個url是返回給客戶的url，於是裏面的IP是外網IP

 

VNC Proxy的運行過程：

1. 一個用戶試圖從瀏覽器裏面打開鏈接到虛擬機的VNC Client

2. 瀏覽器向nova-api發送請求，要求返回訪問vnc的url

3. nova-api調用nova-compute的get vnc console方法，要求返回鏈接VNC的信息

4. nova-compute調用libvirt的get vnc console函數

5. libvirt會經過解析虛擬機運行的/etc/libvirt/qemu/instance-0000000c.xml文件來得到VNC Server的信息

6. libvirt將host, port等信息以json格式返回給nova-compute

7. nova-compute會隨機生成一個UUID做爲Token

8. nova-compute將libvirt返回的信息以及配置文件中的信息綜合成connect_info返回給nova-api

9. nova-api會調用nova-consoleauth的authorize_console函數

10. nova-consoleauth會將instance –> token, token –> connect_info的信息cache起來

11. nova-api將connect_info中的access url信息返回給瀏覽器：http://172.24.1.1:6080/vnc_auto.html?token=7efaee3f-eada-4731-a87c-e173cbd25e98&title=helloworld%289169fdb2-5b74-46b1-9803-60d2926bd97c%29

12. 瀏覽器會試圖打開這個連接

13. 這個連接會將請求發送給nova-novncproxy

14. nova-novncproxy調用nova-consoleauth的check_token函數

15. nova-consoleauth驗證了這個token，將這個instance對應的connect_info返回給nova-novncproxy

16. nova-novncproxy經過connect_info中的host, port等信息，鏈接compute節點上的VNC Server，從而開始了proxy的工做

 

6. 若是VNC登陸不進去，還有一個方法，使用本身的VNC Client，經過compute物理節點的IP地址登錄

qemu-system-x86_64 有參數 -vnc 0.0.0.0:5

 

就能夠經過compute node的ip地址進入

 

 

7. 經過ovs-vsctl show和brctl來查看，各個網卡和bridge之間關係是否正確，tunnel之間是否可以通，網卡是否都處於up的狀態

 

 

 

8. 若是從虛擬機的虛擬網卡到DHCP Server的網卡一路都是配置正確的，則須要查看br-tun上ovs-ofctl dumpflows查看flows規則，是否對包的改寫正確，是否有正確的規則

 

9. 經過VNC登陸進去後，就能夠經過命令行運行dhclient，來重啓鏈接DHCP Server, 從compute節點上的網卡和bridge，一個個進行tcpdump，看到底哪一個網卡或者bridge沒有收到包，收到的包裏面的VLAN ID等是否正確

 

10. 若是VM能從DHCP Server得到IP，則好事成了一半，接下來換一個有cloud-init的image，看metadata server可以鏈接成功，可以注入key，也是經過console.log來看

 

11. 若是metadata server不能鏈接成功，就須要順着metadata server的整個流程，一個一個模塊看，看每一個模塊的log，端口是否正確，是否收到請求，也能夠在VM裏面用curl來模擬metadata server的請求

 

 

openstack裏的metadata，是提供一個機制給用戶，能夠設定每個instance 的參數。好比你想給instance設置某個屬性，好比主機名。

 

Instance訪問metadata server http://169.254.169.254

 

metadata的一個重要應用，是設置每一個instance的ssh公鑰。

 

獲取metadata的api接口是：

 

http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key 

 

這個IP地址，在 openstack 是不存在的。爲何能夠獲取到metadata呢？

 

這是因爲Amazon的緣由，最先metadata是亞馬遜提出來的，參見：http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html

 

後來不少人給亞馬遜定製了一些操做系統的鏡像，好比 ubuntu, fedora, centos 等等，並且將裏面獲取 metadta 的api地址也寫死了。因此opentack爲了兼容，保留了這個地址169.254.169.254。

 

而後經過iptables nat映射到真實的api上：

 

iptables -A nova-network-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 16.158.166.197:8775 

 

nova如何區分究竟是哪一個虛擬機請求metadata？採起的方法是在HTTP頭部識別是哪一個虛擬機。

 

 

 

一個虛擬機訪問169.254.169.254的流程以下：

 

(1) 虛擬機發出請求

 

• 虛擬機啓動時會訪問169.254.169.254

• 數據包會直接發送到虛擬機的默認網關172.71.71.1

• 默認網關在network node上，qr-XXXXX

 

(2) namespace中的iptables

 

• 由於使用了namespace，在network node上每一個namespace裏都會有相應的iptables規則和網絡設備。

• iptables規則中，會把目的地址169.254.169.254的數據包，重定向到本地端口9697

 

ip netns exec qrouter-5a74908c-712c-485c-aa9f-6c1e8b57e3e1 iptables -t nat -nvL

 

(3) namespace-metadata-proxy

 

啓用namespace場景下，對於每個router，都會建立這樣一個進程。該進程監聽9697端口，其主要功能：

 

一、向請求頭部添加X-Forwarded-For和X-Neutron-Router-ID，分別表示虛擬機的fixedIP和router的ID

二、將請求代理至Unix domain socket（/var/lib/neutron/metadata_proxy）

 

 

(4) Neutron-metadata-agent

 

• network node上的metadata agent監聽/var/lib/neutron/metadata_proxy：

• 該進程的功能是，根據請求頭部的X-Forwarded-For和X-Neutron-Router-ID參數，向Neutron service查詢虛擬機ID，而後向Nova Metadata服務發送請求（默認端口8775），消息頭：X-Forwarded-For，X-Instance-ID、X-Instance- ID-Signature分別表示虛擬機的fixedIP，虛擬機ID和虛擬機ID的簽名。

 

 

12. 若是metadata server可以鏈接成功，key成功注入，下一步須要從namespace裏面看是否可以ping通，可以ssh

 

 

13. 若是namespace裏面可以成功，則在network節點上，ping floating ip和ssh，是否可以成功，若是不成功，看br-ex的網卡是否添加正確，是否配置了ip，路由表是否正確，namespace裏面floating ip的iptables規則是否添加正確

 

14. 在network節點上可以ssh到floating ip，則須要從其餘節點上ssh，若是不成功，可能br-ex的網址配置有問題，極可能是br-ex添加的物理網卡不是混合狀態，也多是路由配置有問題，對於floating ip所在的網段，不指向network節點

 

15. 若是floating ip可以成功，則須要進去VM裏面運行apt-get update，若是不能夠，看可否ping通openstack裏面的gateway(10.0.0.1)，而後看可否ping通物理網絡環境的gateway(16.158.XXX.1)

 

16. 看DNS Server是否配置正確，是否可以ping通，若是能，apt-get update運行成功

 

（轉載）