良许Linux教程网 干货合集 详解OpenStack 的 metadata

详解OpenStack 的 metadata

在云计算中,Metadata 并不是一个陌生的概念。从字面上看,Metadata 是元数据的意思。而在云计算中,Metadata 服务能够向虚机注入一些额外的信息,这样虚机在创建之后可以有一些定制化的配置。在 OpenStack 中,Metadata 服务能够向虚机提供主机名,ssh 公钥,用户传入的一些定制数据等其他信息。这些数据被分为两类:metadata和user data,metadata主要包括虚机自身的一些数据比如hostname、ssh秘钥、网络配置等,而user data主要包括一些定制的脚本、命令等。但是不管是哪一种数据,openstack向虚机提供数据的方式是一致的。

image-20211219125108533

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 服务机制OpenStack 的 metadata 服务机制 图 1.虚拟机定义的 xml 文件

OpenStack 的 metadata 服务机制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

#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 计算服务在创建虚拟机时默认使用 config drive 机制。

清单 2

force_config_drive=true

用户可以在虚拟机中查看写入的 metadata 信息,如果客户操作系统支持通过标签访问磁盘的话,可以使用如下命令查看:

清单 3

#mkdir -p /mnt/config
#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 服务机制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 发送请求。 通过 router 发送请求 如果虚拟机所在 subnet 连接在了 router 上,那么发向 169.254.169.254 的报文会被发至 router。如图 4 所示,Neutron 通过在 router 所在网络命名空间添加 iptables 规则,将该报文转发至 9697 端口,而 neutron-ns-metadata-proxy 监听着该端口,所以报文被 neutron-ns-metadata-proxy 获取,进入上述后续处理和转发流程。

OpenStack 的 metadata 服务机制OpenStack 的 metadata 服务机制 图 4.router 所在网络命名空间的 iptables 规则

OpenStack 的 metadata 服务机制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 服务机制OpenStack 的 metadata 服务机制 图 6.虚拟机中的静态路由表

另外再查看 DHCP 服务器的 IP 配置信息,发现 DHCP 服务器配置了两个 IP,其中一个就是 169.254.169.254。与 router 类似的,Neutron 在 DHCP 网络命名空间中启动了监听 80 端口的 neutron-ns-metadata-proxy 服务,从而进入处理和转发请求的流程。

OpenStack 的 metadata 服务机制OpenStack 的 metadata 服务机制 图 7.DHCP 服务器的 IP 配置

总结

Metadata 服务为用户自定义配置虚拟机提供了有效的解决方案。本文剖析了 OpenStack 提供 metadata 服务的两种机制:config drive 和 RESTful 服务。Config drive 机制主要用于配置虚拟机的网络信息,包括 IP、子网掩码、网关等。当虚拟机无法通过 DHCP 正确获取网络信息时,config drive 是获取 metadata 信息的必要方式。如果虚拟机能够自动正确配置网络,那么可以通过 RESTful 服务的方式获取 metadata 信息。

以上就是良许教程网为各位朋友分享的Linu系统相关内容。想要了解更多Linux相关知识记得关注公众号“良许Linux”,或扫描下方二维码进行关注,更多干货等着你 !

img
本文由 良许Linux教程网 发布,可自由转载、引用,但需署名作者且注明文章出处。如转载至微信公众号,请在文末添加作者公众号二维码。
良许

作者: 良许

良许,世界500强企业Linux开发工程师,公众号【良许Linux】的作者,全网拥有超30W粉丝。个人标签:创业者,CSDN学院讲师,副业达人,流量玩家,摄影爱好者。
上一篇
下一篇

发表评论

邮箱地址不会被公开。 必填项已用*标注

联系我们

联系我们

公众号:良许Linux

在线咨询: QQ交谈

邮箱: yychuyu@163.com

关注微信
微信扫一扫关注我们

微信扫一扫关注我们

关注微博
返回顶部