Metadata 的概念

在创建虚拟机时，用户通常需要配置一些设置，如启用服务、安装软件包、添加SSH密钥、设置主机名等。在OpenStack中，这些配置信息被划分为两类：metadata和userdata。Metadata主要包含虚拟机自身的属性，如主机名、网络配置和SSH登录密钥，通常以键值对的形式表示。而userdata则包含一些命令或脚本。UserData通过文件传递，支持多种文件格式，包括gzip压缩文件、shell脚本和cloud-init配置文件等。虽然metadata和userdata不同，但OpenStack向虚拟机提供这两种信息的机制是一致的，只是虚拟机在获取信息后处理方式不同。因此，下文统一使用metadata来描述这些配置信息

通过深入了解 metadata 的服务机制，用户可以在适当的应用场景中选择正确的 metadata 配置方式，从而对虚拟机进行配置。此外，了解 metadata 服务机制能够为用户在 OpenStack 的部署、排错、维护提供帮助，提高工作效率

Metadata 的获取机制

在OpenStack中，虚拟机可以通过两种方式获取Metadata信息：Config Drive和Metadata RESTful服务。这两种机制都旨在提供虚拟机所需的配置信息，但它们的工作原理和实现方式略有不同。以下是对这两种机制的介绍和分析

Config drive

Config drive机制是OpenStack将metadata信息写入虚拟机的一个特殊配置设备中，然后在虚拟机启动时，自动挂载并读取metadata信息，以获取所需的配置信息。在客户端操作系统中，存储metadata的设备需要采用ISO9660或VFAT文件系统。具体实现方式会根据不同的Hypervisor和配置而有所差异，以libvirt为例：OpenStack将metadata写入libvirt的虚拟磁盘文件中，并指示libvirt将其虚拟为cdrom设备。当虚拟机启动时，客户操作系统中的cloud-init会自动挂载并读取该设备，然后根据读取到的内容对虚拟机进行配置

当然，要实现上述功能，需要宿主机和虚拟机镜像两者协同完成，它们需要各自满足一些条件

宿主机（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命令的路径。这些步骤可以确保Config Drive机制能够正确运行，以便虚拟机在启动时能够顺利获取和应用metadata信息。

虚拟机镜像

虚拟机镜像确保安装了cloud-init是很重要的，因为它可以简化并自动化虚拟机的初始化和配置过程。如果镜像中没有安装cloud-init，您可以自行编写脚本来模拟其功能，以在虚拟机启动期间挂载配置磁盘、读取数据、解析数据并根据数据内容执行相应动作。

#!/bin/bash

# 模拟 cloud-init 的功能，实现初始化和配置
# 挂载配置磁盘
mount /dev/sdb1 /mnt/config
# 读取数据文件
data_file="/mnt/config/userdata.txt"
# 解析数据并执行相应动作
while IFS= read -r line || [[ -n "$line" ]]; do
    # 示例：假设每行数据是一个命令
    eval "$line"
done < "$data_file"
# 卸载配置磁盘
umount /mnt/config

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中，提供metadata服务的关键组件包括nova-api-metadata服务、Neutron-metadata-agent和Neutron-ns-metadata-proxy。这些组件协同工作，以确保虚拟机可以通过REST API获取metadata信息。下面对他们协同工作做出分析

Nova-api-metadata

nova-api-metadata 启动了 RESTful 服务，负责处理虚拟机发送来的 REST API 请求。从请求的 HTTP 头部中取出相应的信息，获得虚拟机的 ID，继而从数据库中读取虚拟机的 metadata 信息，最后将结果返回。

Neutron-metadata-agent

ova-api-metadata服务是OpenStack Nova组件的一部分，负责处理虚拟机发送的metadata请求。
当虚拟机需要获取metadata信息时，它将请求发送到nova-api-metadata服务提供的RESTful接口。
nova-api-metadata服务将请求转发给Neutron-metadata-agent进行处理。

Neutron-ns-metadata-proxy

Neutron-ns-metadata-proxy是OpenStack Neutron组件的一部分，用于处理跨主机的metadata请求。
当Neutron-metadata-agent收到跨主机的metadata请求时，它会将请求发送给Neutron-ns-metadata-proxy。
Neutron-ns-metadata-proxy负责将请求转发到虚拟机所在的网络节点上的nova-api-metadata服务。
nova-api-metadata服务在网络节点上响应请求并提供metadata信息，然后将响应返回给Neutron-ns-metadata-proxy。
Neutron-ns-metadata-proxy将响应返回给Neutron-metadata-agent，最终将metadata信息传递给请求的虚拟机。

上图Metadata 请求发送流程

虚拟机发送metadata请求至Neutron-ns-metadata-proxy。
Neutron-ns-metadata-proxy收到请求后，在请求中添加router-id和network-id信息。
请求通过Unix Domain Socket被转发给Neutron-metadata-agent。
Neutron-metadata-agent根据请求中的router-id、network-id和IP信息，获取与之相关的端口（port）信息。
根据端口信息，Neutron-metadata-agent获取虚拟机的instance-id和tenant-id，并将它们加入到请求中。
请求被转发给nova-api-metadata。
nova-api-metadata利用instance-id和tenant-id获取虚拟机的metadata信息。
获取到metadata后，nova-api-metadata将其返回给Neutron-metadata-agent。
Neutron-metadata-agent将metadata信息返回给Neutron-ns-metadata-proxy。
Neutron-ns-metadata-proxy最终将metadata信息返回给发起请求的虚拟机。

此流程确保了虚拟机可以通过Neutron-ns-metadata-proxy获取到与自身相关的metadata信息，使得虚拟机能够动态地获取并应用所需的配置信息。

上面我们分析了各个服务之间转发请求的流程，那么现在只存在一个问题，整个获取 metadata 的路线就通畅了：虚拟机如何将请求发送至 neutron-ns-metadata-proxy？

在OpenStack中，假如我们来解析虚拟机发送metadata请求到169.254.169.254:80的过程，通常通过Neutron提供的两种方式之一来完成：通过router发送请求和通过DHCP发送请求：

通过Router发送请求：

在这种方式下，Neutron会为每个网络创建一个专用的路由器（router），该路由器会被配置为拦截所有发往169.254.169.254:80的请求。
当虚拟机需要获取metadata信息时，它会向169.254.169.254:80发送HTTP请求，这个请求会被虚拟机的网络栈捕获并发送到默认网关。
默认网关将请求发送到虚拟机所连接的网络中的路由器。
路由器会检测到请求是针对metadata服务的，并将其重定向到metadata代理服务（如Neutron-ns-metadata-proxy）所在的网络节点。

通过DHCP发送请求：

在这种方式下，Neutron会通过DHCP服务器为虚拟机分配IP地址时，将169.254.169.254:80作为metadata服务地址发送给虚拟机。
虚拟机在获取到IP地址后，会直接向169.254.169.254:80发送metadata请求，而无需经过路由器。
这种方式更加简单和直接，但需要确保DHCP服务器正确配置并发送metadata服务地址给虚拟机。

添加博主

微信号｜yfq940-

ITPub博客

OpenStack metadata服务机制剖析

最新文章