工作原理

与 Ironic 集成

有关如何安装和配置 Ironic 驱动程序的信息，包括 IPA 驱动程序，请参阅 Ironic 驱动程序文档。

查找

启动时，代理程序通过将硬件配置文件发送到 Ironic 查找端点来确定其节点 UUID：/v1/lookup，从而在 Ironic 中执行查找。

心跳

成功查找其节点后，代理程序通过 /v1/heartbeat/{node_ident} 每 N 秒发送一次心跳，其中 N 是 Ironic conductor 的 agent.heartbeat_timeout 值乘以介于 .3 和 .6 之间的数字。

例如，如果您的 conductor 的 ironic.conf 包含

[agent]
heartbeat_timeout = 60

IPA 将每 20 到 36 秒发送一次心跳。这样做是为了确保在网络或 API 中断后重新连接的代理程序具有抖动。

在代理程序发送心跳后，conductor 将对节点执行任何所需的操作，包括查询已运行命令的状态。例如，启动带内清理任务或将镜像部署到节点。

检查

IPA 可以在启动时进行硬件检查，并将数据发布到 Ironic Inspector，通过 /v1/continue 端点。

编辑您的默认 PXE/iPXE 配置或 IPA 选项，这些选项嵌入在镜像中，并将 ipa-inspection-callback-url 设置为 Ironic Inspector 的完整端点，例如

ipa-inspection-callback-url=http://IP:5050/v1/continue

确保您的 DHCP 环境设置为默认情况下启动 IPA。

如果您使用新的内置 Ironic 带内检查，则只需设置一个收集器列表（请参阅 检查数据），例如

ipa-inspection-collectors=default,logs

然后，正确的回调 URL 将从 ipa-api-url 中的 Ironic URL 确定。

实例代理

对于基础设施操作员和云用户相同的情况，存在一种可以与实例中的代理程序一起安装的附加工具。这是 ironic-collect-introspection-data 命令，它允许处于 ACTIVE 状态的节点将更新的内省数据发布到 ironic-inspector。此功能需要将 ironic-inspector 配置为将 [processing]permit_active_introspection 设置为 True。例如

ironic-collect-introspection-data --inspection_callback_url http://IP:5050/v1/continue

或者，此命令也可以使用多播 DNS 功能来识别 Ironic Inspector 服务端点。例如

ironic-collect-introspection-data --inspection_callback_url mdns

对于希望接收定期更新的一些操作员来说，附加的守护程序模式可能很有用，形式为 [DEFAULT]introspection_daemon 布尔值配置选项。例如

ironic-collect-introspection-data --inspection_callback_url mdns --introspection_daemon

上述命令将尝试连接到内省，然后进入循环以每 300 秒发布一次。可以使用 [DEFAULT]introspection_daemon_post_interval 配置选项进行调整。

检查数据

作为检查过程的一部分，机器上的数据被收集并发送到 Ironic Inspector 进行存储。可以通过 内省数据 API 访问它。

数据的确切格式取决于启用的收集器，可以使用 ipa-inspection-collectors 内核参数进行配置。每个收集器都会将信息附加到生成的 JSON 对象。树内收集器是

default

默认启用的收集器。收集以下键

  • inventory - 硬件清单。

  • root_disk - 如果未提供根设备提示，则此机器的默认根设备，将用于部署。

  • configuration - 检查配置，一个包含两个键的对象

    • collectors - 启用收集器的列表。

    • managers - 启用的 硬件管理器 的列表：包含键 name 和 version 的项目。

  • boot_interface - 已弃用，应使用 inventory.boot.pxe_interface 字段。

日志

收集系统日志。为了产生有用的结果，它必须始终是收集器列表中的最后一个。

  • logs - base64 编码的 tarball，包含各种日志。

pci-devices

收集 PCI 设备列表。提供一个键

  • pci_devices - 包含键 vendor_id 和 product_id 的对象列表。

extra-hardware

使用 hardware 库收集有关系统的广泛事实列表，这是此收集器的必需依赖项。添加一个键

  • data - 来自 hardware-collect 工具的原始数据。是一个包含四个项目/项的列表的列表。建议将此收集器与 Ironic Inspector 侧的 extra_hardware 处理钩子一起使用，以将其转换为 extra 键中的嵌套字典。

    如果设置了 ipa-inspection-benchmarks，则将执行相应的基准测试，并提供其结果。

dmi-decode

收集来自 dmidecode 的信息。提供一个键

  • dmi DMI 信息，包含三个键：bios、cpu 和 memory。

numa-topology

收集 NUMA 拓扑信息。提供一个键

  • numa_topology，包含三个嵌套键

    • ram - 包含键 numa_node（节点 ID）和 size_kb 的对象列表。

    • cpus - 包含键 cpu（CPU ID）、numa_node（节点 ID）和 thread_siblings（同级线程列表）的对象列表。

    • nics - 包含键 name（NIC 名称）和 numa_node（节点 ID）的对象列表。

lldp

使用 LLDP 收集有关网络连接的信息。提供一个键

  • lldp_raw - 接口名称到原始类型长度值 (TLV) 记录列表的映射。

usb-devices

收集 USB 设备信息。添加一个键

  • usb_devices - 包含键 product、vendor 和 handle 的对象列表

硬件清单

IPA 使用其 硬件管理器 收集各种硬件信息，并在查找时将其发送到 Ironic，在 检查 时将其发送到 Ironic Inspector。

清单的确切格式取决于使用的硬件管理器。这是所有硬件管理器都应提供的基本格式。清单是一个字典（JSON 对象），至少包含以下字段

cpu

CPU 信息：model_name、frequency、count、architecture、flags 和 socket_count。

memory

RAM 信息：total（总大小，以字节为单位）、physical_mb（物理安装的内存大小，以 MiB 为单位，可选）。

注意

区别在于后者包括内核保留的内存区域，并且始终略大。它还与 Nova flavor 将包含此节点的内容相匹配，因此在检查过程中使用它而不是 total。

bmc_address

节点的 BMC（也称为 IPMI v4 地址）的 IPv4 地址，可选。

bmc_v6address

节点的 BMC（也称为 IPMI v6 地址）的 IPv6 地址，可选。

disks

磁盘块设备的列表，包含字段：name、model、size（以字节为单位）、rotational（布尔值）、wwn、serial、uuid、vendor、wwn_with_extension、wwn_vendor_extension、hctl 和 by_path（完整的磁盘路径，形式为 /dev/disk/by-path/<rest-of-path>）。

interfaces

网络接口列表，包含字段：name、mac_address、ipv4_address、lldp、vendor、product，以及可选的 biosdevname（BIOS 给定的 NIC 名称）和 speed_mbps（最大支持速度）。

注意

为了向后兼容，接口可能包含 lldp 字段。它们已被弃用，使用者应依赖于 lldp 检查收集器。

system_vendor

来自 SMBIOS 的系统供应商信息，如 dmidecode 报告：product_name、serial_number 和 manufacturer，以及一个 firmware 结构，包含字段 vendor、version 和 build_date。

boot

包含字段的启动信息：current_boot_mode（当前启动使用的启动模式 - BIOS 或 UEFI）和 pxe_interface（用于 PXE 启动的接口，如果有）。

hostname

系统主机名

注意

这很可能是由 DHCP 服务器设置的。如果 DHCP 服务器未设置它，则可能是 localhost。

镜像校验和

作为下载镜像以写入磁盘作为镜像部署过程的一部分，利用一系列字段来确定下载的镜像是否与用户使用 instance_info/image_checksum 值声明的预期镜像校验和匹配。

OpenStack 作为一个整体，已用 os_hash_value 和 os_hash_algo 字段替换了“遗留”checksum 字段，从而可以断言镜像校验和值。其优点是可以根据需要使用各种算法。

为了 Ironic 的目的，我们继续支持传递校验和字段，因为我们支持通过 URL 获取校验和。

我们还支持通过长度确定校验和。

该字段可用于指定

  • 用于检索校验和的 URL。

  • MD5（默认禁用，请参阅代理程序配置文件中的 [DEFAULT]md5_enabled）。

  • 基于 SHA-2 的 SHA256

  • 基于 SHA-2 的 SHA512

不支持基于 SHA-3 的校验和的自动确定，因为它们可以具有可变的校验和结果长度。在添加此文档时，基于 SHA-2 的校验和算法尚未从批准中撤回。如果您需要强制使用基于 SHA-3 的校验和，必须使用 os_hash_algo 设置以及 os_hash_value 设置。