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的方式操作虚拟主机场景

wKioL1Y8QdPQLVrQAAEv8tj5v0Q147.jpg

2)如Centos或redhat,可以直接使用root用户,设置密码:

wKioL1Y8RguA_N5RAAFXMfn5H_I045.jpg


二.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 请求发送流程

wKiom1Y8R5GxEJqyAABvR-GP4eo803.jpg

如图 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 规则

wKiom1Y8SNTyPMxTAAEmEMw0484828.jpg

wKioL1Y8StGgMVdzAAEQhfe1yz4197.jpg

图 5.监听在 9697 端口上的 Neutron-ns-metadata-proxy 服务

wKioL1Y8S7yCJ5FFAAc6TvP4_N8465.jpg

上图圈红圈的是在单独一个网络命名空间查看,下面可以看到有三个网络命名空间,与图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 配置

图 7:DHCP 服务器的 IP 配置

图8.检查Metadata的服务是否正常

wKioL1Y8TSzhX_NWAACzXFnLlQ4798.jpg此图表示正常

总结:要保证虚拟主机与Metadata服务正常通讯,首先镜像需要安装cloud-init,当然各个服务也正常了,经常会出现l连接不上metadata服务,通常虚拟主机的端口不正常,这时可以使用重建来排除故障,上图的metadata-dhcp的主机名就是在创建虚拟主机时定义,还有key生效都必须保证cloud-init的存在,如图:

wKiom1Y8TxGClN8IAAGtJtJIZr0677.jpg

可参考网址:http://www.ibm.com/developerworks/cn/cloud/library/1509_liukg_openstackmeta/index.html


你可能感兴趣的:(Metadatar的作用,无法使用SSH的key,必须使用console)