如何理解Metadata Service 架構

這期內容當中小編將會給大家帶來有關如何理解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 架構了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。