Ironic L3 基于的部署

https://storyboard.openstack.org/#!/story/1749193

Ironic 依赖 L2 网络进行 IP 配置（以及可选的 PXE 启动）以配置裸机节点。这给多机架部署和远程站点部署（如边缘云等）带来了限制。此外，有损的配置网络可能会减慢或导致某些部署失败。

本规范建议依赖现代 BMC 的虚拟介质启动能力，可靠且安全地向所选节点交付启动镜像、静态网络配置、节点标识信息等。

建议的节点启动方式应完全消除对 DHCP 和 PXE 的需求，从而实现纯 L3 网络的部署。

问题描述

在 Ironic conductor 节点和目标节点之间提供 L2 连接并不总是容易的。

示例用例

• 多机架部署：机架间 L2 交换超出 ToR 的范围，使用 DHCP-relay 具有挑战性，因为这增加了对具有 DHCP-relay 的 ToR 或在远程子网上侦听以中继或代理 DHCP 请求的系统或 VM 的要求的限制。

• 远程站点目标：从中心位置部署位于不同远程站点的服务器是一个好主意。使用当前 L2 依赖设置，我们需要在 Ironic Conductor 和远程目标服务器之间提供 VPN L2 隧道。

  示例：边缘云服务器或分布式 VNF Flexi Zone 控制器 [1]。

• 有损、过载的配置网络可能导致 DHCP 或 TFTP 数据包丢失，从而减慢或导致整个节点部署失败。

市场上大多数硬件产品都支持从虚拟介质设备启动。虽然 Ironic 可以通过虚拟介质启动节点，但其当前的流程仍然依赖 DHCP 来获取启动的操作系统以获得 IP 堆栈配置。如果实施了建议的更改，则可以消除对 DHCP 的依赖。

提议的变更

在没有 DHCP 的情况下部署节点涉及解决三个关键问题

1. 安全地将启动镜像传递到正确的节点

2. 从云或特定站点的基础设施收集节点配置信息

3. 将节点配置信息（以及身份验证、标识等）配置到节点上运行的 ramdisk 操作系统

当代 BMC 的虚拟介质功能以及在某些 ironic 硬件类型（例如 redfish-virtual-media）中实现的虚拟介质启动支持完全解决了问题 (1)。本规范的其余部分致力于思考问题 (2) 和 (3)。

收集节点配置

典型的 ironic 节点部署流程涉及启动 Ironic Python Agent（称为 IPA 或 ramdisk），必须启动它以准备节点。一旦由 IPA 设置，租户（也称为实例）操作系统就会启动。

在 OpenStack 的上下文中，现有的云基础设施能够管理租户网络配置（例如 Neutron），向租户传递网络配置（例如 config-drive [2]）甚至简化节点配置的应用（例如 cloud-init [3]、os-net-config [4] 或 Ignition [11]）。所有这些功能结合起来在很大程度上解决了租户的问题 (2) 和 (3)。

然而，我们当前的软件基础设施并没有提供太多在没有 DHCP 的情况下配置 ironic ramdisk 网络的部分内容。本规范建议

• 允许操作员手动将静态节点网络配置与 ironic 节点对象关联。假设操作员将使用其他机制进行 IP 地址管理。

• 启用 ironic 利用 Neutron 构建静态网络配置，从 Neutron 信息中为正在部署的节点构建静态网络配置。

配置节点

本规范建议将包含 Nova 元数据的 config-drive 的内容刻录到从节点启动的 ISO 镜像中，并在配置和状态中。如果操作员没有向 Ironic 提供任何 config-drive 信息，Ironic 将创建一个。

为了便于网络配置处理和应用，本规范建议重用 network-data.json [8] Nova 元数据格式，用于 Ironic 管理的节点网络配置。

示例 network-data.json 文件

{
    "links": [
        {
            "id": "interface0",
            "type": "phy",
            "ethernet_mac_address": "a0:36:9f:2c:e8:80",
            "mtu": 1500
        },
        {
            "id": "interface1",
            "type": "phy",
            "ethernet_mac_address": "a0:36:9f:2c:e8:81",
            "mtu": 1500
        }
    ],
    "networks": [
        {
            "id": "provisioning IPv4",
            "type": "ipv4",
            "link": "interface0",
            "ip_address": "10.184.0.244",
            "netmask": "255.255.240.0",
            "routes": [
                {
                    "network": "10.0.0.0",
                    "netmask": "255.0.0.0",
                    "gateway": "11.0.0.1"
                },
                {
                    "network": "0.0.0.0",
                    "netmask": "0.0.0.0",
                    "gateway": "23.253.157.1"
                }
            ],
            "network_id": "da5bb487-5193-4a65-a3df-4a0055a8c0d7"
        },
        {
            "id": "provisioning IPv6",
            "type": "ipv6",
            "link": "interface1",
            "ip_address": "2001:cdba::3257:9652/24",
            "routes": [
                {
                    "network": "::",
                    "netmask": "::",
                    "gateway": "fd00::1"
                },
                {
                    "network": "::",
                    "netmask": "ffff:ffff:ffff::",
                    "gateway": "fd00::1:1"
                },
            ],
            "network_id": "da5bb487-5193-4a65-a3df-4a0055a8c0d8"
        }
    ],
    "services": [
        {
            "type": "dns",
            "address": "10.0.0.1"
        }
    ]
}

本规范预计将 network_data.json 文档的内容与 ironic 节点对象关联，通过在节点对象中引入一个新的 network_data 字段来包含 ironic ramdisk 启动的 network_data.json 信息。

在 ramdisk 侧，本规范建议使用 Glean [12] 来消费和应用网络配置到运行 ironic ramdisk 的操作系统。这里的关键考虑因素是，与 cloud-init 不同，Glean 简洁，并且可以轻松支持 cloud-init 功能的子集。

替代的 ramdisk 实现可以选择其他方式基于 network_data.json 信息引导 OS 网络。

总而言之 - 在配置节点网络配置的领域，本规范建议

• 通过 ramdisk 镜像重用 Nova 元数据表示来配置网络配置。

• 向 ironic 节点对象添加一个新字段：network_data 用于 ramdisk 引导。

  该字段的内容将由 ironic conductor API 根据 Glean JSON 模式以及实施者认为合理的某些临时检查进行验证。

  将 Glean 模式有效地硬编码到 ironic conductor API 中将不允许轻松扩展或添加其他网络配置格式。

• 创建一个新的 config-drive 以使其包含 network-data.json 文件。

• 将 config-drive 内容写入 ISO 文件系统的根目录（以及 ramdisk 和内核 blob），然后创建一个可引导的 ISO 镜像。

• 将 Glean 依赖项包含到 ramdisk 镜像中以进行托管 OS 引导。

然而，Ironic 救援操作，至少在其当前实现中，只有当用户和配置网络是相同的网络时才有效。

这是因为救援 ramdisk 将尝试通过重新启动 DHCP 客户端来重新编号 NIC。解决此限制不在本规范的范围内。

部署工作流程

为了更容易理解，让我们重申整个 Ironic 部署工作流程，重点关注网络配置的构建和使用方式。我们将考虑两种场景 - 独立 ironic 和 OpenStack 云中的 ironic。在每种情况下，我们只考虑部署 ramdisk 并省略实例启动阶段。

独立 ironic

1. 操作员提供部署 ramdisk 网络配置，以 network-data.json 内容的形式，通过正在部署的 ironic 节点的 network_data 字段。 network_data.json 的内容必须符合 Glean 可以消费的 network_data.json 的 JSON 模式。

2. Ironic conductor 验证提供的 network-data.json 是否符合 Glean 模式（通过配置提供给 ironic API 程序），如果验证失败则尽早失败。 Glean 模式不允许任何可以应用于 OS 的 network_data.json 属性，即使这些属性作为 Nova 元数据有效。

3. Ironic 构建一个新的 config-drive 镜像，并将 network-data.json 文件（从 network_data 字段获取的内容）放置在 config-drive 镜像中的常规位置。

4. 为了启动部署 ramdisk，ironic 构建一个可引导的 ISO，由 deploy_kernel 和 deploy_ramdisk 组成，并将 config-drive 内容写入引导 ISO 镜像的根目录。

   Glean 运行在 ramdisk 内部，将尝试挂载虚拟 CD 驱动器，以查找标记为 config-2 的文件系统，读取 network_data.json 并将网络配置应用于 OS。

Ironic 在 OpenStack 中

1. 在启动 ramdisk 之前，除非操作员提供的网络配置已存在于 network_data ironic 节点字段中，否则 ironic 通过与 Neutron 通信来收集与正在部署的节点关联的每个 ironic 端口/端口组的网络配置。然后 ironic 以 network-data.json 文件的形式为 ramdisk 操作系统构建网络配置。

2. Ironic 构建一个新的 config-drive 镜像，并将 network-data.json 文件（如步骤 (1) 中构建）放置在 config-drive 镜像中的预定义位置。

3. 为了启动部署 ramdisk，ironic 构建一个可引导的 ISO，由 deploy_kernel 和 deploy_ramdisk 组成，并将 config-drive 内容写入引导 ISO 镜像的根目录。

   Glean 运行在 ramdisk 内部，将尝试挂载虚拟 CD 驱动器，以查找标记为 config-2 的文件系统，读取 network_data.json 并将网络配置应用于 ramdisk 操作系统。

备选方案

或者，为了将整个一致的 network_data.json JSON 文档与 ironic 节点对象关联，network_data.json 也可以绑定到 ironic 端口对象。然而，实验性实现揭示了源于以端口为中心的设计的某些困难，因此已达成共识，将 network_data.json 绑定到 ironic 节点对象。

或者，为了使 ironic 收集和构建 network-data.json [8]，ironic 也可以直接请求 Nova 元数据服务 [10] 以根据实例 ID 生成必要的文件。然而，这对于非部署操作（例如节点清理）将不起作用，因为 Nova 未参与其中。

或者，为了依赖 Nova 元数据和 Glean 作为 ramdisk 中的消费者，我们可以利用 os-net-config 从内核参数获取压缩配置的功能。缺点是内核 cmdline 的大小受到严重限制（256+ 字节）。此外，os-net-config 感觉像是一个 TripleO 特定的工具，与 cloud-init 相比，后者除了是云中引导实例的主流方式外，还了解 OpenStack 网络配置元数据。

或者，为了让 Ironic 提供 ramdisk 网络配置作为 network_data.json 文件，Ironic 也可以接受整个 config-drive。这将使其看起来类似于实例启动（例如 Ironic 配置状态 API），并允许在未来将更多文件传递给 ramdisk。

作为替代，可以将 Glean 模式验证集成到 Ironic conductor 中，或者要求操作员在提交到 Ironic 之前使用外部工具验证他们的 network_data.json 数据。这将放松 ironic conductor 对 Glean 输入要求变化的依赖，并简化 network_data.json 在 ramdisk 和实例引导中的重用。

数据模型影响

添加一个新的、用户可管理的字段 network_data 到 ironic 节点对象，将 ramdisk 网络配置信息传递给 ironic。如果设置，此新字段的内容应为格式良好的 network-data.json 文档，描述运行 ramdisk 的节点的网络配置。

状态机影响

无。

REST API 影响

• 更新 GET /v1/nodes/detail、GET /v1/nodes/{node_id}、PATCH /v1/nodes/{node_id} 以添加新的请求/响应字段

• network_data JSON 对象，传递网络配置。

客户端 (CLI) 影响

“ironic” CLI

无

“openstack baremetal” CLI

• 更新 openstack baremetal node create 和 openstack baremetal node set 命令，以接受新的参数 --network-config <JSON>，并提供描述网络配置 JSON 结构的帮助文本。

• 扩展 openstack baremetal node show 命令的输出，添加 network_data 列。

RPC API 影响

无

驱动程序 API 影响

• 扩展 ironic 基本 NetworkInterface，添加 get_node_network_config API 调用，为正在管理的节点提供网络配置。Ironic 将把此 API 调用的输出写入通过虚拟介质提供的引导镜像中。

• 为非 Neutron 网络实现 get_node_network_config 网络接口调用，从 ironic 对象的 network_data 字段（如果存在）提供 network_data.json。然后，操作员可以实现他们自己的 IPAM（例如，用于独立 ironic 用例）。

• 为 Neutron 网络实现 get_node_network_config 网络接口调用，基于 Neutron 端口和子网信息生成 network_data.json [9]。

• 如果 network_data.json 尚未通过 config-drive 传递给 ironic，则使 ironic 中的虚拟介质引导接口生成包含 network_data.json 的 config-drive。

• 使 ironic 中的虚拟介质引导接口在每次节点引导时将 config-drive 内容写入生成的可引导 ISO 镜像的根目录。如果包含 config-drive 文件，此可引导 ISO 镜像上的文件系统应标记为 config-2。

Nova 驱动程序影响

无

Ramdisk 影响

• Diskimage-builder 工具应在引导时将 Glean 安装到 ramdisk 中并调用。

  在此基础上，dhcp-all-interfaces DIB 元素可能不再使用，因为 Glean 将在所有未显式配置（通过 config-drive）的接口上运行 DHCP [13]。

安全影响

无。

其他最终用户影响

无。

可扩展性影响

无。

性能影响

无。

其他部署者影响

无。

开发人员影响

无。

实现

负责人

主要负责人

etingof (etingof@gmail.com)

其他贡献者

无。

工作项

• 以机器可读的 JSON 模式的形式记录 Glean 要求，以及与 network_data.json 的关系。

• 更新 ironic 节点模型，以包含可选的、用户指定的 network_data 字段，该字段以 network_data.json JSON 文档的形式承载 ramdisk 网络配置。

• 更新 REST API 端点以支持新的 network_data 字段

• 在 baremetal CLI（openstack baremetal node ...）中支持新的 network_data 字段

• 扩展 ironic 基本 NetworkInterface，添加 get_node_network_config API 调用，为正在管理的节点提供网络配置。

• 为非 Neutron 网络实现 get_node_network_config 网络接口调用，从 ironic 节点对象的 network_data 字段（如果存在）提供 network_data.json。

• 为 Neutron 网络实现 get_node_network_config 网络接口调用，基于 Neutron 端口和子网信息生成 network_data.json [9]。

• 使 ironic 中的虚拟介质引导接口生成带有 network_data.json 的 config-drive。

• 使 ironic 中的虚拟介质引导接口将 config-drive 文件写入生成的可引导 ISO 镜像的根文件系统，该镜像在每次节点引导时生成。文件系统应标记为 config-2，以便 Glean 找到并使用它。

• 更新 ramdisk 引导代码，以便在系统引导时调用 Glean，并在 config-drive 上存在 network-data.json 文件时使用它。

• 更新 diskimage-builder 工具，以控制新静态网络配置处理功能的包含和选项。

• 创建关于无 DHCP 引导设置和工作流程的文档。

依赖项

Ramdisk 将开始依赖 Glean 来处理 network-data.json 文档。

测试

使用操作员提供的和 Neutron 生成的 network_data.json 对 ironic 节点部署进行 Tempest 测试。

升级和向后兼容性

无。

文档影响

应将基于 L3 的部署的使用记录在此项中。

参考资料

[1]

https://networks.nokia.com/products/flexi-zone

[2]

https://docs.openstack.org/nova/latest/user/metadata.html#config-drives

[3]

https://cloudinit.readthedocs.io/en/latest/

[4]

https://github.com/openstack/os-net-config

[8] (1,2)

https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html

[9] (1,2)

https://github.com/openstack/nova/blob/master/nova/virt/netutils.py#L60

[10]

https://docs.openstack.org/nova/latest/user/metadata-service.html

[11]

https://github.com/coreos/ignition/blob/master/doc/configuration-v3_0.md

[12]

https://docs.openstack.org/infra/glean/

[13]

https://opendev.org/opendev/glean/src/branch/master/glean/cmd.py#L323