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

OpenStack虛擬機如何獲取metadata

作者：佚名
云計算 虛擬化 OpenStack
cloud-init是運行在虛擬機內部的一個進程，它通過datasource獲取虛擬機的配置信息(即metadata)。

 1. 關于OpenStack metadata服務

我們知道OpenStack虛擬機是通過cloud-init完成初始化配置，比如網卡配置、hostname、初始化密碼以及密鑰配置等。cloud-init是運行在虛擬機內部的一個進程，它通過datasource獲取虛擬機的配置信息(即metadata)。cloud-init實現了很多不同的datasource，不同的datasource實現原理不一樣。比較常用的datasource主要有以下兩種：

  • ConfigDriver: Nova把所有配置信息寫入到本地的一個raw文件中，然后通過cdrom形式掛載到虛擬機中。此時在虛擬機內部可以看到類似/dev/sr0（注：sr代表 scsi + rom)的虛擬設備。cloud-init只需要讀取/dev/sr0文件信息即可獲取虛擬機配置信息。
  • Metadata: Nova在本地啟動一個HTTP metadata服務，虛擬機只需要通過HTTP訪問該metadata服務獲取相關的虛擬機配置信息。

ConfigDriver的實現原理比較簡單，本文不再介紹。這里重點介紹Metadata，主要解決以下兩個問題：

  1. Nova Metadata服務啟動在宿主機上（nova-api所在的控制節點），虛擬機內部租戶網絡和宿主機的物理網絡是不通的，虛擬機如何訪問Nova的Metadata服務。
  2. 假設問題1已經解決，那么Nova Metadata服務如何知道是哪個虛擬機發起的請求。

[[236018]]

2. Metadata服務配置

2.1 Nova配置

Nova的metadata服務名稱為nova-api-metadata，不過通常會把服務與nova-api服務合并:

  1. [DEFAULT] 
  2. enabled_apis = osapi_compute,metadata 

另外虛擬機訪問Nova的Metadata服務需要Neutron轉發，原因后面講，這里只需要注意在nova.conf配置:

  1. [neutron] 
  2. service_metadata_proxy = true 

2.2 Neutron配置

前面提到虛擬機訪問Nova的Metadata服務需要Neutron轉發，可以通過l3-agent轉發，也可以通過dhcp-agent轉發，如何選擇需要根據實際情況：

  • 通過l3-agent轉發，則虛擬機所在的網絡必須關聯了router。
  • 通過dhcp-agent轉發，則虛擬機所在的網絡必須開啟dhcp功能。

Metadata默認是通過l3-agent轉發的，不過由于在實際情況下，虛擬機的網絡通常都會開啟dhcp功能，但不一定需要router，因此我更傾向于選擇通過dhcp-agent轉發，配置如下:

  1. # /etc/neutron/dhcp_agent.ini [DEFAULT] 
  2. force_metadata = true 
  3.  
  4. # /etc/neuron/l3_agent.ini [DEFAULT] 
  5. enable_metadata_proxy = false 

本文接下來的所有內容均基于以上配置環境。

3 OpenStack虛擬機如何訪問Nova Metadata服務

3.1 從虛擬機訪問Metadata服務說起

cloud-init訪問metadata服務的URL地址是http://169.254.169.254，這個IP很特別，主要是效仿了AWS的Metadata服務地址，它的網段是169.254.0.0/16，這個IP段其實是保留的，即IPv4 Link Local Address，它和私有IP(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)類似，不能用于互聯網路由，通常只用于直連網絡。如果操作系統(Windows)獲取IP失敗，也有可能自動配置為169.254.0.0/16網段的一個IP。

那AWS為什么選擇169.254.169.254這個IP呢，這是因為選擇Link Local IP可以避免與用戶的IP沖突，至于為什么選擇169.254.169.254這個IP而不是169.254.0.0/24的其它IP，大概是為了好記吧。

另外AWS還有幾個很有趣的地址：

  • 169.254.169.253: DNS服務。
  • 169.254.169.123: NTP服務。

更多關于169.254.169.254信息，可以參考whats-special-about-169-254-169-254-ip-address-for-aws。

OpenStack虛擬機也是通過http://169.254.169.254獲取虛擬機的初始化配置信息：

  1. $ curl -sL 169.254.169.254/openstack/latest/meta_data.json {"uuid": "daf32a70-42c9-4d30-8ec5-3a5d97582cff", "availability_zone": "nova", "hostname": "int32bit-test-1.novalocal", "launch_index": 0, "devices": [], "project_id": "ca17d50f6ac049928cc2fb2217dab93b", "name": "int32bit-test-1"} 

從以上輸出可見從metadata服務中我們獲取了虛擬機的uuid、name、project id、availability_zone、hostname等。

虛擬機怎么通過訪問169.254.169.254這個地址就可以獲取Metadata信息呢，我們首先查看下虛擬機的路由表:

  1. # route -n 
  2. Kernel IP routing table 
  3. Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
  4. 0.0.0.0         10.0.0.126      0.0.0.0         UG    0      0        0 eth0 
  5. 10.0.0.64       0.0.0.0         255.255.255.192 U     0      0        0 eth0 
  6. 169.254.169.254 10.0.0.66       255.255.255.255 UGH   0      0        0 eth0 

我們可以看到169.254.169.254的下一跳為10.0.0.66。10.0.0.66這個IP是什么呢？我們通過Neutron的port信息查看下:

  1. # neutron port-list -c network_id -c device_owner -c mac_address -c fixed_ips -f csv | grep 10.0.0.66 
  2. "2c4b658c-f2a0-4a17-9ad2-c07e45e13a8a","network:dhcp","fa:16:3e:b3:e8:38","[{u'subnet_id': u'6f046aae-2158-4882-a818-c56d81bc8074', u'ip_address': u'10.0.0.66'}]" 

可看到10.0.0.66正好是網絡2c4b658c-f2a0-4a17-9ad2-c07e45e13a8a的dhcp地址，可以進一步驗證:

  1. # ip netns exec qdhcp-2c4b658c-f2a0-4a17-9ad2-c07e45e13a8a ifconfig 
  2. tap1332271e-0d: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450 
  3.         inet 10.0.0.66  netmask 255.255.255.192  broadcast 10.0.0.127 
  4.         inet6 fe80::f816:3eff:feb3:e838  prefixlen 64  scopeid 0x20<link> 
  5.         ether fa:16:3e:b3:e8:38  txqueuelen 1000  (Ethernet) 
  6.         RX packets 662  bytes 58001 (56.6 KiB) 
  7.         RX errors 0  dropped 0  overruns 0  frame 0 
  8.         TX packets 410  bytes 55652 (54.3 KiB) 
  9.         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 

由此，我們可以得出結論，OpenStack虛擬機訪問169.254.169.254會路由到虛擬機所在網絡的DHCP地址，DHCP地址與虛擬機IP肯定是可以互通的，從而解決了虛擬機內部到宿主機外部的通信問題。那DHCP又如何轉發到Nova Metadata服務呢，下一節將介紹如何解決這個問題。

3.2 Metadata請求***次轉發

前面介紹了虛擬機訪問Metadata服務地址169.254.169.254，然后轉發到DHCP地址。我們知道Neutron的DHCP port被放到了namespace中，我們不妨進入到虛擬機所在網絡的namespace:

  1. ip netns exec qdhcp-2c4b658c-f2a0-4a17-9ad2-c07e45e13a8a bash 

首先查看該namespace的路由:

  1. # route -n 
  2. Kernel IP routing table 
  3. Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
  4. 0.0.0.0         10.0.0.126      0.0.0.0         UG    0      0        0 tap1332271e-0d 
  5. 10.0.0.64       0.0.0.0         255.255.255.192 U     0      0        0 tap1332271e-0d 
  6. 169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 tap1332271e-0d 

從路由表中看出169.254.0.0/16是從網卡tap1332271e-0d發出去的，我們查看網卡地址信息:

  1. # ip a 
  2. 18: tap1332271e-0d: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN qlen 1000 
  3.     link/ether fa:16:3e:b3:e8:38 brd ff:ff:ff:ff:ff:ff 
  4.     inet 10.0.0.66/26 brd 10.0.0.127 scope global tap1332271e-0d 
  5.        valid_lft forever preferred_lft forever 
  6.     inet 169.254.169.254/16 brd 169.254.255.255 scope global tap1332271e-0d 
  7.        valid_lft forever preferred_lft forever 
  8.     inet6 fe80::f816:3eff:feb3:e838/64 scope link 
  9.        valid_lft forever preferred_lft forever 

我們發現，169.254.169.254其實是配在網卡tap1332271e-0d的一個虛擬IP。虛擬機能夠訪問169.254.169.254這個地址也就不足為奇了。需要注意的是，本文的metadata轉發配置是通過dhcp-agent實現的，如果是l3-agent，則169.254.169.254是通過iptables轉發。

我們能夠訪問curl http://169.254.169.254，說明這個地址肯定開放了80端口:

  1. # netstat -lnpt 
  2. Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name 
  3. tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      11334/haproxy 
  4. tcp        0      0 10.0.0.66:53            0.0.0.0:*               LISTEN      11331/dnsmasq 
  5. tcp        0      0 169.254.169.254:53      0.0.0.0:*               LISTEN      11331/dnsmasq 
  6. tcp6       0      0 fe80::f816:3eff:feb3:53 :::*                    LISTEN      11331/dnsmasq 

從輸出中看，所在的環境除了開啟了DHCP服務(53端口)，確實監聽了80端口，進程pid為11334/haproxy。

我們看到haproxy這個進程就可以猜測是負責請求的代理與轉發，即OpenStack虛擬機首先會把請求轉發到DHCP所在namespace的haproxy監聽端口80。

問題又來了，DHCP所在的namespace網絡仍然和Nova Metadata是不通的，那haproxy如何轉發請求到Nova Metadata服務呢，我們下一節介紹。

3.3 Metadata請求第二次轉發

前面我們介紹了OpenStack虛擬機訪問http://169.254.169.254會被轉發到DHCP所在namespace的haproxy監聽的80端口中。但是，namespace中仍然無法訪問Nova Metadata服務。

為了研究解決辦法，我們首先看下這個haproxy進程信息:

  1. cat /proc/11334/cmdline | tr '\0' ' ' 
  2. haproxy -f /opt/stack/data/neutron/ns-metadata-proxy/2c4b658c-f2a0-4a17-9ad2-c07e45e13a8a.conf 

其中2c4b658c-f2a0-4a17-9ad2-c07e45e13a8a.conf配置文件部分內容如下:

  1. listen listener 
  2.     bind 0.0.0.0:80 
  3.     server metadata /opt/stack/data/neutron/metadata_proxy 
  4.     http-request add-header X-Neutron-Network-ID 2c4b658c-f2a0-4a17-9ad2-c07e45e13a8a 

我們發現haproxy綁定的端口為80，后端地址為一個文件/opt/stack/data/neutron/metadata_proxy。后端不是一個IP/TCP地址，那必然是一個UNIX Socket文件:

  1. # ll /opt/stack/data/neutron/metadata_proxy 
  2. srw-r--r-- 1 stack stack 0 Jul  1 13:30 /opt/stack/data/neutron/metadata_proxy 

因此我們得出結論，haproxy進程會把OpenStack虛擬機Metadata請求轉發到本地的一個socket文件中。

UNIX Domain Socket是在socket架構上發展起來的用于同一臺主機的進程間通訊（IPC），它不需要經過網絡協議棧實現將應用層數據從一個進程拷貝到另一個進程，有點類似于Unix管道(pipeline)。

問題又來了:

  • 我們從haproxy配置看，監聽的地址是0.0.0.0:80，那如果有多個網絡同時都監聽80端口豈不是會出現端口沖突嗎？
  • socket只能用于同一主機的進程間通信，如果Nova Metadata服務與Neutron dhcp-agent不在同一個主機，則顯然還是無法通信。

***個問題其實前面已經解決了，haproxy是在虛擬機所在網絡的DHCP namespace中啟動的，我們可以驗證:

  1. # lsof -i :80 
  2. COMMAND   PID  USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME 
  3. haproxy 11334 stack    4u  IPv4 65729753      0t0  TCP *:http (LISTEN) 
  4. # ip netns identify 11334 
  5. qdhcp-2c4b658c-f2a0-4a17-9ad2-c07e45e13a8a 

關于第二個問題，顯然還需要一層轉發，具體內容請看下一小節內容。

另外需要注意的是，新版本的OpenStack是直接使用haproxy代理轉發的，在一些老版本中則使用neutron-ns-metadata-proxy進程負責轉發，實現的代碼位于neutron/agent/metadata/namespace_proxy.py：

  1. def _proxy_request(self, remote_address, method, path_info, 
  2.                        query_string, body): 
  3.     headers = { 
  4.         'X-Forwarded-For': remote_address, 
  5.     } 
  6.  
  7.     if self.router_id: 
  8.         headers['X-Neutron-Router-ID'] = self.router_id 
  9.     else: 
  10.         headers['X-Neutron-Network-ID'] = self.network_id 
  11.  
  12.     url = urlparse.urlunsplit(( 
  13.         'http', 
  14.         '169.254.169.254', 
  15.         path_info, 
  16.         query_string, 
  17.         '')) 
  18.  
  19.     h = httplib2.Http() 
  20.     resp, content = h.request( 
  21.         url, 
  22.         method=method, 
  23.         headers=headers, 
  24.         body=body, 
  25.         connection_type=agent_utils.UnixDomainHTTPConnection) 

大家可能對請求URL為169.254.169.254有疑問，怎么轉發給自己呢? 這是因為這是一個UNIX Domain Socket請求，其實這個URL只是個參數占位，填什么都無所謂，這個請求相當于:

  1. curl -H "X-Neutron-Network-ID: ${network_uuid}" \ 
  2.      -H "X-Forwarded-For: ${request_ip}" \ 
  3.      -X GET \ 
  4.      --unix /var/lib/neutron/metadata_proxy \ 
  5.      http://169.254.169.254 

3.4 Metadata請求第三次轉發

前面說到，haproxy會把Metadata請求轉發到本地的一個socket文件中，那么，到底是哪個進程在監聽/opt/stack/data/neutron/metadata_proxysocket文件呢？我們通過lsof查看下:

  1. # lsof /opt/stack/data/neutron/metadata_proxy 
  2. COMMAND     PID  USER   FD   TYPE             DEVICE SIZE/OFF     NODE NAME 
  3. neutron-m 11085 stack    3u  unix 0xffff8801c8711c00      0t0 65723197 /opt/stack/data/neutron/metadata_proxy 
  4. neutron-m 11108 stack    3u  unix 0xffff8801c8711c00      0t0 65723197 /opt/stack/data/neutron/metadata_proxy 
  5. neutron-m 11109 stack    3u  unix 0xffff8801c8711c00      0t0 65723197 /opt/stack/data/neutron/metadata_proxy 
  6. # cat /proc/11085/cmdline  | tr '\0' ' ' 
  7. /usr/bin/python /usr/bin/neutron-metadata-agent --config-file /etc/neutron/neutron.conf 

可見neutron-metadata-agent監聽了這個socket文件，相當于haproxy把Metadata服務通過socket文件轉發給了neutron-metadata-agent服務。

  1. def run(self): 
  2.     server = agent_utils.UnixDomainWSGIServer('neutron-metadata-agent') 
  3.     server.start(MetadataProxyHandler(self.conf), 
  4.                  self.conf.metadata_proxy_socket, 
  5.                  workers=self.conf.metadata_workers, 
  6.                  backlog=self.conf.metadata_backlog, 
  7.                  mode=self._get_socket_mode()) 
  8.     self._init_state_reporting() 
  9.     server.wait() 

進一步驗證了neutron-metadata-agent監聽了/opt/stack/data/neutron/metadata_proxysocket文件。

由于neutron-metadata-agent是控制節點上的進程，因此和Nova Metadata服務肯定是通的, OpenStack虛擬機如何訪問Nova Metadata服務問題基本就解決了。

  1. curl 169.254.169.254 -> haproxy(80端口) -> UNIX Socket文件 -> neutron-metadata-agent -> nova-api-metadata 

即一共需要三次轉發。

但是Nova Metadata服務如何知道是哪個虛擬機發送過來的請求呢？換句話說，如何獲取該虛擬機的uuid，我們將在下一章介紹。

4 Metadata服務如何獲取虛擬機信息

前一章介紹了OpenStack虛擬機如何通過169.254.169.254到達Nova Metadata服務，那到達之后如何判斷是哪個虛擬機發送過來的呢？

OpenStack是通過neutron-metadata-agent獲取虛擬機的uuid的。我們知道，在同一個Neutron network中，即使有多個subnet，也不允許IP重復，即通過IP地址能夠唯一確定Neutron的port信息。而neutron port會設置device_id標識消費者信息，對于虛擬機來說，即虛擬機的uuid。

因此neutron-metadata-agent通過network uuid以及虛擬機ip即可獲取虛擬機的uuid。

不知道大家是否還記得在haproxy配置文件中存在一條配置項:

  1. http-request add-header X-Neutron-Network-ID 2c4b658c-f2a0-4a17-9ad2-c07e45e13a8a 

即haproxy轉發之前會把network id添加到請求頭部中，而IP可以通過HTTP的頭部X-Forwarded-For中獲取。因此neutron-metadata-agent具備獲取虛擬機的uuid以及project id(租戶id)條件，我們可以查看neutron-metadata-agent獲取虛擬機uuid以及project id實現，代碼位于neutron/agent/metadata/agent.py:

  1. def _get_instance_and_tenant_id(self, req): 
  2.     remote_address = req.headers.get('X-Forwarded-For') 
  3.     network_id = req.headers.get('X-Neutron-Network-ID') 
  4.     router_id = req.headers.get('X-Neutron-Router-ID') 
  5.  
  6.     ports = self._get_ports(remote_address, network_id, router_id) 
  7.     if len(ports) == 1: 
  8.         return ports[0]['device_id'], ports[0]['tenant_id'] 
  9.     return None, None 

如果誰都可以偽造Metadata請求獲取任何虛擬機的metadata信息，顯然是不安全的，因此在轉發給Nova Metadata服務之前，還需要發一個secret:

  1. def _sign_instance_id(self, instance_id): 
  2.     secret = self.conf.metadata_proxy_shared_secret 
  3.     secret = encodeutils.to_utf8(secret) 
  4.     instance_id = encodeutils.to_utf8(instance_id) 
  5.     return hmac.new(secret, instance_id, hashlib.sha256).hexdigest() 

metadata_proxy_shared_secret需要管理員配置，然后組合虛擬機的uuid生成一個隨機的字符串作為key。

最終，neutron-metadata-agent會把虛擬機信息放到頭部中，發送到Nova Metadata服務的頭部信息如下：

  1. headers = { 
  2.     'X-Forwarded-For': req.headers.get('X-Forwarded-For'), 
  3.     'X-Instance-ID': instance_id, 
  4.     'X-Tenant-ID': tenant_id, 
  5.     'X-Instance-ID-Signature': self._sign_instance_id(instance_id) 
  6. } 

此時Nova Metadata就可以通過虛擬機的uuid查詢metadata信息了，代碼位于nova/api/metadata/base.py:

  1. def get_metadata_by_instance_id(instance_id, address, ctxt=None): 
  2.     ctxt = ctxt or context.get_admin_context() 
  3.     attrs = ['ec2_ids', 'flavor', 'info_cache', 
  4.              'metadata', 'system_metadata', 
  5.              'security_groups', 'keypairs', 
  6.              'device_metadata'] 
  7.     try: 
  8.         im = objects.InstanceMapping.get_by_instance_uuid(ctxt, instance_id) 
  9.     except exception.InstanceMappingNotFound: 
  10.         LOG.warning('Instance mapping for %(uuid)s not found; ' 
  11.                     'cell setup is incomplete', {'uuid': instance_id}) 
  12.         instance = objects.Instance.get_by_uuid(ctxt, instance_id, 
  13.                                                 expected_attrs=attrs) 
  14.         return InstanceMetadata(instance, address) 
  15.  
  16.     with context.target_cell(ctxt, im.cell_mapping) as cctxt: 
  17.         instance = objects.Instance.get_by_uuid(cctxt, instance_id, 
  18.                                                 expected_attrs=attrs) 
  19.         return InstanceMetadata(instance, address) 

5 在虛擬機外部如何獲取虛擬機metadata

前面已經介紹了OpenStack虛擬機從Nova Metadata服務獲取metadata的過程。有時候我們可能需要調試虛擬機的metadata信息，驗證傳遞的數據是否正確，而又嫌麻煩不希望進入虛擬機內部去調試。有什么方法能夠直接調用nova-api-metadata服務獲取虛擬機信息呢。

根據前面介紹的原理，我寫了兩個腳本實現:

***個Python腳本sign_instance.py用于生成secret:

  1. sign_instance.py 
  2.  
  3. import six 
  4. import sys 
  5. import hmac 
  6. import hashlib 
  7.  
  8. def sign_instance_id(instance_id, secret=''): 
  9.     if isinstance(secret, six.text_type): 
  10.         secret = secret.encode('utf-8') 
  11.     if isinstance(instance_id, six.text_type): 
  12.         instance_id = instance_id.encode('utf-8') 
  13.     return hmac.new(secret, instance_id, hashlib.sha256).hexdigest() 
  14. print(sign_instance_id(sys.argv[1])) 

第二個bash腳本get_metadata.py實現獲取虛擬機metadata:

  1. #!/bin/bash 
  2. metadata_server=http://192.168.1.16:8775 
  3. metadata_url=$metadata_server/openstack/latest 
  4. instance_id=$1 
  5. data=$2 
  6. if [[ -z $instance_id ]]; then echo "Usage: $0 <instance_id>" 
  7.     exit 1 
  8. fi tenant_id=$(nova show $instance_id | awk '/tenant_id/{print $4}') 
  9. sign_instance_id=$(python sign_instance.py $instance_id) 
  10. curl -sL -H "X-Instance-ID:$instance_id" -H "X-Instance-ID-Signature:$sign_instance_id" -H "X-Tenant-ID:$tenant_id"  $metadata_url/$data 

其中metadata_server為Nova Metadata服務地址。

用法如下:

  1. # ./get_metadata.sh daf32a70-42c9-4d30-8ec5-3a5d97582cff 
  2. meta_data.json 
  3. password 
  4. vendor_data.json 
  5. network_data.json 
  6. # ./get_metadata.sh daf32a70-42c9-4d30-8ec5-3a5d97582cff network_data.json | python -m json.tool 
  7. { 
  8.     "links": [ 
  9.         { 
  10.             "ethernet_mac_address": "fa:16:3e:e8:81:9b", 
  11.             "id": "tap28468932-9e", 
  12.             "mtu": 1450, 
  13.             "type": "ovs", 
  14.             "vif_id": "28468932-9ea0-43d0-b699-ba19bf65cae3" 
  15.         } 
  16.     ], 
  17.     "networks": [ 
  18.         { 
  19.             "id": "network0", 
  20.             "link": "tap28468932-9e", 
  21.             "network_id": "2c4b658c-f2a0-4a17-9ad2-c07e45e13a8a", 
  22.             "type": "ipv4_dhcp" 
  23.         } 
  24.     ], 
  25.     "services": [] 
  26. } 

5 總結

***通過一張工作流圖總結：

OpenStack Metadata Workflow

源碼:

  1. title OpenStack Metadata WorkFlow  
  2.   
  3. participant vm  
  4. participant haproxy  
  5. participant UNIX Socket  
  6. participant neutron-metadata-agent  
  7. participant nova-api-metadata  
  8.   
  9. vm -> haproxy: curl 169.254.169.254(***次轉發）   
  10. note over haproxy: Add header X-Neutron-Network-ID  
  11. haproxy -> UNIX Socket: 第二次轉發  
  12. UNIX Socket -> neutron-metadata-agent: 第二次轉發  
  13. note over neutron-metadata-agent: get_instance_and_tenant_id  
  14. note over neutron-metadata-agent: sign_instance_id  
  15. neutron-metadata-agent -> nova-api-metadata: 第三次轉發   
  16. note over nova-api-metadata: get_metadata_by_instance_id  
  17. nova-api-metadata -> neutron-metadata-agent: metadata  
  18. neutron-metadata-agent -> UNIX Socket: metadata  
  19. UNIX Socket -> haproxy: metadata  
  20. haproxy -> vm: metadata  

 【本文是51CTO專欄作者“付廣平”的原創文章，如需轉載請通過51CTO獲得聯系】

戳這里，看該作者更多好文

責任編輯：武曉燕 來源： 51CTO專欄
OpenStack虛擬機metadata
相關推薦

2016-09-01 12:37:13

OpenStack虛擬機Metadata

2011-12-12 09:08:48

OpenStack虛擬機監控

2015-09-18 10:40:04

OpenStackMetadata虛擬機配置

2014-04-16 10:44:56

OpenStack命令行工具虛擬機

2014-04-16 13:22:29

虛擬機OpenStack命令行

2012-04-10 10:29:29

2010-12-23 14:05:12

虛擬機

2017-09-14 10:11:24

OpenStack虛擬機過程分析

2012-05-18 10:22:23

2022-08-14 09:11:13

Kubernetes容器云原生

2015-05-15 10:36:13

2015-07-08 14:33:23

虛擬機OpenStack

2013-07-17 09:32:58

2020-03-18 13:22:33

虛擬機OpenStack裸機

2015-04-28 13:35:22

SDNOpenFlowOpenStack

2010-07-26 09:02:38

2013-04-07 09:52:40

Ubuntu虛擬機虛擬化軟件

2009-06-29 19:36:07

虛擬機備份虛擬環境

2012-04-27 09:29:57

虛擬化虛擬機云

2013-11-19 14:05:08

VDP虛擬機
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 青青草免费在线视频 | 精品一区二区三区不卡 | 国产精品3区 | 久久久婷婷 | 视频一区二区三区中文字幕 | 亚洲国产成人精品久久久国产成人一区 | 日韩视频在线免费观看 | 免费观看羞羞视频网站 | 久久久久久av | 色成人免费网站 | 91精品国产综合久久久亚洲 | 中文字幕免费视频 | 午夜免费电影 | 中文字幕在线播放第一页 | 中文二区 | 国产精品久久一区 | 国产 欧美 日韩 一区 | 免费午夜电影 | 一级h片| 日韩有码一区 | 欧美午夜视频 | 美女激情av | 亚洲精品9999 | 一级二级三级在线观看 | 欧美精品一区二区三区在线播放 | 羞羞视频网站免费观看 | 国产性生活一级片 | 做a视频| 狠狠热视频 | 久久久久国产一区二区三区 | 成人在线精品 | 午夜精品久久久久久久久久久久久 | 久久久久网站 | 日日拍夜夜 | 亚洲精品9999久久久久 | 日韩中文字幕视频 | 日韩一区二区在线免费观看 | 91精品国产综合久久久久蜜臀 | 日韩国产精品一区二区三区 | 超碰免费在线 | 精品一区二区三区在线观看国产 |