节点清理¶
概述¶
Ironic 提供了两种节点清理模式：自动 和 手动。
自动 清理 在首次将工作负载分配给节点之前以及在硬件从一个工作负载回收至另一个工作负载时自动执行。
手动 清理 必须由操作员调用。
自动清理¶
当硬件从一个工作负载回收至另一个工作负载时，Ironic 会对节点执行自动清理，以确保其已准备好用于另一个工作负载。这可确保租户每次都能部署一致的裸机节点。
使用自动清理，节点在从 active -> available 状态移动时（当硬件从一个工作负载回收至另一个工作负载时）会移动到 cleaning 状态。节点在从 manageable -> available 状态移动时也会经历清理过程（在首次将工作负载分配给节点之前）。要全面了解所有进入清理状态的转换，请参阅 裸机状态机。
启用自动清理¶
要启用自动清理，请确保 ironic.conf 设置如下
[conductor]
automated_clean=true
这将启用基于您的硬件和 Ironic 用于节点的硬件类型，默认的一组清理步骤。默认情况下，这包括擦除先前租户的所有数据。
您还需要配置 清理网络。
清理步骤¶
确定清理步骤的方式取决于 conductor.automated_cleaning_step_source 的值
- 自动生成的清理步骤 (‘autogenerated’)
这是 Ironic 自动清理的默认模式，它提供了最初在 Kilo 中实现的原始 Ironic 行为。
步骤是从硬件接口收集的，并按优先级从高到低排序，其中较大的整数表示较高的优先级。如果跨接口的优先级之间存在冲突，则使用以下解析顺序：Power、Management、Deploy、BIOS 和 RAID 接口。
您可以通过将该清理步骤的优先级设置为零或
None来跳过一个清理步骤。您可以通过修改清理步骤的整数优先级来重新排序清理步骤。- 基于 Runbook 的清理步骤 (‘runbook’)
当使用 用于清理和维护的 Runbook 进行自动清理时，确切的步骤及其顺序在 runbook 中定义。基于优先级的排序不适用；步骤按 runbook 中指定的顺序执行。
如果未分配 runbook 来执行节点的清理，并且启用了 automated_cleaning，则机器将无法清理并进入
clean failed状态。- 混合模式 (‘hybrid’)
如果为正在清理的节点配置了用于清理的 runbook，则此模式使用基于 runbook 的清理方法。在此模式下，如果未配置用于清理的 runbook，Ironic 将回退到自动生成清理步骤。
有关如何更改自动生成清理步骤的优先级，请参阅 如何更改清理步骤的优先级？
有关配置清理 runbook的完整详细信息，请参阅 使用 Runbook 配置自动清理。
存储清理选项¶
警告
默认情况下，Ironic 的存储清理选项将在自动清理期间永久删除磁盘上的数据。
特定于存储的清理步骤是 erase_devices、erase_devices_metadata 和（在 Yoga 中添加）erase_devices_express。
erase_devices 旨在确保以可用最安全的方式删除数据。在支持硬件辅助安全擦除的设备上（许多 NVMe 和一些 ATA 驱动器），这是首选选项。如果硬件辅助安全擦除不可用，并且 deploy.continue_if_disk_secure_erase_fails 设置为 True，清理将回退到使用 shred 覆盖设备的内容。默认情况下，如果启用 erase_devices 并且 Ironic 无法擦除设备，清理将失败以确保数据安全。
注意
erase_devices 可能需要很长时间（数小时甚至数天）才能完成，除非所有系统中的设备都支持快速的硬件辅助数据擦除。
erase_devices_metadata 清理步骤不如 erase_devices 提供如此强大的不可逆数据破坏保证。但是，它具有运行时间相对较快（几秒钟到几分钟）的优点。它通过破坏存储设备的元数据而不擦除所有数据本身来运行。在运行 erase_devices_metadata 后尝试恢复数据可能是成功的，但肯定需要相关的专业知识和专用工具。
最后，erase_devices_express 结合了 erase_devices 和 erase_devices_metadata 的一些优点。如果可用（目前仅支持 NVMe 设备），它会尝试利用硬件辅助数据擦除功能。如果不可用硬件辅助数据擦除，它将回退到设备的元数据擦除（与 erase_devices_metadata 相同）。可以将其视为一种时间优化的存储清理模式，旨在在短时间内执行尽可能彻底的数据擦除。此清理步骤特别适用于具有混合 NVMe-HDD 存储配置的环境，因为它允许快速且安全地擦除存储在 NVMe 上的数据，并结合快速但更基本的基于元数据的 HDD 上的数据擦除。
默认情况下，Ironic 将在清理的早期使用 erase_devices_metadata 以提高可靠性（确保节点无法重新启动到其旧的工作负载），并在清理的后期使用 erase_devices 以安全擦除驱动器；erase_devices_express 已禁用。
操作员可以使用 deploy.erase_devices_priority 和 deploy.erase_devices_metadata_priority 更改默认设备擦除方法的优先级，或通过设置 0 完全禁用它们。可以通过 conductor.clean_step_priority_override 选项修改其他清理步骤的优先级。例如，以下配置片段禁用了 erase_devices_metadata 和 erase_devices，并改为执行 erase_devices_express 擦除步骤。
[deploy]
erase_devices_priority=0
erase_devices_metadata_priority=0
[conductor]
clean_step_priority_override=deploy.erase_devices_express:95
这可确保禁用 erase_devices 和 erase_devices_metadata，以便不会两次清理存储，然后为 erase_devices_express 分配一个非零优先级，从而启用它。在优先级覆盖中指定的任何非零优先级都有效；较大的值将导致磁盘擦除在清理过程中更早运行（如果启用了多个步骤）。
可以修改 Ironic 如何擦除磁盘的其他配置如下。此列表可能不完整。请参阅 ironic.conf.sample（链接）以获取更多详细信息
deploy.enable_ata_secure_erase，默认Truedeploy.enable_nvme_secure_erase，默认True
警告
Ironic 自动清理默认配置为安全配置。除非您有特殊的硬件需求或独特的用例，否则不应修改相关设置。错误配置可能导致数据泄露漏洞。
使用 Runbook 配置自动清理¶
从 2025.2/Flamingo 版本开始，操作员可以配置 Ironic 使用 runbook 进行自动清理，而不是依赖自动生成的步骤。这提供了对清理过程的更多控制，并确保跨节点的保持一致性。
警告
在使用 runbook 进行自动清理时，请确保它们包括适当的安全措施，例如磁盘擦除。Ironic 不会验证 runbook 是否执行磁盘清理操作或任何其他特定的清理步骤。
Trait 匹配
与 runbook 一样，您必须在节点上具有与 runbook 名称匹配的 trait。这允许使用 fail-safe，以防止危险的特定于硬件的清理步骤在不兼容的硬件上运行。
您可以通过将 conductor.automated_cleaning_runbook_validate_traits 设置为 False 来禁用此检查。
openstack baremetal node add trait myNode CUSTOM_RB_EXAMPLE
配置清理 Runbook
Runbook 可以在三个级别配置（从最具体到最不具体）
每个节点:
操作员可以使用以下命令设置每个节点的清理 runbook 覆盖
openstack baremetal node set myNode --driver-info cleaning_runbook=CUSTOM_RB_EXAMPLE
警告
自定义每个节点的清理需要将
conductor.automated_cleaning_runbook_from_node设置为 True。启用节点级 runbook 允许节点所有者通过使用 noop runbook 覆盖清理行为。仅在受信任的环境中启用此功能。
每个资源类:
操作员可以使用
conductor.automated_cleaning_runbook_by_resource_class构建资源类到 runbook 的映射列表，从而设置每个资源类的 runbook。这些 runbook 用于清理该资源类中的任何节点，而这些节点没有节点级覆盖。在此示例中，large 资源类使用
CUSTOM_FULL_CLEAN，而 small 资源类使用CUSTOM_QUICK_CLEAN。这些资源类中的节点仍然需要具有与 runbook 名称匹配的 trait。[conductor] automated_cleaning_runbook_by_resource_class = large:CUSTOM_FULL_CLEAN,small:CUSTOM_QUICK_CLEAN
全局默认值：操作员还可以配置全局默认值，该默认值用于没有配置更具体的 runbook（例如节点级覆盖或资源类映射）的节点。
在此示例中，环境中清理的任何节点都将使用
CUSTOM_DEFAULT_CLEAN。除非禁用 trait 映射，否则所有节点还需要具有也命名为CUSTOM_DEFAULT_CLEAN的 trait 才能成功清理。[conductor] automated_cleaning_runbook = CUSTOM_DEFAULT_CLEAN
创建并分配 Runbook
创建一个包含必要的清理步骤的 runbook
baremetal runbook create --name CUSTOM_SECURE_ERASE \
--steps '[{"interface": "deploy", "step": "erase_devices", "args": {}, "order": 0}]'
确保节点具有匹配的 trait
baremetal node add trait <node> CUSTOM_SECURE_ERASE
管理界面¶
名称 |
细节 |
优先级 |
可停止 |
参数 |
|---|---|---|---|---|
|
清除 iDRAC 作业队列。 |
0 |
否 |
|
|
清除所有安全启动密钥。 |
0 |
否 |
|
|
(已弃用) 导出服务器的配置。 将运行该步骤的服务器的配置导出到指定的格式和位置。 使用来自 sushy-oem-idrac 库的 Dell 服务器配置配置文件 (SCP) 获取用于克隆的所有配置。 |
0 |
否 |
|
|
(已弃用) 导入并将配置应用于服务器。 从存储中获取给定位置的预创建配置，并将其导入到给定的服务器。使用Dell的服务器配置配置文件 (SCP)。 |
0 |
否 |
|
|
一次性导入和导出配置。 从存储中获取给定名称的预创建配置，并将其导入到给定的服务器。之后，将服务器的配置导出，并以Ironic配置的特定格式存储在指示的存储中。 |
0 |
否 |
|
|
将iDRAC重置为已知良好状态。 通过重置iDRAC并清除其作业队列，将iDRAC重置为已知良好状态。 |
0 |
否 |
|
|
重置iDRAC。 |
0 |
否 |
|
|
将安全启动密钥重置为出厂默认值。 |
0 |
否 |
|
|
使用Redfish Manager资源设置BMC时钟。 |
0 |
否 |
|
|
更新节点上的固件。 |
0 |
否 |
|
名称 |
细节 |
优先级 |
可停止 |
参数 |
|---|---|---|---|---|
|
激活iLO Advanced许可证。 |
0 |
否 |
|
|
将签名的HTTPS证书添加到iLO。 |
0 |
否 |
|
|
清除所有安全启动密钥。 清除所有安全启动密钥。此操作仅支持HP Proliant Gen9及更高版本的服务器。 |
0 |
否 |
|
|
创建CSR。 |
0 |
否 |
|
|
将BIOS设置重置为默认值。 将BIOS重置为默认设置。此操作目前仅支持HP Proliant Gen9及更高版本的服务器。 |
10 |
否 |
|
|
重置iLO。 |
0 |
否 |
|
|
重置iLO密码。 |
30 |
否 |
|
|
将安全启动密钥重置为出厂默认值。 将安全启动密钥重置为出厂默认值。此操作仅支持HP Proliant Gen9及更高版本的服务器。 |
20 |
否 |
|
|
更新安全参数。 |
0 |
否 |
|
|
更新Auth Failure Logging Threshold安全参数。 |
0 |
否 |
|
|
更新固件。 |
0 |
否 |
|
|
使用Smart Update Manager (SUM)进行清理步骤以更新固件 |
0 |
否 |
|
|
更新最小密码长度安全参数。 |
0 |
否 |
|
名称 |
细节 |
优先级 |
可停止 |
参数 |
|---|---|---|---|---|
|
激活iLO Advanced许可证。 |
0 |
否 |
|
|
将签名的HTTPS证书添加到iLO。 |
0 |
否 |
|
|
清除iLO中列表中提供的证书。 |
0 |
否 |
|
|
清除所有安全启动密钥。 清除所有安全启动密钥。此操作仅支持HP Proliant Gen9及更高版本的服务器。 |
0 |
否 |
|
|
创建CSR。 |
0 |
否 |
|
|
擦除节点上的所有驱动器。 此方法对节点中所有受支持的物理驱动器执行带外清理磁盘擦除。无法对逻辑驱动器执行此擦除。 |
0 |
否 |
|
|
安全擦除整个系统。 一键安全擦除过程会重置iLO并删除所有存储在那里的许可证，重置BIOS设置，以及删除存储在系统上的所有Active Health System (AHS)和保修数据。它还会擦除受支持的非易失性存储数据并删除任何部署设置配置文件。 |
0 |
否 |
|
|
将BIOS设置重置为默认值。 将BIOS重置为默认设置。此操作目前仅支持HP Proliant Gen9及更高版本的服务器。 |
10 |
否 |
|
|
重置iLO。 |
0 |
否 |
|
|
重置iLO密码。 |
30 |
否 |
|
|
将安全启动密钥重置为出厂默认值。 将安全启动密钥重置为出厂默认值。此操作仅支持HP Proliant Gen9及更高版本的服务器。 |
20 |
否 |
|
|
更新安全参数。 |
0 |
否 |
|
|
更新Auth Failure Logging Threshold安全参数。 |
0 |
否 |
|
|
更新固件。 |
0 |
否 |
|
|
使用Smart Update Manager (SUM)进行清理步骤以更新固件 |
0 |
否 |
|
|
更新最小密码长度安全参数。 |
0 |
否 |
|
名称 |
细节 |
优先级 |
可停止 |
参数 |
|---|---|---|---|---|
|
清除所有安全启动密钥。 |
0 |
否 |
|
|
将安全启动密钥重置为出厂默认值。 |
0 |
否 |
|
|
恢复节点的BIOS配置。 |
0 |
否 |
|
|
使用Redfish Manager资源设置BMC时钟。 |
0 |
否 |
|
|
更新节点上的固件。 |
0 |
否 |
|
名称 |
细节 |
优先级 |
可停止 |
参数 |
|---|---|---|---|---|
|
清除所有安全启动密钥。 |
0 |
否 |
|
|
将安全启动密钥重置为出厂默认值。 |
0 |
否 |
|
|
使用Redfish Manager资源设置BMC时钟。 |
0 |
否 |
|
|
更新节点上的固件。 |
0 |
否 |
|
Firmware Interface¶
名称 |
细节 |
优先级 |
可停止 |
参数 |
|---|---|---|---|---|
|
使用组件设置更新节点上的固件。 |
0 |
否 |
|
Bios Interface¶
名称 |
细节 |
优先级 |
可停止 |
参数 |
|---|---|---|---|---|
|
将BIOS设置应用于节点。 |
0 |
否 |
|
|
将节点的BIOS设置重置为出厂默认值。 |
0 |
否 |
名称 |
细节 |
优先级 |
可停止 |
参数 |
|---|---|---|---|---|
|
将提供的配置应用于节点。 |
0 |
否 |
|
|
将BIOS设置重置为出厂配置。 |
0 |
否 |
名称 |
细节 |
优先级 |
可停止 |
参数 |
|---|---|---|---|---|
|
将BIOS配置应用于给定的节点。 此方法从settings参数获取BIOS设置，并将其应用于给定的节点。完成BIOS配置后，可以调用self.cache_bios_settings()将节点的BIOS相关信息与应用于节点的BIOS配置同步。它还会验证给定的设置，并在设置无效的BIOS配置时管理故障。如果需要密码才能更新BIOS配置，则它将从driver_info属性中获取。 |
0 |
否 |
|
名称 |
细节 |
优先级 |
可停止 |
参数 |
|---|---|---|---|---|
|
将BIOS设置应用于节点。 |
0 |
否 |
|
|
将节点的BIOS设置重置为出厂默认值。 |
0 |
否 |
Raid Interface¶
名称 |
细节 |
优先级 |
可停止 |
参数 |
|---|---|---|---|---|
|
使用agent ramdisk在裸机上创建RAID配置。 此方法在给定的节点上创建RAID配置。 |
0 |
否 |
|
|
删除给定节点上的RAID配置。 |
0 |
否 |
名称 |
细节 |
优先级 |
可停止 |
参数 |
|---|---|---|---|---|
|
在节点上创建RAID配置。 此方法从node.target_raid_config读取RAID配置，并创建所有逻辑磁盘。 |
0 |
否 |
|
|
删除节点上的RAID配置。 |
0 |
否 |
名称 |
细节 |
优先级 |
可停止 |
参数 |
|---|---|---|---|---|
|
使用agent ramdisk在裸机上创建RAID配置。 此方法在给定的节点上创建RAID配置。 |
0 |
否 |
|
|
删除RAID配置。 |
0 |
否 |
名称 |
细节 |
优先级 |
可停止 |
参数 |
|---|---|---|---|---|
|
创建RAID配置。 此方法在给定的节点上创建RAID配置。 |
0 |
否 |
|
|
删除RAID配置。 |
0 |
否 |
名称 |
细节 |
优先级 |
可停止 |
参数 |
|---|---|---|---|---|
|
在节点上创建RAID配置。 此方法从node.target_raid_config读取RAID配置，并创建所有逻辑磁盘。 |
0 |
否 |
|
|
删除节点上的RAID配置。 |
0 |
否 |
Manual cleaning¶
Manual cleaning通常用于处理长时间运行、手动或破坏性任务，操作员希望在将第一个工作负载分配给节点之前或在工作负载之间执行这些任务。在启动手动清理时，操作员会指定要执行的清理步骤。手动清理只能在节点处于manageable状态时执行。完成手动清理后，节点将再次处于manageable状态。
Ironic在4.4 (Mitaka系列)版本中添加了对手动清理的支持。
设置¶
为了使手动清理起作用，您可能需要配置Cleaning Network。
通过API启动手动清理¶
手动清理只能在节点处于manageable状态时执行。REST API请求可在API版本1.15及更高版本中获得
PUT /v1/nodes/<node_ident>/states/provision
(更多信息可在此处获得。)
此API将允许操作员通过‘target’: ‘clean’将节点直接从manageable状态置于cleaning配置状态。PUT请求还需要指定‘clean_steps’参数。这是一个清理步骤的有序列表。清理步骤由字典（JSON）表示，形式如下
{
"interface": "<interface>",
"step": "<name of cleaning step>",
"args": {"<arg1>": "<value1>", ..., "<argn>": "<valuen>"}
}
对于所有步骤，‘interface’和‘step’键是必需的。如果清理步骤方法接受关键字参数，则可以指定‘args’键。它是一个关键字变量参数的字典，每个关键字参数条目是 <name>: <value>。
如果任何步骤缺少必需的关键字参数，将不会执行手动清理，并且节点将被置于 clean failed 置备状态，并附带相应的错误消息。
如果在清理过程中，某个清理步骤确定其关键字参数不正确，将执行所有先前的步骤，然后将节点置于 clean failed 置备状态，并附带相应的错误消息。
此 API 请求体的示例
{
"target":"clean",
"clean_steps": [{
"interface": "raid",
"step": "create_configuration",
"args": {"create_nonroot_volumes": false}
},
{
"interface": "deploy",
"step": "erase_devices"
}]
}
在上面的示例中，节点的 RAID 接口将配置硬件 RAID，而不使用非 root 卷，然后擦除所有设备（按此顺序）。
例如，使用 Redfish 管理接口设置 BMC 时钟
{
"target": "clean",
"clean_steps": [{
"interface": "management",
"step": "set_bmc_clock",
"args": {"datetime": "2025-07-22T12:34:56+00:00"}
}]
}
此步骤要求节点使用 redfish 管理接口，并且 Redfish 服务在 Manager Resource 下暴露 DateTime 和 DateTimeLocalOffset 字段。
或者，您可以指定 runbook 代替 clean_steps
{
"target":"clean",
"runbook": "<runbook_name_or_uuid>"
}
指定的 runbook 必须与节点的某个特性匹配才能使用。
通过“openstack baremetal”CLI 启动手动清理¶
从 Bare Metal API 版本 1.15 开始，可以通过 baremetal node clean 命令进行手动清理。
必须指定参数 --clean-steps。其值为以下之一
JSON 字符串
指向 JSON 文件的路径，其内容传递给 API
-从 stdin 读取。这允许将 clean steps 管道输入。在 Unix 实用程序中使用“-”表示 stdin 很常见。
以下示例假定通过 OS_BAREMETAL_API_VERSION 环境变量设置了 Bare Metal API 版本。（另一种方法是在命令中添加 --os-baremetal-api-version 1.15。）
export OS_BAREMETAL_API_VERSION=1.15
使用 JSON 字符串执行此操作的示例
baremetal node clean <node> \
--clean-steps '[{"interface": "deploy", "step": "erase_devices_metadata"}]'
baremetal node clean <node> \
--clean-steps '[{"interface": "deploy", "step": "erase_devices"}]'
或使用文件
baremetal node clean <node> \
--clean-steps my-clean-steps.txt
或使用 stdin
cat my-clean-steps.txt | baremetal node clean <node> \
--clean-steps -
用于手动清理的 Runbook¶
操作员现在可以使用 runbook 代替传递 clean steps 列表。Runbook 是策划的步骤列表，可以与节点通过特性关联，从而简化了在类似节点上执行一致清理操作的过程。
要使用 runbook 进行手动清理
baremetal node clean <node> --runbook <runbook_name_or_uuid>
必须先创建 runbook 并将其与节点关联。只能使用与节点特性匹配的 runbook 来清理该节点。有关 runbook API 用法的更多信息，请参见 用于清理和维护的 Runbook。
清理网络¶
如果您使用的是 Neutron DHCP 提供程序（默认），您还需要确保已配置清理网络。此网络将用于引导用于带内清理的 ramdisk。您可以使用与您的租户网络相同的网络。有关设置清理网络的步骤，请参见 配置 Bare Metal 服务以进行清理。
带内与带外¶
Ironic 使用两种主要方法对节点执行操作：带内和带外。Ironic 支持使用两种方法来清理节点。
带内¶
带内步骤由 Ironic 通过使用部署接口向节点上运行的 ramdisk 发出 API 调用来执行。目前，所有部署接口都支持带内清理。默认情况下，ironic-python-agent 附带一个最小的清理配置，仅擦除磁盘。但是，您可以添加自己的清理步骤，或者使用自定义硬件管理器覆盖默认清理步骤。
带外¶
带外是您的管理控制器执行的操作，例如 IPMI、iLO 或 DRAC。带外步骤将由 Ironic 使用电源或管理接口执行。执行哪些步骤取决于硬件类型和硬件本身。
对于受 iLO 硬件类型支持的带外清理操作，请参阅 节点清理支持。
常见问题解答¶
清理步骤的排序方式？¶
对于自动清理，清理步骤按整数优先级排序，其中较大的整数具有更高的优先级。如果跨硬件接口的优先级之间存在冲突，则使用以下解析顺序
电源接口
管理接口
部署接口
BIOS 接口
RAID 接口
对于手动清理，应按所需的顺序指定清理步骤。
如何跳过清理步骤？¶
对于自动清理，优先级为零或 None 的清理步骤将被跳过。
如何更改清理步骤的优先级？¶
对于手动清理或基于 runbook 的清理，请按所需的顺序指定清理步骤。
对于自动清理，这取决于清理步骤是带外还是带内。
大多数带外清理步骤都有一个用于优先级的显式配置选项。
更改带内（ironic-python-agent）清理步骤的优先级需要使用 conductor.clean_step_priority_override，这是一个配置选项，允许使用多个配置值指定每个步骤的优先级
[conductor]
clean_step_priority_override=deploy.erase_devices_metadata:123
clean_step_priority_override=management.reset_bios_to_default:234
clean_step_priority_override=management.clean_priority_reset_ilo:345
可以根据需要多次指定此参数，以定义多个清理步骤的优先级 - 这些值将被组合。
正在运行哪个清理步骤？¶
要检查节点正在执行或尝试执行并失败的清理步骤，请运行以下命令；它将在节点的 driver_internal_info 字段中返回值
baremetal node show $node_ident -f value -c driver_internal_info
clean_steps 字段将包含所有剩余步骤及其优先级的列表，并且列出的第一个步骤是当前正在进行或节点在进入 clean failed 状态之前失败的步骤。
我应该禁用自动清理吗？¶
建议对 Ironic 部署启用自动清理，但是，启用它有一些权衡。例如，Ironic 无法将新实例部署到当前正在清理的节点，并且清理可能是一个耗时的过程。为了缓解这种情况，我们建议使用支持 NVMe 安全擦除（基于 nvme-cli format 命令）或支持加密 ATA 安全擦除的 ATA 驱动器的 NVMe 驱动器，因为通常部署接口中的 erase_devices 步骤是完成所有清理步骤中最耗时的步骤。
为什么在节点正在清理时我无法打开/关闭节点？¶
在清理期间，节点可能会执行不应中断的操作，例如 BIOS 或固件更新。因此，禁止操作员在节点正在清理时通过 Ironic API 更改电源状态。
高级主题¶
父节点¶
parent_node 的概念是指配置了“父节点”的节点，并允许对父节点执行操作，在某些情况下，需要考虑子节点。主要是在与子节点相关的执行清理步骤方面。
在这种情况下，子节点主要是指具有自己管理控制器的嵌入式设备。例如“SmartNIC”或数据处理单元 (DPU)，它们可能有自己的管理控制器和电源控制。
父节点和子节点之间的关系在子节点上建立。示例
baremetal node set --parent-node <parent_node_uuid> <child_node_uuid>
子节点清理步骤执行¶
您可以执行对子节点执行操作的步骤。例如，打开它们（通过步骤 power_on），关闭它们（通过步骤 power_off），或向 BMC 发出重启信号（通过步骤 reboot）。
例如，如果您需要显式关闭子节点电源，然后再执行另一个步骤，则可以使用如下步骤来表达它
[{
"interface": "power",
"step": "power_off",
"execute_on_child_nodes": True,
"limit_child_node_execution": ['f96c8601-0a62-4e99-97d6-1e0d8daf6dce']
},
{
"interface": "deploy",
"step": "erase_devices"
}]
正如您所想，此步骤将关闭单个子节点的电源，因为已表达对已知单个节点的限制，并且该子节点的电源将通过管理接口关闭。之后，将在父节点上执行 erase_devices 步骤。
注意
虽然部署步骤框架也支持 execute_on_child_nodes 和 limit_child_node_execution 参数，但所有步骤框架都存在一个基本限制，即子节点步骤执行的目的是同步操作，这些操作不依赖于任何子节点上运行的 ironic-python-agent。此约束将来可能会更改。
带有子节点的电源管理¶
子节点和父节点的组合具有特殊的电源考虑因素，并且这些设备正在行业中不断发展。也就是说，Ironic 项目采取了一种显式尝试“打开”任何父节点的方法，当收到“打开”子节点的请求时。可以通过设置 driver_info 参数 has_dedicated_power_supply 设置为 True 来绕过此设置，以认识到一些硬件供应商正在努力为这些类别的设备提供独立的电源，以满足其客户的使用案例。
与“打开”子节点的请求类似，当请求关闭“父节点”的电源时，Ironic 将向所有子节点发出“关闭”电源命令，除非子节点在其 driver_info 字段中设置了 has_dedicated_power_supply 选项。
故障排除¶
如果节点上的清理失败，该节点将被置于 clean failed 状态。如果失败发生在运行清理步骤时，该节点也会被置于维护模式，以防止 Ironic 对该节点采取任何操作。操作员应验证节点是否没有永久损坏，并且在删除维护模式之前没有进程仍在节点上运行。
注意
旧版本的 Ironic 即使在没有运行任何清理步骤时，也可能会将节点置于维护模式。
处于 clean failed 状态的节点不会被关闭，因为该节点可能处于可能导致关闭节点损坏或删除有关清理失败性质的有用信息的状态。
可以将 clean failed 节点移动到 manageable 状态，在该状态下，Nova 无法对其进行调度，您可以安全地尝试修复该节点。要将节点从 clean failed 移动到 manageable
baremetal node manage $node_ident
现在您可以对该节点执行操作，例如更换损坏的磁盘驱动器。
确定清理步骤失败的原因的策略包括检查 Ironic conductor 日志、查看仍在运行的 ironic-python-agent 上的日志（如果带内步骤失败），或对节点执行常规硬件故障排除。
修复节点后，您可以将节点移回 available 状态，以允许 Nova 对其进行调度。
# First, move it out of maintenance mode
baremetal node maintenance unset $node_ident
# Now, make the node available for scheduling by Nova
baremetal node provide $node_ident
该节点将从头开始自动清理，并在完成后移动到 available 状态。
