深入理解OpenStack-虚拟机元数据metadata

• 概念

OpenStack云主机metadata(元数据)是一组与一台云主机相关联的键值对。用户可以通过API读写这些键值对。
云主机或者Nova服务也可以获取这些metadata。

• OpenStack元数据分类

元数据可以分为实例元数据(instance metadata)和用户数据(instance user data)。

实例元数据包括键值对或者自定义键值对.
用户数据是以user-data为键的元数据，供部署在云主机中的云感知应用使用。

用户数据与普通实例元数据的不同在于它先于云主机创建，并从云主机中访问，可以用于存储配置、脚本以及其它任何信息。

• 查询元数据有何作用？

在OpenStack云主机上通过请求Metadata元数据API，来获取云主机上的主机名、IP地址、SSH公钥等信息。通过这些信息可以通过编写脚本来对云主机的标准化进行定制。

---

查询云主机元数据

云主机中,可以通过访问http://169.254.169.254 这个URL来获取它的元数据信息。

在控制节点上ssh虚拟机
ssh cirros@192.168.56.53

获取元数据metadata
$ curl http://169.254.169.254/
1.0
2007-01-19
2007-03-01
...
2008-09-01
2009-04-04
latest

这个返回结果是元数据服务目前支持的接口版本号，可以选择最新的2009-04-04来查询元数据。

$ curl http://169.254.169.254/2009-04-04/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
instance-action
instance-id
instance-type
local-hostname
local-ipv4
placement/
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups

比如：
1. 获取虚拟机的IP地址
   $ curl http://169.254.169.254/2009-04-04/meta-data/local-ipv4
     192.168.56.53

2. 获取虚拟机的主机名
   $ curl http://169.254.169.254/2009-04-04/meta-data/hostname
     first1host.novalocal
     
3. 获取已上传到虚拟机中的ssh-key
   $ curl http://169.254.169.254/2009-04-04/meta-data/public-keys/0/openssh-key
     ssh-rsa AAAAB3NzaC1yc2EA......kDwKNgF3 root@controller

metadata元数据获取流程

获取元数据的请求会通过云主机的默认网关,路由到网络节点上该云主机所在虚拟网络的虚拟网关设备上，并通过iptables的NAT规则重定向到neutron-ns-metadata-proxy服务，再经由neutron-metadata-agent最终由nova-api里提供的metadata服务返回云主机的虚拟机。 


注(重要)：在/etc/neutron/dhcp_agent.ini中有enable_isolated_metadata这个选项，设置为True后，如果一个虚拟网络没有网关则DHCP服务会给这个主机增加一条路由，将元数据请求路由到DHCP服务。只要DHCP服务与元数据服务在一台主机上就可以由后者去处理该请求了。


如下图(参考):

(1)虚拟机发出请求

查看虚拟机网卡信息
$ ip -4 address show dev eth0
  eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
  inet 192.168.56.53/24 brd 192.168.56.255 scope global eth0


查看虚拟机路由
$ ip route list
default via 192.168.56.2 dev eth0 
169.254.169.254 via 192.168.56.50 dev eth0 
192.168.56.0/24 dev eth0  src 192.168.56.53

(2)namespace-metadata-proxy

我的网络环境因为是扁平桥接所以下面是qdhcp设备。因为使用了namespace，在network node上每个namespace里都会有相应的iptables规则和网络设备。

先获取当前虚拟网络设备或获取网络名称空间
[root@controller ~]# ip netns
qdhcp-605a77b4-d232-4d0b-b915-d6572542c3d5 (id: 0)

获取这个虚拟网络设备的ip地址信息
[root@controller ~]# ip netns exec qdhcp-605a77b4-d232-4d0b-b915-d6572542c3d5 ip addr show 
2:ns-fda843d0-0e@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether fa:16:3e:bb:39:10 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.56.50/24 brd 192.168.56.255 scope global ns-fda843d0-0e
       valid_lft forever preferred_lft forever
    inet 169.254.169.254/16 brd 169.254.255.255 scope global ns-fda843d0-0e
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:febb:3910/64 scope link 
       valid_lft forever preferred_lft forever

可以看到169.254.169.254地址是绑定在qdhcp-605a77b4-d232-4d0b-b915-d6572542c3d5 (id: 0)虚拟设备上的ns-fda843d0-0e@if5这个网卡上的，然后再看看它的下一步路由

[root@controller ~]# ip netns exec qdhcp-605a77b4-d232-4d0b-b915-d6572542c3d5 ip route

default via 192.168.56.2 dev ns-fda843d0-0e 
169.254.0.0/16 dev ns-fda843d0-0e proto kernel scope link src 169.254.169.254 
192.168.56.0/24 dev ns-fda843d0-0e proto kernel scope link src 192.168.56.50 
这就可以理解它为什么能与192.168.56.0/24网络通信了

接下来ping下
ip netns exec qdhcp-605a77b4-d232-4d0b-b915-d6572542c3d5 ping 192.168.56.2
ip netns exec qdhcp-605a77b4-d232-4d0b-b915-d6572542c3d5 ping 169.254.169.254
结果都是通的

(3)Neutron Metadata Agent

network node上的metadata agent监听/var/lib/neutron/metadata_proxy

我这里的PIKE版本启用的是Neutron Metadata Agent, 控制节点上查看以下信息

[root@controller ~]# netstat -lxp |grep metadata
unix  2      [ ACC ]     STREAM     LISTENING     128073   6622/python2         /var/lib/neutron/metadata_proxy


[root@controller ~]# ps -f --pid 6622 |fold -s
UID         PID   PPID  C STIME TTY          TIME CMD
neutron    6622      1  0 02:39 ?        00:00:38 /usr/bin/python2 
/usr/bin/neutron-metadata-agent --config-file 
/usr/share/neutron/neutron-dist.conf --config-file /etc/neutron/neutron.conf 
--config-file /etc/neutron/metadata_agent.ini --config-dir 
/etc/neutron/conf.d/common --config-dir 
/etc/neutron/conf.d/neutron-metadata-agent --log-file 
/var/log/neutron/metadata-agent.log

该进程的功能是，根据请求头部的X-Forwarded-For和X-Quantum-Router-ID参数，向Quantum service查询虚拟机ID，然后向Nova Metadata服务发送请求（默认端口8775），消息头：X-Forwarded-For，X-Instance-ID、X-Instance-ID-Signature分别表示虚拟机的fixedIP，虚拟机ID和虚拟机ID的签名。

(4) Nova Metadata Service

Nova的metadata service是随着nova-api启动的。虚拟机访问169.254.169.254的返回内容，其实就是metadata服务向nova-conductor查询后，返回给network node的metadata agent，再由metadata agent返回给metadata proxy，然后返回给虚拟机的。

[root@controller ~]# netstat -lntup |grep 8775
tcp        0      0 0.0.0.0:8775            0.0.0.0:*               LISTEN      6263/python2   


You have new mail in /var/spool/mail/root
[root@controller ~]# ps -f --pid 6263
UID         PID   PPID  C STIME TTY          TIME CMD
nova       6263      1  1 02:29 ?        00:12:21 /usr/bin/python2 /usr/bin/nova-ap

为什么请求的IP地址是169.254.169.254？

这个IP地址在OpenStack中是不存在的，为什么可以获取到metadata呢？

这是因为Amazon的原因，最早metadata是通过亚马逊提出来的。

参考： Amazon Ec2-instance-metadata介绍

后来很多开源机构给亚马逊定制了一些操作系统的镜像，比如 ubuntu, fedora, centos 等等，而且将里面获取 metadta 的api地址也写死了。所以opentack为了兼容，保留了这个地址 169.254.169.254。然后通过iptables nat映射到真实的api上.

• 本文作者： GaryWu
• 本文链接： https://garywu520.github.io/2018/01/15/深入理解OpenStack-虚拟机元数据metadata/
• 版权声明： 本博客所有文章除特别声明外，均采用 MIT 许可协议。转载请注明出处！