Openstack的Metadata的做用

無論理是私有云與公有云，特別是公有云，在建立虛擬機時，用戶須要對虛擬機進行配置，好比：主機名（hostname）、密鑰、服務等，在 OpenStack 中，這些配置信息被分紅兩類：metadata 和 user data。Metadata 主要包括虛擬機自身的一些經常使用屬性，如 hostname、網絡配置信息、SSH 登錄祕鑰等，主要的形式爲鍵值對。而 user data 主要包括一些命令、腳本等。User data 經過文件傳遞，並支持多種文件格式，包括 gzip 壓縮文件、shell 腳本、cloud-init 配置文件等。雖然 metadata 和 user data 並不相同，可是 OpenStack 向虛擬機提供這兩種信息的機制是一致的，只是虛擬機在獲取到信息後，對二者的處理方式不一樣罷了。因此下文統一用 matadata 來描述。

一.user data機制：

1）在定製腳本源的下拉列表中，能夠選擇直接輸入或可執行腳本文件，此例是對Ubuntu的鏡像在加載爲操做系統時把Ubuntu默認用戶的密碼修改成ubuntu，可做爲在沒有辦法使用SSH帶上Key鏈接此虛擬主機時，使用Console的方式操做虛擬主機場景

2）如Centos或redhat，能夠直接使用root用戶，設置密碼：

二.Metadata機制

在 OpenStack 中，虛擬機獲取 Metadata 信息的方式有兩種：Config drive 和 metadata RESTful 服務。下面咱們只對Metadata介紹與分析。

Metadata RESTful 服務

OpenStack 提供了 RESTful 接口，虛擬機能夠經過 REST API 來獲取 metadata 信息。提供該服務的組件爲：nova-api-metadata。固然，要完成從虛擬機至網絡節點的請求發送和相應，只有 nova-api-metadata 服務是不夠的，此外共同完成這項任務的服務還有：Neutron-metadata-agent 和 Neutron-ns-metadata-proxy。下面咱們將剖析它們是如何協同工做爲虛擬機提供 metadata 服務的。

Neutron-metadata-agent

Neutron-metadata-agent 運行在網絡節點，負責將接收到的獲取 metadata 的請求轉發給 nova-api-metadata。Neutron-metadata-agent 會獲取虛擬機和租戶的 ID，添加到請求的 HTTP 頭部中。nova-api-metadata 會根據這些信息獲取 metadata。

Nova-api-metadata

nova-api-metadata 啓動了 RESTful 服務，負責處理虛擬機發送來的 REST API 請求。從請求的 HTTP 頭部中取出相應的信息，得到虛擬機的 ID，繼而從數據庫中讀取虛擬機的 metadata 信息，最後將結果返回。

Neutron-ns-metadata-proxy

Neutron-ns-metadata-proxy 也運行在網絡節點。爲了解決網絡節點的網段和租戶的虛擬網段重複的問題，OpenStack 引入了網絡命名空間。Neutron 中的路由和 DHCP 服務器都在各自獨立的命名空間中。因爲虛擬機獲取 metadata 的請求都是以路由和 DHCP 服務器做爲網絡出口，因此須要經過 neutron-ns-metadata-proxy 聯通不一樣的網絡命名空間，將請求在網絡命名空間之間轉發。Neutron-ns-metadata-proxy 利用在 unix domain socket 之上的 HTTP 技術，實現了不一樣網絡命名空間之間的 HTTP 請求轉發。並在請求頭中添加’X-Neutron-Router-ID’和’X-Neutron-Network-ID’信息，以便 Neutron-metadata-agent 來辨別發送請求的虛擬機，獲取虛擬機的 ID。

圖 3.Metadata 請求發送流程

如圖 3 所示，虛擬機獲取 metadata 的大體流程爲：首先請求被髮送至 neutron-ns-metadata-proxy，此時會在請求中添加 router-id 和 network-id，而後請求經過 unix domian socket 被轉發給 neutron-metadata-agent，根據請求中的 router-id、network-id 和 IP，獲取 port 信息，從而拿到 instance-id 和 tenant-id 加入請求中，最後請求被轉發給 nova-api-metadata，其利用 instance-id 和 tenant-id 獲取虛擬機的 metadata，返回相應。

上面咱們分析了各個服務之間轉發請求的流程，那麼如今只存在一個問題，整個獲取 metadata 的路線就通暢了：虛擬機如何將請求發送至 neutron-ns-metadata-proxy？

咱們首先來分析虛擬機發送的請求。因爲 metadata 最先是由亞馬遜提出的，當時規定 metadata 服務的地址爲 169.254.169.254:80，OpenStack 沿用了這一規定。因此虛擬機會向 169.254.169.254:80 發送 medtadata 請求。那麼這一請求是如何從虛擬機中發送出來的呢？目前 Neutron 有兩種方式來解決這個問題：經過 router 發送請求和經過 DHCP 發送請求。

經過 router 發送請求

若是虛擬機所在 subnet 鏈接在了 router 上，那麼發向 169.254.169.254 的報文會被髮至 router。如圖 4 所示，Neutron 經過在 router 所在網絡命名空間添加 iptables 規則，將該報文轉發至 9697 端口，而 neutron-ns-metadata-proxy 監聽着該端口，因此報文被 neutron-ns-metadata-proxy 獲取，進入上述後續處理和轉發流程。

圖4.router 所在網絡命名空間的 iptables 規則

圖 5.監聽在 9697 端口上的 Neutron-ns-metadata-proxy 服務

上圖圈紅圈的是在單獨一個網絡命名空間查看，下面能夠看到有三個網絡命名空間，與圖4的qrouter相同

經過 DHCP 發送請求

若是虛擬機所在 subnet 沒有鏈接在任何 router 上，那麼請求則沒法經過 router 轉發。此時 Neutron 經過 DHCP 服務器來轉發 metadata 請求。DHCP 服務經過 DHCP 協議的選項 121 來爲虛擬機設置靜態路由。如圖 6 所示，圖中 10.0.0.3 爲 DHCP 服務器的 IP 地址。經過查看虛擬機的靜態路由表，咱們能夠發現發送至 169.254.169.254 的報文被髮送到了 10.0.0.3，即 DHCP 服務器。

圖 6.虛擬機中的靜態路由表

另外再查看 DHCP 服務器的 IP 配置信息，發現 DHCP 服務器配置了兩個 IP，其中一個就是 169.254.169.254。與 router 相似的，Neutron 在 DHCP 網絡命名空間中啓動了監聽 80 端口的 neutron-ns-metadata-proxy 服務，從而進入處理和轉發請求的流程。

圖 7.DHCP 服務器的 IP 配置

圖8.檢查Metadata的服務是否正常

此圖表示正常

總結：要保證虛擬主機與Metadata服務正常通信，首先鏡像須要安裝cloud-init,固然各個服務也正常了，常常會出現l鏈接不上metadata服務，一般虛擬主機的端口不正常，這時可使用重建來排除故障，上圖的metadata-dhcp的主機名就是在建立虛擬主機時定義，還有key生效都必須保證cloud-init的存在，如圖：

可參考網址：http://www.ibm.com/developerworks/cn/cloud/library/1509_liukg_openstackmeta/index.html