成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

OpenStack Metadata 服務機制及配置方式

云計算 OpenStack
Metadata 服務為用戶自定義配置虛擬機提供了有效的解決方案。本文剖析了 OpenStack 提供 metadata 服務的兩種機制:config drive 和 RESTful 服務。Config drive 機制主要用于配置虛擬機的網絡信息,包括 IP、子網掩碼、網關等。當虛擬機無法通過 DHCP 正確獲取網絡信息時,config drive 是獲取 metadata 信息的必要方式。如果虛擬機能夠自動正確配置網絡,那么可以通過 RESTful 服務的方式獲取 metadata 信息。

Metadata 的概念

在創建虛擬機的時候,用戶往往需要對虛擬機進行一些配置,比如:開啟一些服務、安裝某些包、添加 SSH 秘鑰、配置 hostname 等等。在 OpenStack 中,這些配置信息被分成兩類:metadata 和 user data。Metadata 主要包括虛擬機自身的一些常用屬性,如 hostname、網絡配置信息、SSH 登陸秘鑰等,主要的形式為鍵值對。而 user data 主要包括一些命令、腳本等。User data 通過文件傳遞,并支持多種文件格式,包括 gzip 壓縮文件、shell 腳本、cloud-init 配置文件等。雖然 metadata 和 user data 并不相同,但是 OpenStack 向虛擬機提供這兩種信息的機制是一致的,只是虛擬機在獲取到信息后,對兩者的處理方式不同罷了。所以下文統一用 matadata 來描述。

本文詳細闡述了 OpenStack 中 metadata 的服務機制,通過深入了解 metadata 的服務機制,用戶可以在適當的應用場景中選擇正確的 metadata 配置方式,從而對虛擬機進行配置。此外,了解 metadata 服務機制能夠為用戶在 OpenStack 的部署、排錯、維護提供幫助,提高工作效率。

Metadata 的獲取機制

在 OpenStack 中,虛擬機獲取 Metadata 信息的方式有兩種:Config drive 和 metadata RESTful 服務。下面我們分別對這兩種機制進行介紹與分析。

Config drive

Config drive 機制是指 OpenStack 將 metadata 信息寫入虛擬機的一個特殊的配置設備中,然后在虛擬機啟動時,自動掛載并讀取 metadata 信息,從而達到獲取 metadata 的目的。在客戶端操作系統中,存儲 metadata 的設備需要是 ISO9660 或者 VFAT 文件系統。具體的實現會根據 Hypervisor 的不同和配置有所差異,以 libvirt 為例:OpenStack 會將 metadata 寫入 libvirt 的虛擬磁盤文件中,并指示 libvirt 將其虛擬為 cdrom 設備,如圖 1 和圖 2 所示。另一方面,虛擬機在啟動時,客戶操作系統中的 cloud-init 會去掛載并讀取該設備,然后根據所讀取出的內容對虛擬機進行配置。

OpenStack 的 metadata 服務機制

圖 1.虛擬機定義的 xml 文件

OpenStack 的 metadata 服務機制

圖 2.存儲 metadata 的虛擬磁盤文件

當然,要實現上述功能,需要宿主機和虛擬機鏡像兩者協同完成,它們需要各自滿足一些條件:

宿主機(OpenStack 的計算節點)

支持 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,需要自行編寫腳本,實現在虛擬機啟動期間掛載配置磁盤、讀取數據、解析數據并且根據數據內容執行相應動作。

OpenStack 提供了命令行參數--config-drive 用于配置是否在創建虛擬機時使用 config drive 機制。比如:

清單 1

  1. #nova boot --config-drive=true --image image-name --key-name mykey --flavor 1 --user-data  
  2. ./my-user-data.txt myinstance --file /etc/network/interfaces=/home/myuser/instance-interfaces 

或者也可以如清單 2 所示,在/etc/nova/nova.conf 中配置,使得 OpenStack 計算服務在創建虛擬機時默認使用 config drive 機制。

清單 2

  1. force_config_drive=true 

用戶可以在虛擬機中查看寫入的 metadata 信息,如果客戶操作系統支持通過標簽訪問磁盤的話,可以使用如下命令查看:

清單 3

  1. #mkdir -p /mnt/config 
  2. #mount /dev/disk/by-label/config-2 /mnt/config 

Metadata RESTful 服務

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

Nova-api-metadata

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

Neutron-metadata-agent

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

OpenStack 的 metadata 服務機制

圖 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 發送請求。

#p#

通過 router 發送請求

如果虛擬機所在 subnet 連接在了 router 上,那么發向 169.254.169.254 的報文會被發至 router。如圖 4 所示,Neutron 通過在 router 所在網絡命名空間添加 iptables 規則,將該報文轉發至 9697 端口,而 neutron-ns-metadata-proxy 監聽著該端口,所以報文被 neutron-ns-metadata-proxy 獲取,進入上述后續處理和轉發流程。

OpenStack 的 metadata 服務機制

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

OpenStack 的 metadata 服務機制

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

 


通過 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 服務器。

OpenStack 的 metadata 服務機制

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

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

OpenStack 的 metadata 服務機制

圖 7.DHCP 服務器的 IP 配置

總結

Metadata 服務為用戶自定義配置虛擬機提供了有效的解決方案。本文剖析了 OpenStack 提供 metadata 服務的兩種機制:config drive 和 RESTful 服務。Config drive 機制主要用于配置虛擬機的網絡信息,包括 IP、子網掩碼、網關等。當虛擬機無法通過 DHCP 正確獲取網絡信息時,config drive 是獲取 metadata 信息的必要方式。如果虛擬機能夠自動正確配置網絡,那么可以通過 RESTful 服務的方式獲取 metadata 信息。

原文鏈接:http://www.ibm.com/developerworks/cn/cloud/library/1509_liukg_openstackmeta/index.html
 

責任編輯:Ophira 來源: ibm developerWorks 中國
相關推薦

2018-07-10 15:10:50

OpenStack虛擬機metadata

2016-09-20 22:41:21

Linuxmmapreadahead

2016-09-01 12:37:13

OpenStack虛擬機Metadata

2010-04-27 12:56:35

lvs負載均衡

2018-04-12 08:37:27

2010-08-05 10:19:28

路由器配置

2013-12-08 19:51:20

OpenStack網絡配置

2009-09-17 14:05:18

WSUS服務器

2013-12-08 18:13:08

OpenStack橫向擴展

2016-02-29 16:54:10

OpenStack混合云應用軟件定義基礎設施

2023-03-17 08:50:00

服務器時鐘服務數據庫

2015-01-20 09:35:52

2015-06-12 10:27:28

DevOpsDockerOpenStack

2013-09-16 15:46:50

OpenStack云計算

2020-07-16 08:39:18

服務狀態排錯

2012-08-07 15:02:05

OpenStack網絡模式

2010-02-26 14:05:57

WCF通信方式

2014-11-27 13:29:29

OpenStackSwift開源

2025-05-27 01:00:00

2013-07-31 09:38:16

IPv6地址單播地址多播地址
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 亚洲精彩免费视频 | 特级做a爱片免费69 精品国产鲁一鲁一区二区张丽 | 91精品久久久久久久久久入口 | 蜜桃av一区二区三区 | 污视频免费在线观看 | 蜜桃视频在线观看免费视频网站www | 亚洲国产精品视频一区 | 国产高清在线 | 91五月天| 成人av播放| 999久久久精品 | 亚洲日日 | 精品国产18久久久久久二百 | 色橹橹欧美在线观看视频高清 | 欧美日韩美女 | 青青久久av北条麻妃海外网 | 成人1区2区| 欧美日韩精品久久久免费观看 | 久久久久久久国产精品 | 精品国产aⅴ | 91黄色免费看 | 91精品国产一区二区三区蜜臀 | 欧美成人一区二免费视频软件 | 毛片在线看片 | 天天操夜夜拍 | 日韩欧美三区 | av免费网址 | 久久99精品久久久 | 国产这里只有精品 | 毛片区| 91成人免费看片 | 精品日韩 | 亚洲欧美bt | 国产精品久久久久久久久久尿 | 久久五月婷| 水蜜桃亚洲一二三四在线 | 久久久91精品国产一区二区三区 | 美女精品一区 | 中文字幕一区二区三区四区 | 99国产精品99久久久久久 | 福利影院在线看 |