OpenStack Metadata Service分析

1、為什么Metadata Service

OpenStack Metadata Service 提供 instance 的配置信息（這些信息被統(tǒng)稱為 metadata）。instance 啟動時向 Metadata Service 請求并獲得自己的 metadata，instance 的 cloud-init根據(jù) metadata 完成個性化配置工作。

2、Metadata Service架構(gòu)

nova-api-metadata

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

開啟metadata服務(wù)

nova-api-metadata與nova-api服務(wù)是合并在一起的，可以通過nova.conf的enabled_apis配置來指定是否啟用nova-api-metadata

neutron-metadata-agent

nova-api-metadata走管理網(wǎng)絡(luò)，虛擬機走業(yè)務(wù)網(wǎng)絡(luò)，所以虛擬機無法直接和nova-api-metadata進行通信，在這個時候就需要借助到運行在網(wǎng)絡(luò)節(jié)點上的neutron-metadata-agent服務(wù)。

在網(wǎng)絡(luò)節(jié)點上運行兩個組件 l3 agent和dhcp agent，他們會創(chuàng)建一個haproxy進程，運行在各自的namespace中，用來接收虛擬機發(fā)送的metadata請求，并將該請求通過Unix Domain Socket的方式轉(zhuǎn)發(fā)給neutron-metadata-agent服務(wù)，再由neutron-metadata-agent轉(zhuǎn)發(fā)給nova-api-metadata。

整個流程可以總結(jié)為：
a、instance將metadata請求發(fā)送給router或者dhcp agent創(chuàng)建的haproxy進程
b、haproxy進程通過Unix Domian Socket將請求發(fā)送給neutron-metadata-agent
c、neutron-metadata通過內(nèi)部管理網(wǎng)絡(luò)將請求發(fā)送給nova-api-metadata服務(wù)

3、L3 agent or DHCP agent

上述描述中提到，L3 agent和dhcp agent均可以創(chuàng)建haproxy進程，進而實現(xiàn)metadata請求的轉(zhuǎn)發(fā)，那么兩種方案該如何選擇呢？

事實上，兩者各有各的應(yīng)用場景，甚至兩種方案可以并存，下文將詳細分析兩者的區(qū)別。
說在前面，l3-agent 和 dhcp-agent 訪問 metadata 的實現(xiàn)方法是不同的。

對于 169.254.169.254：
a、l3-agent 用 iptables 規(guī)則來轉(zhuǎn)發(fā)。
b、dhcp-agent 則是將此 IP 配置到自己的 interface 上。

4、L3 agent實現(xiàn)分析

創(chuàng)建一個網(wǎng)絡(luò)test1，啟用dhcp，暫時不連接到router，然后啟動一個instance，然后觀察instance的啟動日志：

從上面的啟動log中，我們可以發(fā)現(xiàn)，intance從dhcp獲取到ip地址之后，向169.254.169.254發(fā)送了request請求，但是20次均失敗
那么169.254.169.254到底是什么？

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

現(xiàn)在我們發(fā)現(xiàn)，instance請求是失敗的，這個是為什么呢？

上文提到，OpenStack通過L3 agent或者dhcp agent創(chuàng)建haproxy進程，進而實現(xiàn)metadata的轉(zhuǎn)發(fā)，我們首先檢查下網(wǎng)絡(luò)節(jié)點上的haproxy進程。

發(fā)現(xiàn)并沒有haproxy進程運行，這個也就解釋了，為什么instance會請求失敗。但是到底是哪里出了問題？

根本原因是：默認情況下，haproxy進程由L3 agent來創(chuàng)建（dhcp agent則是關(guān)閉狀態(tài)），由于當前test1網(wǎng)絡(luò)并沒有掛載router上，所以沒有創(chuàng)建haproxy進程。

創(chuàng)建router，并將test1掛載router上之后。我們發(fā)現(xiàn)haproxy進程已經(jīng)在網(wǎng)絡(luò)節(jié)點啟動。

重啟instance test1，看會發(fā)生什么變化。

根據(jù)instance日志顯示，虛擬機已經(jīng)成功從169.254.169.254獲取到了metadata。
這個過程中到底發(fā)生了什么？

a、instance在啟動之后，會向168.254.169.254的80端口發(fā)起metadata請求，根據(jù)
instance的路由可以發(fā)現(xiàn)，該請求會從instance的eth0發(fā)出，送往路由器上的qr-設(shè)備。

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

c、為什么是9697？
因為router創(chuàng)建的haproxy進程正是監(jiān)聽在9697端口上

d、在后面就簡單了：haproxy進程將請求通過Unix Domain Socket轉(zhuǎn)發(fā)給neutron-metadata-agent，后者再通過管理網(wǎng)關(guān)轉(zhuǎn)發(fā)給nova-api-metadata。

5、DHCP agent實現(xiàn)分析

OpenStack默認通過L3 agent管理metadata的實現(xiàn)，進而和nova-api-metadata通信，但是并不是所有的環(huán)境都有L3 agent，比如直接使用物理router的場景，這樣場景如何實現(xiàn)metadata呢？

答案就是DHCP agent

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

重啟dchp agent服務(wù)

b、檢查網(wǎng)絡(luò)節(jié)點上的haproxy進程情況，會發(fā)現(xiàn)開啟dhcp功能的網(wǎng)絡(luò)，會創(chuàng)建一個對應(yīng)的haproxy進程，并將169.254.169.254配置在對應(yīng)的dhcp port上。

c、重啟instance，instance會向169.254.169.254的80端口發(fā)送metadata請求，根據(jù)instance內(nèi)部路由，請求會到達dhcp_port端口上。

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

d、后面流程和L3 agent完全相同：haproxy進程將請求通過Unix Domain Socket轉(zhuǎn)發(fā)給neutron-metadata-agent，后者再通過管理網(wǎng)關(guān)轉(zhuǎn)發(fā)給nova-api-metadata。

6、Instance 怎么獲得自己的 Metadata

要從 nova-api-metadata 獲得 metadata，需要指定 instance 的 id
而instance在啟動的時候，是無法知道自己的id的，所以http請求中不會包含id，
instance id是neutron-metadata-agent添加進去的。對于L3 agent和DHCP agent
兩種方案上實現(xiàn)又略有不同，下文會針對兩者進行說明。

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

L3 agent
a、haproxy進程接受到metadata請求，在轉(zhuǎn)發(fā)給neutron-metadata-agent之前，會將ip和router id添加到http的head中。
b、neutron-metadata-agent接受到請求后，會查詢instance的id，然后將instance id添加到http的head中，然后轉(zhuǎn)發(fā)給nova-api-metadata。
c、nova-api-metadata響應(yīng)請求到指定的instance。

DHCP agent
a、haproxy進程接受到metadata請求，在轉(zhuǎn)發(fā)給neutron-metadata-agent之前，會將ip和network id添加到http的head中。
b、neutron-metadata-agent接受到請求后，會查詢instance的id，然后將instance id添加到http的head中，然后轉(zhuǎn)發(fā)給nova-api-metadata。
c、nova-api-metadata響應(yīng)請求到指定的instance。

這樣，不管 instance 將請求發(fā)給 l3-agent 還是 dhcp-agent，nova-api-metadata 最終都能獲知 instance 的 id，進而返回正確的 metadata。