OpenStack Metadata Service 提供 instance 的配置信息（這些信息被統(tǒng)稱為 metadata）。instance 啟動(dòng)時(shí)向 Metadata Service 請(qǐng)求并獲得自己的 metadata，instance 的 cloud-init根據(jù) metadata 完成個(gè)性化配置工作。
nova-api-metadata
nova-api-metadata是nova-api的子服務(wù)，它是metadata的實(shí)際提供者，虛擬機(jī)的啟動(dòng)時(shí)，可以選擇通過(guò)nova-api-metadata的REST API來(lái)獲取metadata信息
nova-api-metadata服務(wù)運(yùn)行在控制節(jié)點(diǎn)上，服務(wù)端口8775(可以通過(guò)nova的配置修改)
開啟metadata服務(wù)
nova-api-metadata與nova-api服務(wù)是合并在一起的，可以通過(guò)nova.conf的enabled_apis配置來(lái)指定是否啟用nova-api-metadata
neutron-metadata-agent
nova-api-metadata走管理網(wǎng)絡(luò)，虛擬機(jī)走業(yè)務(wù)網(wǎng)絡(luò)，所以虛擬機(jī)無(wú)法直接和nova-api-metadata進(jìn)行通信，在這個(gè)時(shí)候就需要借助到運(yùn)行在網(wǎng)絡(luò)節(jié)點(diǎn)上的neutron-metadata-agent服務(wù)。
在網(wǎng)絡(luò)節(jié)點(diǎn)上運(yùn)行兩個(gè)組件 l3 agent和dhcp agent，他們會(huì)創(chuàng)建一個(gè)haproxy進(jìn)程，運(yùn)行在各自的namespace中，用來(lái)接收虛擬機(jī)發(fā)送的metadata請(qǐng)求，并將該請(qǐng)求通過(guò)Unix Domain Socket的方式轉(zhuǎn)發(fā)給neutron-metadata-agent服務(wù)，再由neutron-metadata-agent轉(zhuǎn)發(fā)給nova-api-metadata。
整個(gè)流程可以總結(jié)為：
a、instance將metadata請(qǐng)求發(fā)送給router或者dhcp agent創(chuàng)建的haproxy進(jìn)程
b、haproxy進(jìn)程通過(guò)Unix Domian Socket將請(qǐng)求發(fā)送給neutron-metadata-agent
c、neutron-metadata通過(guò)內(nèi)部管理網(wǎng)絡(luò)將請(qǐng)求發(fā)送給nova-api-metadata服務(wù)
上述描述中提到，L3 agent和dhcp agent均可以創(chuàng)建haproxy進(jìn)程，進(jìn)而實(shí)現(xiàn)metadata請(qǐng)求的轉(zhuǎn)發(fā)，那么兩種方案該如何選擇呢？
事實(shí)上，兩者各有各的應(yīng)用場(chǎng)景，甚至兩種方案可以并存，下文將詳細(xì)分析兩者的區(qū)別。
說(shuō)在前面，l3-agent 和 dhcp-agent 訪問 metadata 的實(shí)現(xiàn)方法是不同的。
對(duì)于 169.254.169.254：
a、l3-agent 用 iptables 規(guī)則來(lái)轉(zhuǎn)發(fā)。
b、dhcp-agent 則是將此 IP 配置到自己的 interface 上。
創(chuàng)建一個(gè)網(wǎng)絡(luò)test1，啟用dhcp，暫時(shí)不連接到router，然后啟動(dòng)一個(gè)instance，然后觀察instance的啟動(dòng)日志：
從上面的啟動(dòng)log中，我們可以發(fā)現(xiàn)，intance從dhcp獲取到ip地址之后，向169.254.169.254發(fā)送了request請(qǐng)求，但是20次均失敗
那么169.254.169.254到底是什么？
事實(shí)上，這個(gè)ip地址就是metadata service的ip地址，instance在啟動(dòng)的時(shí)候會(huì)向它發(fā)送metadata的請(qǐng)求。
現(xiàn)在我們發(fā)現(xiàn)，instance請(qǐng)求是失敗的，這個(gè)是為什么呢？
上文提到，OpenStack通過(guò)L3 agent或者dhcp agent創(chuàng)建haproxy進(jìn)程，進(jìn)而實(shí)現(xiàn)metadata的轉(zhuǎn)發(fā)，我們首先檢查下網(wǎng)絡(luò)節(jié)點(diǎn)上的haproxy進(jìn)程。
發(fā)現(xiàn)并沒有haproxy進(jìn)程運(yùn)行，這個(gè)也就解釋了，為什么instance會(huì)請(qǐng)求失敗。但是到底是哪里出了問題？
根本原因是：默認(rèn)情況下，haproxy進(jìn)程由L3 agent來(lái)創(chuàng)建（dhcp agent則是關(guān)閉狀態(tài)），由于當(dāng)前test1網(wǎng)絡(luò)并沒有掛載router上，所以沒有創(chuàng)建haproxy進(jìn)程。
創(chuàng)建router，并將test1掛載router上之后。我們發(fā)現(xiàn)haproxy進(jìn)程已經(jīng)在網(wǎng)絡(luò)節(jié)點(diǎn)啟動(dòng)。
重啟instance test1，看會(huì)發(fā)生什么變化。
根據(jù)instance日志顯示，虛擬機(jī)已經(jīng)成功從169.254.169.254獲取到了metadata。
這個(gè)過(guò)程中到底發(fā)生了什么？
a、instance在啟動(dòng)之后，會(huì)向168.254.169.254的80端口發(fā)起metadata請(qǐng)求，根據(jù)
instance的路由可以發(fā)現(xiàn)，該請(qǐng)求會(huì)從instance的eth0發(fā)出，送往路由器上的qr-設(shè)備。
b、metadata請(qǐng)求到達(dá)路由，進(jìn)入PREROUTING鏈，將目的地址為169.254.169.254，進(jìn)入qr-口，目的port是80的請(qǐng)求，重定向到9697。
c、為什么是9697？
因?yàn)閞outer創(chuàng)建的haproxy進(jìn)程正是監(jiān)聽在9697端口上
d、在后面就簡(jiǎn)單了：haproxy進(jìn)程將請(qǐng)求通過(guò)Unix Domain Socket轉(zhuǎn)發(fā)給neutron-metadata-agent，后者再通過(guò)管理網(wǎng)關(guān)轉(zhuǎn)發(fā)給nova-api-metadata。
OpenStack默認(rèn)通過(guò)L3 agent管理metadata的實(shí)現(xiàn)，進(jìn)而和nova-api-metadata通信，但是并不是所有的環(huán)境都有L3 agent，比如直接使用物理router的場(chǎng)景，這樣場(chǎng)景如何實(shí)現(xiàn)metadata呢？
答案就是DHCP agent
a、打開dhcp agent的metadata功能
vim /etc/neutron/dhcp_agent.ini
重啟dchp agent服務(wù)
b、檢查網(wǎng)絡(luò)節(jié)點(diǎn)上的haproxy進(jìn)程情況，會(huì)發(fā)現(xiàn)開啟dhcp功能的網(wǎng)絡(luò)，會(huì)創(chuàng)建一個(gè)對(duì)應(yīng)的haproxy進(jìn)程，并將169.254.169.254配置在對(duì)應(yīng)的dhcp port上。
c、重啟instance，instance會(huì)向169.254.169.254的80端口發(fā)送metadata請(qǐng)求，根據(jù)instance內(nèi)部路由，請(qǐng)求會(huì)到達(dá)dhcp_port端口上。
c、metadata請(qǐng)求到達(dá)dhcp的namespace，會(huì)被haproxy進(jìn)程監(jiān)聽到（haproxy進(jìn)程在dhcp namespace中監(jiān)聽80端口）
d、后面流程和L3 agent完全相同：haproxy進(jìn)程將請(qǐng)求通過(guò)Unix Domain Socket轉(zhuǎn)發(fā)給neutron-metadata-agent，后者再通過(guò)管理網(wǎng)關(guān)轉(zhuǎn)發(fā)給nova-api-metadata。
要從 nova-api-metadata 獲得 metadata，需要指定 instance 的 id
而instance在啟動(dòng)的時(shí)候，是無(wú)法知道自己的id的，所以http請(qǐng)求中不會(huì)包含id，
instance id是neutron-metadata-agent添加進(jìn)去的。對(duì)于L3 agent和DHCP agent
兩種方案上實(shí)現(xiàn)又略有不同，下文會(huì)針對(duì)兩者進(jìn)行說(shuō)明。
獲取metadata流程如下：
instance -> haproxy-> neutron-metadata-agent -> nova-api-metadata
L3 agent
a、haproxy進(jìn)程接受到metadata請(qǐng)求，在轉(zhuǎn)發(fā)給neutron-metadata-agent之前，會(huì)將ip和router id添加到http的head中。
b、neutron-metadata-agent接受到請(qǐng)求后，會(huì)查詢instance的id，然后將instance id添加到http的head中，然后轉(zhuǎn)發(fā)給nova-api-metadata。
c、nova-api-metadata響應(yīng)請(qǐng)求到指定的instance。
DHCP agent
a、haproxy進(jìn)程接受到metadata請(qǐng)求，在轉(zhuǎn)發(fā)給neutron-metadata-agent之前，會(huì)將ip和network id添加到http的head中。
b、neutron-metadata-agent接受到請(qǐng)求后，會(huì)查詢instance的id，然后將instance id添加到http的head中，然后轉(zhuǎn)發(fā)給nova-api-metadata。
c、nova-api-metadata響應(yīng)請(qǐng)求到指定的instance。
這樣，不管 instance 將請(qǐng)求發(fā)給 l3-agent 還是 dhcp-agent，nova-api-metadata 最終都能獲知 instance 的 id，進(jìn)而返回正確的 metadata。
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。
重慶分公司
重慶分公司
