建站
咨詢
售后
建站咨詢
新聞中心
在云計算中，Metadata 并不是一個陌生的概念。從字面上看，Metadata 是元數(shù)據(jù)的意思。而在云計算中，Metadata 服務能夠向虛機注入一些額外的信息，這樣虛機在創(chuàng)建之后可以有一些定制化的配置。在 OpenStack 中，Metadata 服務能夠向虛機提供主機名，ssh 公鑰，用戶傳入的一些定制數(shù)據(jù)等其他信息。這些數(shù)據(jù)被分為兩類：metadata和user data，metadata主要包括虛機自身的一些數(shù)據(jù)比如hostname、ssh秘鑰、網(wǎng)絡配置等，而user data主要包括一些定制的腳本、命令等。但是不管是哪一種數(shù)據(jù)，openstack向虛機提供數(shù)據(jù)的方式是一致的。
龍南網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、APP開發(fā)、自適應網(wǎng)站建設等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)建站從2013年開始到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設就選創(chuàng)新互聯(lián)建站。
Metadata 的獲取機制
在 OpenStack 中，虛擬機獲取 Metadata 信息的方式有兩種：Config drive 和 metadata RESTful 服務。下面我們分別對這兩種機制進行介紹與分析
Config drive
Config drive 機制是指 OpenStack 將 metadata 信息寫入虛擬機的一個特殊的配置設備中，然后在虛擬機啟動時，自動掛載并讀取 metadata 信息，從而達到獲取 metadata 的目的。在客戶端操作系統(tǒng)中，存儲 metadata 的設備需要是 ISO9660 或者 VFAT 文件系統(tǒng)。具體的實現(xiàn)會根據(jù) Hypervisor 的不同和配置有所差異，以 libvirt 為例：OpenStack 會將 metadata 寫入 libvirt 的虛擬磁盤文件中，并指示 libvirt 將其虛擬為 cdrom 設備，如圖 1 和圖 2 所示。另一方面，虛擬機在啟動時，客戶操作系統(tǒng)中的 cloud-init 會去掛載并讀取該設備，然后根據(jù)所讀取出的內(nèi)容對虛擬機進行配置。
圖 1.虛擬機定義的 xml 文件
圖 2.存儲 metadata 的虛擬磁盤文件
當然，要實現(xiàn)上述功能，需要宿主機和虛擬機鏡像兩者協(xié)同完成，它們需要各自滿足一些條件：
宿主機（OpenStack 的計算節(jié)點）
-
支持 config drive 機制的 Hypervisors 有：libvirt、hyper-v 和 VMware。當使用 libvirt 和 VMware 作為 Hypervisor 時，需要確保宿主機上安裝有 genisoimage 程序，并且設置 mkisofs_cmd 標志為 genisoimage 的位置。當使用 hyper-v 作為 Hypervisor 時，需要設置 mkisofs_cmd 標志為 mkisofs.exe 的全路徑，此外還需要在 hyper-v 的配置文件中設置 qume_img_cmd 為 qemu-img 命令的路徑。
虛擬機鏡像
-
虛擬機鏡像需要確保安裝了 cloud-init。如果沒有安裝 cloud-init，需要自行編寫腳本，實現(xiàn)在虛擬機啟動期間掛載配置磁盤、讀取數(shù)據(jù)、解析數(shù)據(jù)并且根據(jù)數(shù)據(jù)內(nèi)容執(zhí)行相應動作。
OpenStack 提供了命令行參數(shù)–config-drive 用于配置是否在創(chuàng)建虛擬機時使用 config drive 機制。比如：
清單 1
#nova boot --config-drive=true --image image-name --key-name mykey --flavor 1 --user-data
./my-user-data.txt myinstance --file /etc/network/interfaces=/home/myuser/instance-interfaces
或者也可以如清單 2 所示，在/etc/nova/nova.conf 中配置，使得 OpenStack 計算服務在創(chuàng)建虛擬機時默認使用 config drive 機制。
清單 2
force_config_drive=true
用戶可以在虛擬機中查看寫入的 metadata 信息，如果客戶操作系統(tǒng)支持通過標簽訪問磁盤的話，可以使用如下命令查看：
清單 3
#mkdir -p /mnt/config
#mount /dev/disk/by-label/config-2 /mnt/config
Metadata RESTful 服務
OpenStack 提供了 RESTful 接口，虛擬機可以通過 REST API 來獲取 metadata 信息。提供該服務的組件為：nova-api-metadata。當然，要完成從虛擬機至網(wǎng)絡節(jié)點的請求發(fā)送和相應，只有 nova-api-metadata 服務是不夠的，此外共同完成這項任務的服務還有：Neutron-metadata-agent 和 Neutron-ns-metadata-proxy。下面我們將剖析它們是如何協(xié)同工作為虛擬機提供 metadata 服務的。
Nova-api-metadata
nova-api-metadata 啟動了 RESTful 服務，負責處理虛擬機發(fā)送來的 REST API 請求。從請求的 HTTP 頭部中取出相應的信息，獲得虛擬機的 ID，繼而從數(shù)據(jù)庫中讀取虛擬機的 metadata 信息，最后將結果返回。
Neutron-metadata-agent
Neutron-metadata-agent 運行在網(wǎng)絡節(jié)點，負責將接收到的獲取 metadata 的請求轉(zhuǎn)發(fā)給 nova-api-metadata。Neutron-metadata-agent 會獲取虛擬機和租戶的 ID，添加到請求的 HTTP 頭部中。nova-api-metadata 會根據(jù)這些信息獲取 metadata。
Neutron-ns-metadata-proxy
Neutron-ns-metadata-proxy 也運行在網(wǎng)絡節(jié)點。為了解決網(wǎng)絡節(jié)點的網(wǎng)段和租戶的虛擬網(wǎng)段重復的問題，OpenStack 引入了網(wǎng)絡命名空間。Neutron 中的路由和 DHCP 服務器都在各自獨立的命名空間中。由于虛擬機獲取 metadata 的請求都是以路由和 DHCP 服務器作為網(wǎng)絡出口，所以需要通過 neutron-ns-metadata-proxy 聯(lián)通不同的網(wǎng)絡命名空間，將請求在網(wǎng)絡命名空間之間轉(zhuǎn)發(fā)。Neutron-ns-metadata-proxy 利用在 unix domain socket 之上的 HTTP 技術，實現(xiàn)了不同網(wǎng)絡命名空間之間的 HTTP 請求轉(zhuǎn)發(fā)。并在請求頭中添加’X-Neutron-Router-ID’和’X-Neutron-Network-ID’信息，以便 Neutron-metadata-agent 來辨別發(fā)送請求的虛擬機，獲取虛擬機的 ID。
圖 3.Metadata 請求發(fā)送流程
如圖 3 所示，虛擬機獲取 metadata 的大致流程為：首先請求被發(fā)送至 neutron-ns-metadata-proxy，此時會在請求中添加 router-id 和 network-id，然后請求通過 unix domian socket 被轉(zhuǎn)發(fā)給 neutron-metadata-agent，根據(jù)請求中的 router-id、network-id 和 IP，獲取 port 信息，從而拿到 instance-id 和 tenant-id 加入請求中，最后請求被轉(zhuǎn)發(fā)給 nova-api-metadata，其利用 instance-id 和 tenant-id 獲取虛擬機的 metadata，返回相應。
上面我們分析了各個服務之間轉(zhuǎn)發(fā)請求的流程，那么現(xiàn)在只存在一個問題，整個獲取 metadata 的路線就通暢了：虛擬機如何將請求發(fā)送至 neutron-ns-metadata-proxy？
我們首先來分析虛擬機發(fā)送的請求。由于 metadata 最早是由亞馬遜提出的，當時規(guī)定 metadata 服務的地址為 169.254.169.254:80，OpenStack 沿用了這一規(guī)定。所以虛擬機會向 169.254.169.254:80 發(fā)送 medtadata 請求。那么這一請求是如何從虛擬機中發(fā)送出來的呢？目前 Neutron 有兩種方式來解決這個問題：通過 router 發(fā)送請求和通過 DHCP 發(fā)送請求。 通過 router 發(fā)送請求 如果虛擬機所在 subnet 連接在了 router 上，那么發(fā)向 169.254.169.254 的報文會被發(fā)至 router。如圖 4 所示，Neutron 通過在 router 所在網(wǎng)絡命名空間添加 iptables 規(guī)則，將該報文轉(zhuǎn)發(fā)至 9697 端口，而 neutron-ns-metadata-proxy 監(jiān)聽著該端口，所以報文被 neutron-ns-metadata-proxy 獲取，進入上述后續(xù)處理和轉(zhuǎn)發(fā)流程。
圖 4.router 所在網(wǎng)絡命名空間的 iptables 規(guī)則
圖 5.監(jiān)聽在 9697 端口上的 Neutron-ns-metadata-proxy 服務
通過 DHCP 發(fā)送請求
如果虛擬機所在 subnet 沒有連接在任何 router 上，那么請求則無法通過 router 轉(zhuǎn)發(fā)。此時 Neutron 通過 DHCP 服務器來轉(zhuǎn)發(fā) metadata 請求。DHCP 服務通過 DHCP 協(xié)議的選項 121 來為虛擬機設置靜態(tài)路由。如圖 6 所示，圖中 10.0.0.3 為 DHCP 服務器的 IP 地址。通過查看虛擬機的靜態(tài)路由表，我們可以發(fā)現(xiàn)發(fā)送至 169.254.169.254 的報文被發(fā)送到了 10.0.0.3，即 DHCP 服務器。
圖 6.虛擬機中的靜態(tài)路由表
另外再查看 DHCP 服務器的 IP 配置信息，發(fā)現(xiàn) DHCP 服務器配置了兩個 IP，其中一個就是 169.254.169.254。與 router 類似的，Neutron 在 DHCP 網(wǎng)絡命名空間中啟動了監(jiān)聽 80 端口的 neutron-ns-metadata-proxy 服務，從而進入處理和轉(zhuǎn)發(fā)請求的流程。
圖 7.DHCP 服務器的 IP 配置
總結
Metadata 服務為用戶自定義配置虛擬機提供了有效的解決方案。本文剖析了 OpenStack 提供 metadata 服務的兩種機制：config drive 和 RESTful 服務。Config drive 機制主要用于配置虛擬機的網(wǎng)絡信息，包括 IP、子網(wǎng)掩碼、網(wǎng)關等。當虛擬機無法通過 DHCP 正確獲取網(wǎng)絡信息時，config drive 是獲取 metadata 信息的必要方式。如果虛擬機能夠自動正確配置網(wǎng)絡，那么可以通過 RESTful 服務的方式獲取 metadata 信息。
分享文章：詳解OpenStack的metadata
網(wǎng)頁鏈接：http://www.5511xx.com/article/dpjospo.html
