智能网卡到DPU的演进¶

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

“智能网卡”的概念随着时间的推移而不断演变。

老实说，感觉我们Ironic社区帮助推动了这些改进，使其朝着更好、更安全的方向发展。嘿！我们说过我们会改变世界！

最初，这些是基础设施运营商希望卸载部分流量的高度先进的网络卡，后来演变成一种更通用的工作负载，但仍然以卸载为导向。但现在，这些新一代的卡片拥有自己的BMC模块，并且可以进行有限的硬件管理。

但是访问模型和使用/交互方式意味着一台服务器可以有一个主BMC，然后是N个子BMC，其中一些可能能够与整体BMC和操作系统通信，也可能不能。

为了真正支持这一点以及不同的工作流程，我们需要考虑对整体交互和支持模型进行一些重大更改。这并不是因为该设备只是一个子集，而是一个具有自己独特管理协议、启动能力/设备、架构和自己控制台、内部状态、凭据等通用计算机内部的计算机。

问题描述¶

所需背景¶

为了浏览这个主题，我们需要确保我们了解各种术语的含义以及它们之间的关系。

智能网卡¶

这些最好被视为“第一代”DPU卡，其中可以在卡上执行卸载工作负载，例如连接到消息总线的Neutron代理，以便将端口绑定到物理机。

一些最初的社区和供应商讨论还集中在通过类似光纤通道HBA的行为提供存储附件等进一步的潜在用例上。

可组合硬件¶

“可组合硬件”这个词不幸地被过度使用。最好将其描述为使用集中式服务来“组合”硬件以供工作负载使用。一种很好的理解方式，至少在经典意义上，是通过API或应用程序构建一个具有用户可定义CPU、内存、存储和网络的连贯功能性计算机资源。本质上是像我们对虚拟机一样虚拟化硬件交互/建模。

除了特定供应商提供的一些有限的硬件产品外，可组合硬件在很大程度上没有像硬件制造商最初宣传的那样实现。

DPU¶

DPU或数据处理单元最好被视为“第二代”智能网卡，它被设计用来运行更通用的工作负载，但它不完全是网络或连接到网络资源的适配器。例如，你可能希望在卡上运行一个BGP守护进程，这完全超出Ironic的运营和管理范围，但你可以将该服务运行在那里以卸载在系统主CPU上运行的需要。一个流行的想法是利用该卡作为“信任根”。

DPU和可组合硬件在建模方面的相似之处在于提供潜在的远程资源给运行的操作系统。

鉴于DPU的整体通用能力以及对特定计算工作负载卸载的日益关注，我们需要小心地明确我们试图支持的用例，并且不要假设一个意味着另一个。换句话说，DPU确实提供了一些有趣的可组合硬件能力，但它本身并不是完全的配置，因为底层主机仍然是一个静态实体。

注意

DPU有时也表示为xPU，因为传统的显卡是图形处理单元。虽然似乎没有明确的动向来支持特定的卸载，但一些供应商正在开发高度特定的处理卡，例如执行协议/信号转换。它们可能或可能没有操作系统或配置的应用程序。

问题¶

今天，在Ironic中，我们有一个裸机节点的概念。在该裸机节点内部，可能有各种可以集中管理和交互的硬件。它有一个单一的BMC，控制着基本上所有方面。

我们还有一个“智能网卡”的概念，以端口对象上的is_smartnic的形式存在。但是这只会影响Ironic的电源和启动模式管理。

但是，这些卡片并非全部都是“网络”卡，或者至少不是任何传统计算模型中的“网络”卡。想想无线电！

交织的挑战是这种嵌套的访问模型。

为了举例说明，我将参考带有BMC的Nvidia Bluefield2卡。值得注意的是，我们有Antelope IPA中的支持来更新这些卡的BMC固件。至少，这是我们对该功能的理解。

但是要做到这一点

从主机，需要通过请求卡上的BMC允许整体主机操作系统访问卡上的BMC来删除访问限制。这可以使用IPMI原始命令实现，但针对卡上的BMC。
然后你将应用BMC固件更新，到卡的BMC。今天这将启动IPA，并从主机操作系统执行它，这也意味着我们需要与整体主机BMC交互，并启动整个裸机。
然后你自然会想要删除这些权限，这需要调用卡上的BMC来更改访问权限。
然后，如果你想更新卡本身的操作系统，你将重复这个过程，使用不同的命令集来打开卡上的操作系统与BMC上的操作系统之间的访问权限。

注意

我们知道Bluefield2卡可以通过网络启动，并且可以通过SSH进入BMC并将新的操作系统镜像流式传输到安装程序命令通过SSH进行更新。这本身将是一个单独的RFE或功能，但整体建模更改仍然是本规范试图解决的。

希望这说明了复杂性，开始强调我们需要开始支持父/子设备模型的原因，并允许在父节点上表达步骤，这些步骤适用于一个或多个子节点。

进一步使情况复杂化的是，最终我们只是在处理许多不同的Linux系统，它们具有不同的访问模型。例如，运行IPA的较新的Dell服务器，以及两张这些专用卡，此后称为数据处理单元（DPU），将在主机BMC上运行Linux，在主机处理器上，在每个DPU卡的BMC内部，以及在DPU卡上的处理器内部。

本规范本质上不包括DPU卡操作系统状态配置。其他项目正在致力于此，我们期待随着它们的发展与它们集成。

注意

另一个考虑的项目是OPI项目，它正在这个领域开展很多工作，但是他们明确指出通过外部零触控配置进行自动化/手动部署超出他们的项目范围。建立一个通用工作负载是合理的，但是运营生命周期和持续管理是Ironic可以帮助运行各种工作负载和配置的运营商，或者需要执行更具体的生命周期操作的方面。

提议的变更¶

本规范的总体思想是引入构建块，以启用在父设备和子设备之间进行编排和表达操作。

在节点对象上引入parent_node字段，并增加API版本。
引入子节点资源视图/v1/nodes/<node>/children，允许枚举子节点。
默认情况下，/v1/nodes列表仅列出没有父节点的节点，并添加查询过滤器以返回具有父节点的节点。
引入新的步骤字段值execute_on_child_nodes，可以提交。默认值为False。返回CLEANWAIT的步骤，即期望异步返回的步骤，在正常情况下将不允许，但是这将通过配置选项提供。
引入新的步骤字段值limit_child_node_execution，它接受节点UUID列表以允许过滤和约束某些节点上的步骤。特别是，这与execute_on_child_nodes字段分开，因为JSON Schema限制。
引入调用供应商直通接口作为步骤的能力。在某些智能网卡的情况下，他们需要能够调用跨子节点的IPMI原始命令。
引入调用set_boot_device作为步骤的能力。在这种情况下，我们可能希望将DPU卡批量设置为PXE启动，以便在IPA ramdisk或其他机制中进行软件部署。
引入调用power_on、power_off管理接口方法通过conductor set_power_state helpers（包括对快速通道等方面的保护逻辑）。
可能：考虑某些类别的节点可选“物理”网络接口。在我们进入实现能力的过程中，我们才会知道这一点。
可能：考虑BMC报告的机器UUID作为匹配代理操作的标识符。Ironic社区长期以来一直被动地希望这是一个“好主意”。
可能：我们可能需要继续表示在子节点之前或子节点之前的父节点电源管理建模，就像我们对端口对象is_smartnic字段所做的那样。这相对较小，与其他可能的更改一样，在我们进一步发展或一些社区合作伙伴能够根据他们的经验提供具体反馈之前，我们无法很好地了解这一点。

有了这些高级和工作流程更改，操作员将更容易地在单个节点上编排管理操作，并进一步扩展到整个系统的不同设备。

在这个模型中，子节点的基本规则将适用，它们可能有自己的电源和自己的电源控制，因此具有固有的“开启”和“关闭”状态，因此删除父节点应导致删除所有子节点。为了状态跟踪，如果使用特定的操作系统通过Ironic管理单个卡，它们可以移动到已部署状态，但它们也可能永远处于manageable状态，与父节点无关。这是因为其整体嵌入式性质，以及它虽然仍然是一个通用计算设备，但不如通用计算资源。

未解决的问题¶

我们是否应该弃用端口对象字段is_smartnic？这被记录为用于野外更改电源/启动配置流程的第一代智能网卡上的字段，仍然适用于新一代的卡，如果操作员有像Neutron OVS代理连接到消息总线以允许终止连接到卡内底层硬件的VXLAN连接等情况。

本规范的范围¶

理想情况下，我们最终希望拥有DPU特定的硬件类型，但本规范的想法是构建构建DPU特定硬件类型所需的基底，并使高级基础设施运营商能够完成所需的操作。

备选方案¶

存在三种替代方案。从技术上讲，四种。

什么都不做¶

第一个选项是什么都不做，并强制管理员以零碎的方式管理他们的嵌套硬件。这将创建一个Ironic使用的障碍，而且我们已经从一些正在与Ironic一起使用这些卡的硬件供应商那里知道，现有的摩擦是与仅电源管理相关的问题。这意味着，这对于Ironic在更复杂的环境中的使用来说不是一个可行的选择。

限制范围并阐明特定的工作流程¶

第二个选项可能是将“支持范围”限制为仅电源或启动操作。但是，我们已经就支持具有外部电源的服务器中的xPU等问题进行了类似的讨论，并且在很大程度上无法找到可行的模型，很大程度上是因为该模型通常需要单个task.node能够以具有特定参数的特定接口执行。例如，对于基线电源管理，到系统BMC，然后到SNMP PDU对于辅助电源。该模型也没有必要地阻止我们进行更通用的管理能力和访问卡上功能，例如通过其自己的嵌入式BMC进行“串行控制台”而无需进行大量重构和重新设计数据模型。

也有可能嵌套访问控制/建模是不合适的。你并不一定希望在 BMaaS 中提供一个裸机租户，该租户具有对 Ironic 的 lessee 访问权限，能够访问串行控制台，这有点指向我们提出的解决方案，以便提供处理建模固有复杂性的能力，或者至少提供基于现有代码的有机能力。

使用 Chassis¶

第三种可能性是使用现有的 Chassis 资源。父/子关系的概念确实类似于 Chassis 和 Node 的建模方式。

Chassis 最初的意图是在 Ironic 的数据模型中允许表达整个机架或刀片式机箱，部分原因是为了允许与配置管理数据库 (CMDB) 或资产清单更一致的关系和资源跟踪。然而，Chassis 并没有获得太多关注，因为这些系统通常在企业环境中是必需的并且解耦的。

Chassis 在 Ironic 中已被多次提议删除，并且允许创建一对多关系，但这种关系在设置后无法更新。这本质上是有问题的，如果需要移动卡或更换机箱但 DPU 只是移动到新的机箱，则会产生维护负担。

但是，DPU 存在的固有的一对多建模最终意味着建模与实际用法相反。节点需要是 Chassis，但用户如何安排/部署“实例”，更不用说对机器的独立部分执行有针对性的生命周期操作，而这些部分可以移动到另一个 Chassis 呢？

总而言之，这可能会导致我们进展较慢的一个领域，因为我们基本上需要重新建模整个 API，这可能是一个有趣的挑战，但最终意味着所需的工作量大大增加，并且我们可能会尝试重新建模交互并更改用户体验，这意味着新模型也更难采用，并且如果我们不尝试将整个功能集带到 DPU，则风险也更高。如果我们从“重用”的角度来看待解决整个问题，那么本文档中提出的解决方案似乎是一个更轻量级的解决方案，同时也为利用现有功能并为未来功能提供坚实的基础留下了空间。

实际上，Chassis 的理想用例是完全可组合的硬件，其中某些类型的周期性工作可以预先填充“可用”节点，以便由 Nova 等服务从物理资源池中进行调度，以及协调整体差异。然而，阻碍因素最终是硬件的可用性以及相关的文档，这使得在开源中实现一个现实的 Chassis 驱动程序变得困难。

创建一个新的接口或硬件类型¶

我们可以在节点上创建一个新的接口，或者创建一个新的硬件类型。

我们最终希望有一些 DPU 特定的项目来更好地促进和支持最终用户，但是存在多个设备、一对多关系的基本问题。由于单个机器可能具有多种类型的卡或设备，这又将我们指向最初提出的想法。

数据模型影响¶

将添加一个 parent_node 字段，并且该字段将被索引。有可能添加的 DB 索引也可能是多字段复合索引，但这被认为是实现细节。

状态机影响¶

预计不会对状态机产生影响。

REST API 影响¶

GET /v1/nodes/?include_children=True

返回一个包含所有子节点的基节点列表，对于 Ironic 负责的所有事物的概览视图很有用。

GET /v1/nodes/

默认情况下，视图将仅返回 parent_node 字段为 null 的节点。旧的 API 客户端仍然会收到此默认行为更改。

GET /v1/nodes/<node_ident>/children

将返回节点列表，其中包含预先存在的访问列表约束和所有已定义节点的建模，其中 parent_node 与 node_ident 匹配。与现有的节点列表行为一致，如果访问权限不允许查看节点，或者没有节点，则将向 API 客户端返回一个空列表。

此字段也可能需要其他参数，但目前最好将其留作实现细节，倾向于不需要支持其他参数。

注意

我们可能需要验证提交的 node_ident 是否也是 UUID，否则将名称解析为节点，然后查找 UUID。

一个链接字段将引用每个节点，回到基础节点，这可能需要对节点列表和链接生成背后的逻辑进行一些小的调整。

预计所有上述更改将与微版本增加一起合并。唯一的非版本控制更改是 parent_node 字段的存在/匹配。

需要相应的 API 客户端更改才能与代码的这一部分进行交互。

客户端 (CLI) 影响¶

“openstack baremetal” CLI¶

baremetal 命令行界面需要接收参数来查询子节点，并查询特定节点的子节点。

“openstacksdk”¶

可能不需要 SDK 更改，或者可能更适合在有人识别需要跨服务支持的用例时有机地发生。

RPC API 影响¶

预计不会有额外的 RPC API 调用。

驱动程序 API 影响¶

除了确保管理接口 set_boot_device 以及 IPMI 接口 send_raw 命令可以通过步骤框架调用之外，预计不会对驱动程序 API 进行直接更改。

Nova 驱动程序影响¶

预计没有，这旨在对 Nova 不可见。

Ramdisk 影响¶

目前，DPU 内部的 ramdisk 执行目前不在本次讨论范围内。

其中一些现有的智能网卡可能不建议进行“清理”等操作，例如，Bluefield2 卡片具有更传统的 SPI 闪存，而不是 Bluefield3 卡片中的 NVMe。鉴于与此类硬件交互的专业方法，我们预计最终可能希望提供特定的部署或引导接口，这些接口可以绕过某些固有的“代理”功能。

安全影响¶

预计不会有额外的安全影响。

其他最终用户影响¶

无

可扩展性影响¶

此更改提出了一个整体关系和能力，这可能导致 Ironic 的数据库中需要管理更多的节点。对于子设备，可能不需要电源同步循环，或者可以更不频繁地进行。这些是我们最终需要进一步讨论并考虑一些额外的控制项，以便操作员不会因为“节点”表中增加的行数而感到任何需要或影响。

注意

应该注意的是，Ironic 中哈希环的工作方式是，环由conductor 组成，然后根据节点属性进行映射。子节点的映射应该是父节点。这些问题还有待确定。

性能影响¶

预计不会产生直接的负面影响。最直接的影响将是数据库和一些周期性任务，我们已经在前面的部分中对此进行了介绍。通过更新一些周期性任务以不匹配任何子节点，也可以避免一些整体性能，逻辑情况将是像 RAID 周期性任务，这些任务将永远不适用，并且不应该为这样的设备配置，这本身可能使进行这样的周期性更改的必要性变得无关紧要。

其他部署者影响¶

预计不会产生负面影响，但操作员可能会迅速发现需要“BMC SSH 命令”接口，因为越来越多的 BMC 采用基于 linux 的电源提供增强的功能和可能性，以及逻辑映射未映射时的潜在需求。

开发人员影响¶

无

实现¶

负责人¶

主要负责人: Julia (TheJulia) Kreger <juliaashleykreger@gmail.com>
其他贡献者: <IRC 用户名、电子邮件地址、无>

工作项¶

添加 parent_node db 字段和节点对象。
添加节点查询功能。
引入 /v1/nodes/<node>/children API 资源和由此产生的 API 微版本增加。
添加步骤支持，以迭代混合了父节点和子节点步骤命令的步骤定义。
引入通用的电源接口步骤：* power_on * power_off
添加 IPMI 管理接口 raw 命令步骤方法。
添加了新步骤命令和子节点对象调用的示例。

依赖项¶

无。

测试¶

预计进行基本的 tempest API 合同测试，但预计不会进行完整的 tempest 场景测试。