Metadata Service 架構詳解 - 天天5分鐘玩轉 OpenStack（165）

 下面是 Metadata Service 的架構圖，本節咱們詳細討論各個組件以及它們之間的關係。

 

 

nova-api-metadata

 

nova-api-metadata 是 nova-api 的一個子服務，它是 metadata 的提供者，instance 能夠經過 nova-api-metadata 的 REST API 來獲取 metadata 信息。

nova-api-metadata 運行在控制節點上，服務端口是 8775。
 

經過進程 ID 13415 查看該啓動程序。
 

咱們這個環境是 devstack，nova-api-metadata 的程序名稱就是 nova-api，nova-api-metadata 與常規的 nova-api 服務是合併在一塊兒的。不過在 OpenStack 的其餘發行版中可能有單獨的 nova-api-metadata 進程存在。

nova.conf 經過參數 enabled_apis 指定是否啓用 nova-api-metadata。
 

osapi_compute 是常規的 nova-api 服務，metadata 就是 nova-api-metadata 服務。
 

neutron-metadata-agent

nova-api-metadata 在控制節點上，走 OpenStack 內部管理網絡，instance 是沒法經過 http://controller_ip:8775 直接訪問 metadata service 的，由於網絡不通。

那怎麼辦呢？

答案是：藉助 neutron-metadata-agent。

neutron-metadata-agent 運行在網絡節點上。instance 先將 metadata 請求發給 neutron-metadata-agent，neutron-metadata-agent 再將請求轉發到 nova-api-metadata。
 

這裏還有個問題須要解釋清楚：instance 如何將請求發送到 neutron-metadata-agent？

實際上 instance 是不能直接與 neutron-metadata-agent 通訊的，由於 neutron-metadata-agent 也是在 OpenStack 內部管理網絡上的。不過好在網絡節點上有另外兩個組件，dhcp agent 和 l3 agent，它們兩兄弟與 instance 能夠位於同一 OpenStack network 中，這樣就引出了下一個組件： neutron-ns-metadata-proxy。
 

neutron-ns-metadata-proxy

 

neutron-ns-metadata-proxy 是由 dhcp-agent 或者 l3-agent 建立的，也運行在網絡節點。更精確的說法是：運行在網絡節點的 namespace 中。

若是由 dhcp-agent 建立，neutron-ns-metadata-proxy 就運行在 dhcp-agent 所在的 namespace 中；若是由 l3-agent 建立，neutron-ns-metadata-proxy 就運行在 neutron router 所在的 namespace 中。「neutron-ns-metadata-proxy」 中間的 ns 就是 namespace 的意思。neutron-ns-metadata-proxy 與 neutron-metadata-agent 經過 unix domain socket 直接相連。
 

這樣整個鏈路就打通了：

1. instance 經過 neutron network（Project 網絡）將 metadata 請求發送到 neutron-ns-metadata-proxy。

2. neutron-ns-metadata-proxy 經過 unix domain socket 將請求發給 neutron-metadata-agent。

3. neutron-metadata-agent 經過內部管理網絡將請求發送給 nova-api-metadata。

可能你們對於 neutron-ns-metadata-proxy 還會有些疑慮：既然 dhcp-agent 和 l3-agent 均可以建立和管理 neutron-ns-metadata-proxy，使用的時候該如何選擇呢？

簡單的說：各有各的使用場景，而且兩種方案能夠共存。你們不用擔憂，後面咱們會經過例子詳細討論。

Metadata Service 的架構已經討論清楚了，下一節將經過實踐加深理解。