从卷启动 - 参考驱动程序¶

https://bugs.launchpad.net/ironic/+bug/1559691

为了支持从远程托管和/或控制的存储设备（例如通过 SAN 或 cinder iSCSI 目标）启动 ironic 节点，ironic 需要进行更改，以帮助促进和启用驱动程序利用远程存储作为启动卷。

问题描述¶

目前，ironic 的参考驱动程序中没有支持从远程卷启动节点的功能。
由于缺乏此支持，用户的能力和可用性受到限制。提供此功能允许部署利用更大的能力。

从卷启动场景¶

为了便于分阶段实施支持，此规范被分解为多个部分。虽然这些更改似乎应仅限于启动和部署接口，但最终它们需要大量的底层更改才能提供必要的功能。

由于潜在的连接方法和配置多种多样，我们确定的场景似乎适合在参考驱动程序中实施。我们主要关注 cinder 的使用，但打算使存储底层可插拔且通用。

此规范不涵盖对 MultiPath IO（有时称为 MPIO）的支持处理。我们认为目前这超出了 Ironic 的范围。

此外，也不涵盖使用 UEFI HTTP 启动支持的要求，该要求是在 ironic mitaka midcycle 期间提出的。使用 UEFI HTTP 启动将简单地加载 iPXE UEFI 启动加载程序，因此与现有功能相比，这将是一种冗余功能。

以下是各种从卷启动场景。这些场景旨在提供条件和要求的明确定义。

场景 1 - 从 iSCSI 卷 iPXE 启动¶

条件

节点启动默认通过 ironic conductor 控制的 iPXE 进行网络启动。这类似于 PXE 驱动程序的 netboot 选项。

预计使用元数据服务，因为目前不支持配置驱动器。

不支持配置驱动器。

说明：这是 cinder 中最小的新卷和新卷扩展大小的限制。在以后某个时间点，这可能是一种功能，但超出初始实施范围。

iPXE 版本足以支持从 iSCSI 目标启动。

操作系统已通过外部方式部署到预期的 iSCSI 启动卷。

由于需要 iPXE 启动，因此不支持租户网络隔离。

将来，可以创建一个框架或代理来启用租户网络隔离，但目前认为这超出范围。

节点由操作员配置，节点属性 node.properties['capabilities'] 设置为 iscsi_boot，其值为 true，以便节点验证成功。

节点在 volume_targets 表中定义了一个具有 boot_index 值为 0 的卷目标。

要求

存储驱动程序接口

需要存储驱动程序/提供程序接口，以便在发生故障或硬件配置更改时支持系统恢复。

iPXE 模板和生成逻辑更改。

在部署和 PXE 驱动程序模块中实施底层逻辑，以适当处理从卷启动场景中启动节点。

场景 2 - 从光纤通道 over Ethernet (FCoE) iPXE 启动¶

条件

节点启动默认通过 ironic conductor 控制的 iPXE 进行网络启动。类似于 PXE 驱动程序的 netboot 选项。

预计使用元数据服务。

不支持配置驱动器。

操作系统已通过外部方式部署到预期的启动卷。

由于 iPXE 要求，不支持租户网络隔离。

节点配置了节点属性 node.properties['capabilities'] 设置为 fiberchannel_boot，其值为 true，以便节点验证成功。

节点在 volume_targets 表中定义了一个具有 boot_index 值为 0 的卷目标。

要求

场景 1 - 从 iSCSI 卷 iPXE 启动已实施

FCoE 用例中 iPXE 模板生成逻辑的补充

场景 3 - 通过硬件主机总线适配器 (HBA) 启动到卷¶

场景涉及启动到本地卷，但是，预计该卷已预先填充可启动的操作系统。不期望进行卷部署操作。

此场景基于环境和节点固件设置能够直接启动到通过 HBA 提供的卷的期望，一旦上电。

条件

预计使用元数据服务。

不支持配置驱动器。

节点启动默认到块存储设备。

支持租户网络隔离，因为此场景不需要 iPXE 启动来正常运行主机。

操作系统已通过外部方式部署到预期的启动卷。

基础设施和 HBA BIOS 配置使得节点将启动到作为启动卷提供的逻辑单元号 (LUN)。

节点配置了节点属性 node.properties['capabilities'] 设置为 hba_boot，其值为 true，以便节点验证成功。

节点在 volume_targets 表中定义了一个具有 boot_index 值为 0 的卷目标。

要求

创建驱动程序部署方法功能，在正常情况下执行无操作，并在用户请求部署节点时将下一个启动状态默认为本地磁盘。

场景 4 - 通过主机总线适配器 (HBA) 启动到卷并进行镜像部署¶

场景涉及启动到本地卷，其中需要通过 Ironic 的机制将卷写入。

条件

不需要元数据服务。

支持配置驱动器。

节点启动到块存储设备。

支持租户网络隔离，因为此场景不需要 iPXE 启动来正常运行主机。

基础设施和 HBA BIOS 配置使得节点将启动到作为启动卷提供的 LUN。

节点配置了节点属性 node.properties['capabilities'] 设置为 hba_boot，其值为 true。

节点配置了节点实例信息 node.instance_info['force_deployment'] 参数设置为 true。

要求

预计此方法与场景 3 - 通过硬件主机总线适配器 (HBA) 启动到卷中定义的场景基本相同，但是通过包含仅在明确请求从卷启动时才调用部署阶段的默认逻辑来实现。

场景 5 - iPXE 启动到 NFS 根卷¶

场景涉及使用由 conductor 主机托管的内核和 ramdisk 镜像，以便启用节点通过 iPXE 启动，并提供足够的命令行参数以在启动序列期间启用根卷的附加。

这是一个逻辑进展，因为用户已经表明他们已在下游启用了类似启动功能。

条件

预计使用元数据服务。

不支持配置驱动器。

节点启动默认到 iPXE。

节点启动使用由 conductor 托管的内核和 ramdisk。

操作系统已通过外部方式部署到预期的启动卷。

由于需要 iPXE，因此不支持租户网络隔离。

节点配置了节点属性 node.properties['capabilities'] 设置为 nfs_boot，其值为 true，并附带一个 instance_info 设置 nfs_root，该设置提供 nfs 根连接信息。

所使用的内核和 ramdisk 支持 nfsroot 内核命令行选项。

潜在的未来功能¶

这些是其他一些可以在参考驱动程序实施完成后稍后开发的项目，但是这些项目超出当前规范的范围。

从远程卷启动代理以促进部署。

创建部署框架，以允许 IPA 潜在地应用 HBA 设置。

多路径 IO 配置处理和潜在传递。

配置驱动程序支持。

支持租户网络隔离启动场景。

提议的变更¶

为了支持初始功能集，即场景 1-4，从卷启动，我们建议如下

实施一个基本能力概念，通过一个辅助方法实现，该方法允许驱动程序/提供程序能力被代码库的另一部分检查，如果缺少能力定义则返回 false。示例
utils.check_capability(
    task.driver.boot.capabilities, 'iscsi_volume_boot')
utils.check_compatibility(
    task.driver.deploy.capabilities, 'iscsi_volume_deploy')
这将通过一个能力“标签”列表来实现，每个列表都添加到主级别接口类，以防止无效配置。
在现有的参考驱动程序部署验证方法中实施逻辑，以使任何配置了卷存储的节点验证失败，而该节点配置的驱动程序缺乏先前所述的能力接口识别的任何此类支持。这样可以帮助确保此类节点不会因错误的期望而意外配置。
更新 agent.AgentDeploy 和 iscsi_deploy.ISCSIDeploy 驱动程序逻辑，以支持跳过节点的部署，如果定义了存储接口提供程序，卷中存在卷信息，并且卷的索引为 0，表示它是启动卷。本质上，这意味着如果节点被定义为从远程卷启动，则驱动程序.deploy.deploy 方法应立即返回 DEPLOYDONE，因为任何网络启动配置（如果适用）都必须通过 driver.deploy.prepare 方法写入。
if (task.node.storage_interface is not None and
        not task.driver.storage.should_write_image(task)):
此外，部署驱动程序中的验证逻辑需要更新，以传递对节点配置中 instance_info 字段的特定检查，这些字段不适用于从卷启动的情况。
创建存储提供程序接口

类似于网络提供程序接口，默认值将导致提供程序接口执行 no-op 行为，同时公开一组空的存储能力。

一个节点级别的 storage_interface 设置，具有默认值，类似于 Add network interface to base driver class 更改，以定义节点是否使用存储接口以及要使用的提供程序。这旨在与驱动程序组合改革规范对齐。

初始参考存储驱动程序将基于 cinder，利用 python-cinderclient 作为 REST API 接口，以支持以下基本操作，如下所示。

detach_volumes - 最初实施，以枚举已知的附加卷并删除存储附件。

attach_volumes - 最初实施，以枚举已知的配置卷并发出存储附件请求。对于 cinder 驱动程序，我们将保留配置中的卷，初始化到卷的连接，同时提供当前的启动器配置，然后触发 cinder 卷附加调用以更新数据库配置。此外，我们将更新卷元数据，以便于用户识别用于 ironic 节点的卷，从而能够协调已关闭且已分离卷的节点。

validate - 最初实施，以验证配置中是否存在足够的配置以允许功能运行。如果未定义任何卷，则将跳过此验证。

should_write_image - 提供一个接口，允许其他组件询问存储驱动程序是否应将镜像写入磁盘。这允许将所有逻辑置于存储接口中。

更新 pxe.PXEBoot 驱动程序逻辑，以支持为从各种启动场景启动创建适当的 iPXE 配置，如果定义了 volume_target 信息，启用了 iPXE，并且可用存储提供程序。

更新 pxe.PXEBoot 验证接口，以利用辅助方法，当节点配置中定义了存储提供程序和启动卷时，验证能力、启动器配置和卷配置是否与指定的卷/路径类型一致。请注意，大部分逻辑应位于 deploy_utils 方法中，以便将来其他驱动程序可以重用。

更新 conductor utils.node_power_action 逻辑，以启用存储提供程序（由节点.storage_interface 设置定义）被调用，以允许节点的卷附加和分离，从而更新任何存储配置（如果需要）。

添加一个辅助方法，该方法设置并返回（如果尚未设置），基于硬件配置和提供的卷配置信息，节点.instance_info 的 boot_option 参数，从而能够匹配和识别每个场景的下一步适当步骤。

更新 conductor _do_node_tear_down 方法，以调用存储提供程序的 detach_volumes 方法并清除卷信息（如果尚未实施）。

在存储分离交互的开始和完成时，将生成一个通知，以便了解该过程是否已成功完成。

更新 iPXE 模板逻辑，以支持为场景 1、2、5 创建所需的各种文件格式。请参阅：IPXE sanhook 命令、IPXE san 连接 URL 和 nfsroot 内核命令行选项。

如前所述，每个场景将作为 ironic 的增量添加分别提交。

为了支持场景 4，部署驱动程序需要了解如何部署到具有此类配置的系统。

更新部署驱动程序，以启用为场景 1-3 添加的逻辑，该逻辑可以使用 force_deployment 参数进行绕过，该参数应在节点达到活动状态之前从节点的 instance_info 中删除。实际上，这将导致 ironic 在提供的卷信息通常预期已经存在有效的操作系统和引导加载程序的情况下支持部署操作。

需要将所需的启动卷告知代理，如果提供给目标，则告知连接信息。应使用根设备提示传递适当的信息，具体来说，如果可用，则设置 WWN 或卷序列号。

为了支持场景 5

必须实现场景 3。预计这将主要是 iPXE 模板中的替代路径，先前定义的设置将导致磁盘上的 PXE 引导模板从 NFS 根启动节点。

上述后期潜在改进，超出此初始规范

创建逻辑，允许 Ironic 用户利用存储提供程序为他们的节点请求卷。此功能需要 ironic 部署操作系统镜像，应由单独的规范涵盖。

备选方案¶

另一种选择是根本不开发此功能，而是鼓励下游用户独立开发类似的工具以满足其特定环境的需求。话虽如此，从希望发展和增强 ironic 的角度来看，这两种选择都不理想。

数据模型影响¶

将在节点对象中添加一个 storage_interface 字段，该字段将映射到适当的存储驱动程序。

状态机影响¶

无

REST API 影响¶

由于节点存储驱动程序将由操作员选择，因此需要将其隐藏在较旧的 API 客户端中，这需要在功能存在于 API 中后进行微版本更新。

客户端 (CLI) 影响¶

“ironic” CLI¶

无。所有预期的 CLI 更新预计都将包含在信息存储规范中，为 Ironic 节点添加卷连接信息。

“openstack baremetal” CLI¶

无

RPC API 影响¶

无

驱动程序 API 影响¶

第一个更改是引入由部署和引导驱动程序类定义的受支持的高级驱动程序功能列表，称为 capabilities，它允许其他驱动程序组件了解相邻驱动程序接口/组合中存在的功能。

第二个更改是引入一个新的 storage_interface，它将被映射到可用的存储驱动程序中可选择的存储驱动程序。

在此存储接口中，将定义新的方法以支持预期的存储操作。以下是预计将添加并从驱动程序公开可用的方法

def attach_volumes(self, task):
"""Informs the storage subsystem to detach all volumes for the node."""

def detach_volumes(self, task):
"""Informs the storage subsystem to detach all volumes for the node."""

def validate(self, task):
"""Validate that the storage driver has appropriate configuration."""

def should_write_image(self, task):
"""Determines if deploy should perform the image write-out."""

Nova 驱动程序影响¶

对 nova 驱动程序的影响在单独的规范中涵盖 Nova Specs - Ironic - Boot from Cinder volume。由于该驱动程序将作为选择加入的更改提供，我们预计不会对行为产生负面影响。

Ramdisk 影响¶

虽然我们应该能够推导出预期的根卷，并在必要时传递适当的根提示，以便作为场景 4 - 通过主机总线适配器 (HBA) 到卷进行引导，并进行镜像部署的一部分进行部署，但 IPA ramdisk 应该可能添加 HardwareManager 形式的功能以支持 MultiPath IO。话虽如此，MPIO 超出了此规范的范围。

安全影响¶

总体而言，存储驱动程序（在本例中为 cinder）需要使用已填充在 keystone 配置中的凭据来连接到 cinder 以获取和更新卷的映射信息。

场景 1-2 和 5 的设计方式是，租户机器能够通过节点默认网络配置访问各种卷驱动程序设置为利用的服务。因此，由于需要网络引导，因此需要扁平网络拓扑以及访问控制，以便节点能够访问存储卷的服务。

更安全的替代方案是代表场景 3 和 4 的驱动程序，因为此配置最终需要单独的存储基础设施。在这种情况下，将允许部署节点的租户网络隔离。

其他最终用户影响¶

此功能可能需要向 ironic-webclient 和 ironic-ui 子项目传达其他知识，但是需要在实施时进行评估，因为它们正在积极开发中。

可扩展性影响¶

这是一个操作员选择使用的功能。如果处于活动状态，后端存储接口的额外调用可能会根据部署的体系结构对性能产生影响。

性能影响¶

对于 ironic 维护的每个我们认为具有卷的节点，我们需要查询存储管理器，假定为 cinder，并在有意的驱动器电源操作期间附加/分离卷。这可能会延长启动节点的调用时间，或者如果无法进行附加，则可能阻止启动。

其他部署者影响¶

希望使用这些驱动程序的部署者自然需要在 enable_storage_interfaces 列表中添加 cinder 存储接口。

将设置默认存储配置驱动程序为 noop，这将防止调用任何存储相关代码，直到操作员显式选择启用此支持为止。

基于提议的驱动程序配置，我们可以预期在 conductor 配置文件中增加两个额外的部分

[DEFAULT]
enabled_storage_interfaces = <None> # Defaults to none and is a list of the
available drivers.

[cinder]
url = http://api.address:port
url_timeout = 30
retries = 3
auth_strategy = <noauth|keystone>
toggle_attachments_with_power = true

开发人员影响¶

这将增加 ironic 提供的整体复杂性和功能集。希望实施驱动程序特定功能的驱动程序开发人员应预期某些子板操作的发生，并尝试利用本规范和为 Ironic 节点添加卷连接信息规范中规定的子板。

实现¶

负责人¶

主要负责人: juliaashleykreger
其他贡献者: blakec shiina-hironori

工作项¶

将提议的更改分解，与底层场景结合使用，有助于传达不同的工作项目。话虽如此，此功能需要一些时间才能落地。

依赖项¶

需要在 IPA 中实现逻辑来处理未检测到磁盘的情况。cleaning 和 inspection 操作应该能够在没有本地磁盘存储的硬件节点上执行。

此外，在 IPA 中，作为软依赖项，可能需要逻辑来更好地处理存在多路径时的直接附加卷选择。这将需要自己的规范或明确定义的验证计划，因为 IPA 不能期望操作系统多路径支持来处理所有情况下的 MPIO 场景，甚至不存在。

实施为 Ironic 节点添加卷连接信息。此规范不应完全依赖于 Nova Specs - Ironic - Boot from Cinder volume 规范的实施。

对于驱动程序组合改革规范存在软依赖性，因为预计这两个工作将在并行进行，并且此实施工作应适当地合并功能，因为驱动程序组合改革规范的功能开始可用。

测试¶

全面堆栈的功能和集成测试级别是一个需要在 ironic 社区内进一步讨论的主题。一个初始的门测试案例可能是 ironic 部署从 Cinder 卷启动，tempest 测试可以编排。

场景 3 和 4 是最难测试的，因为它们具有与我们的直接控制无关的断开基础设施期望。但是，我们可能会发现基础覆盖层足以使用单元测试进行测试，因为最终将存在大量的底层公共路径。

升级和向后兼容性¶

由于此功能集作为参考驱动程序及其功能集中的一组新功能创建，因此预计不会出现兼容性问题，因为与此规范相关的 API 字段添加将隐藏在不请求适当 API 版本的 API 客户端中。

将添加数据库迁移步骤以创建节点数据库字段 storage_interface。此字段的初始值将为 None，并且不会设置任何隐含的默认值，因为操作员必须选择在其环境中启用存储接口。

文档影响¶

需要更新文档，详细介绍新的驱动程序和相关的用例，以便操作员可以理解驱动程序提供的选项以及它们如何适应其用例。应明确说明与长期网络引导主机相关的其他注意事项作为这项工作的一部分。

预计此规范将在开发此功能的过程中得到进一步完善，以便提出和记录任何新的技术发现。

参考资料¶

相关规范

Mitaka midcycle etherpad

ironic mitaka midcycle

Boot from Volume - Reference Drivers