OpenStack Metadata Service分析

一、爲何Metadata Service

OpenStack Metadata Service 提供 instance 的配置信息（這些信息被統稱爲 metadata）。instance 啓動時向 Metadata Service 請求並得到本身的 metadata，instance 的 cloud-init根據 metadata 完成個性化配置工做。

二、Metadata Service架構

nova-api-metadata

nova-api-metadata是nova-api的子服務，它是metadata的實際提供者，虛擬機的啓動時，能夠選擇經過nova-api-metadata的REST API來獲取metadata信息
nova-api-metadata服務運行在控制節點上，服務端口8775(能夠經過nova的配置修改)

開啓metadata服務

nova-api-metadata與nova-api服務是合併在一塊兒的，能夠經過nova.conf的enabled_apis配置來指定是否啓用nova-api-metadata

neutron-metadata-agent

nova-api-metadata走管理網絡，虛擬機走業務網絡，因此虛擬機沒法直接和nova-api-metadata進行通訊，在這個時候就須要藉助到運行在網絡節點上的neutron-metadata-agent服務。

在網絡節點上運行兩個組件 l3 agent和dhcp agent，他們會建立一個haproxy進程，運行在各自的namespace中，用來接收虛擬機發送的metadata請求，並將該請求經過Unix Domain Socket的方式轉發給neutron-metadata-agent服務，再由neutron-metadata-agent轉發給nova-api-metadata。

整個流程能夠總結爲：
a、instance將metadata請求發送給router或者dhcp agent建立的haproxy進程
b、haproxy進程經過Unix Domian Socket將請求發送給neutron-metadata-agent
c、neutron-metadata經過內部管理網絡將請求發送給nova-api-metadata服務

三、L3 agent or DHCP agent

上述描述中提到，L3 agent和dhcp agent都可以建立haproxy進程，進而實現metadata請求的轉發，那麼兩種方案該如何選擇呢？

事實上，二者各有各的應用場景，甚至兩種方案能夠並存，下文將詳細分析二者的區別。
說在前面，l3-agent 和 dhcp-agent 訪問 metadata 的實現方法是不一樣的。

對於 169.254.169.254：
a、l3-agent 用 iptables 規則來轉發。
b、dhcp-agent 則是將此 IP 配置到本身的 interface 上。

四、L3 agent實現分析

建立一個網絡test1，啓用dhcp，暫時不鏈接到router，而後啓動一個instance，而後觀察instance的啓動日誌：

從上面的啓動log中，咱們能夠發現，intance從dhcp獲取到ip地址以後，向169.254.169.254發送了request請求，可是20次均失敗
那麼169.254.169.254究竟是什麼？

事實上，這個ip地址就是metadata service的ip地址，instance在啓動的時候會向它發送metadata的請求。

如今咱們發現，instance請求是失敗的，這個是爲何呢？

上文提到，OpenStack經過L3 agent或者dhcp agent建立haproxy進程，進而實現metadata的轉發，咱們首先檢查下網絡節點上的haproxy進程。

發現並無haproxy進程運行，這個也就解釋了，爲何instance會請求失敗。可是究竟是哪裏出了問題？

根本緣由是：默認狀況下，haproxy進程由L3 agent來建立（dhcp agent則是關閉狀態），因爲當前test1網絡並無掛載router上，因此沒有建立haproxy進程。

建立router，並將test1掛載router上以後。咱們發現haproxy進程已經在網絡節點啓動。

重啓instance test1，看會發生什麼變化。

根據instance日誌顯示，虛擬機已經成功從169.254.169.254獲取到了metadata。
這個過程當中到底發生了什麼？

a、instance在啓動以後，會向168.254.169.254的80端口發起metadata請求，根據
instance的路由能夠發現，該請求會從instance的eth0發出，送往路由器上的qr-設備。

b、metadata請求到達路由，進入PREROUTING鏈，將目的地址爲169.254.169.254，進入qr-口，目的port是80的請求，重定向到9697。

c、爲何是9697？
由於router建立的haproxy進程正是監聽在9697端口上

d、在後面就簡單了：haproxy進程將請求經過Unix Domain Socket轉發給neutron-metadata-agent，後者再經過管理網關轉發給nova-api-metadata。

五、DHCP agent實現分析

OpenStack默認經過L3 agent管理metadata的實現，進而和nova-api-metadata通訊，可是並非全部的環境都有L3 agent，好比直接使用物理router的場景，這樣場景如何實現metadata呢？

答案就是DHCP agent

a、打開dhcp agent的metadata功能
vim /etc/neutron/dhcp_agent.ini

重啓dchp agent服務

b、檢查網絡節點上的haproxy進程狀況，會發現開啓dhcp功能的網絡，會建立一個對應的haproxy進程，並將169.254.169.254配置在對應的dhcp port上。

c、重啓instance，instance會向169.254.169.254的80端口發送metadata請求，根據instance內部路由，請求會到達dhcp_port端口上。

c、metadata請求到達dhcp的namespace，會被haproxy進程監聽到（haproxy進程在dhcp namespace中監聽80端口）

d、後面流程和L3 agent徹底相同：haproxy進程將請求經過Unix Domain Socket轉發給neutron-metadata-agent，後者再經過管理網關轉發給nova-api-metadata。

六、Instance 怎麼得到本身的 Metadata

要從 nova-api-metadata 得到 metadata，須要指定 instance 的 id
而instance在啓動的時候，是沒法知道本身的id的，因此http請求中不會包含id，
instance id是neutron-metadata-agent添加進去的。對於L3 agent和DHCP agent
兩種方案上實現又略有不一樣，下文會針對二者進行說明。

獲取metadata流程以下：
instance -> haproxy-> neutron-metadata-agent -> nova-api-metadata

L3 agent
a、haproxy進程接受到metadata請求，在轉發給neutron-metadata-agent以前，會將ip和router id添加到http的head中。
b、neutron-metadata-agent接受到請求後，會查詢instance的id，而後將instance id添加到http的head中，而後轉發給nova-api-metadata。
c、nova-api-metadata響應請求到指定的instance。

DHCP agent
a、haproxy進程接受到metadata請求，在轉發給neutron-metadata-agent以前，會將ip和network id添加到http的head中。
b、neutron-metadata-agent接受到請求後，會查詢instance的id，而後將instance id添加到http的head中，而後轉發給nova-api-metadata。
c、nova-api-metadata響應請求到指定的instance。

這樣，無論 instance 將請求發給 l3-agent 仍是 dhcp-agent，nova-api-metadata 最終都能獲知 instance 的 id，進而返回正確的 metadata。