Smart NIC Networking¶

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

本文档描述了对 Ironic 的提议修改，旨在启用基于智能网卡（Smart NIC）的通用、厂商无关的裸机网络服务，从而实现与虚拟化用例相当的裸机网络功能。

问题描述¶

目前 Ironic 支持通过 ML2 机制驱动程序为裸机服务器提供 Neutron 配置的网络连接，但现有支持主要基于通过厂商特定的机制驱动程序配置 TOR 交换机，功能有限。

提议的变更¶

市场上涌现出各种智能/高性能网卡。这些网卡通常集成了一个或多个通用 CPU 核心以及数据平面包处理加速功能，可以高效运行虚拟交换机（例如 OVS），同时保持与 SDN 层的现有接口。

该提案旨在扩展 Ironic，以启用使用智能网卡来实现裸机服务器的通用网络服务。目标是启用运行标准的 Neutron Open vSwitch L2 代理，提供通用、厂商无关的裸机网络服务，与虚拟化用例相比具有相同的功能。Neutron Open vSwitch L2 代理管理智能网卡上的 OVS 桥接。

在此提案中，我们解决了两种用例

Neutron OVS L2 代理在智能网卡上本地运行。

此用例需要能够运行 OpenStack 控制服务的智能网卡，例如 Neutron OVS L2 代理。此用例的目标是将智能网卡视为裸机节点的隔离化超visor，智能网卡为在主机上运行的裸机镜像提供服务（就像超visor 为虚拟机提供服务一样）。虽然此规范最初针对 Neutron OVS L2 代理，但相同的实现自然且容易地扩展到任何其他 ML2 插件以及其他代理/服务（例如，通过智能网卡上的存储发起器后端暴露模拟的 NVMe 存储设备）。
Neutron OVS L2 代理远程运行，并管理所有裸机智能网卡的 OVS 桥接。

在 [1]、[2] 和 [3] 中捕获的 Neutron OVS L2 代理的增强功能。

设置智能网卡配置

智能网卡配置包括以下内容
1. 扩展 ironic 端口，添加 is_smartnic 字段。（默认为 False）
2. 智能网卡主机名 - 运行 Neutron OVS 代理的服务器/智能网卡的主机名。（必需）
3. 智能网卡端口 ID - 需要连接到集成桥接的端口名称。下图中的 B（必需）
4. 智能网卡 SSH 公钥 - 智能网卡的 ssh 公钥（仅适用于远程）
5. 智能网卡 OVSDB SSL 证书 - 智能网卡中 OVS 的 OVSDB SSL（仅适用于远程）
OVS ML2 机制驱动程序将根据从 ironic 传递的智能网卡配置确定 Neutron OVS 代理是在本地运行还是远程运行。config 属性将存储在裸机端口的 local_link_information 中。

在此规范的范围内，智能网卡配置将由管理员手动设置。
部署接口

扩展 ramdisk、direct、iscsi 和 ansible 以支持智能网卡用例。

部署接口调用网络接口方法，例如：add_provisioning_network、remove_provisioning_network、configure_tenant_networks、unconfigure_tenant_networks、add_cleaning_network 和 remove_cleaning_network。

这些网络方法通常在裸机关电时调用，以确保在启动裸机之前在 TOR 上进行适当的网络配置。

智能网卡与裸机共享电源状态，需要先启动裸机才能配置网络。这导致一个潜在的竞争条件，即裸机启动并访问网络，而智能网卡内的网络尚未正确配置。

为了确保在裸机启动之前进行适当的网络配置，部署接口将间歇性地将裸机启动到 BIOS shell，提供一种状态，在这种状态下可以正确配置智能网卡上的 ovs，然后再将裸机重新启动到实际的客户镜像或 ramdisk。智能网卡上的 ovs 将在我们验证 neutron ovs 代理处于活动状态后进行编程。

配置/取消配置网络的以下代码
```
if task.driver.network.need_power_on(task):
    old_power_state = task.driver.power.get_power_state(task)
    if old_power_state == states.POWER_OFF:
        # set next boot to BIOS to halt the baremetal boot
        manager_utils.node_set_boot_device(task, boot_devices.BIOS,
                                           persistent=False)
        manager_utils.node_power_action(task, states.POWER_ON)

# ...
# call task.driver.network method(s)
# ...

if task.driver.network.need_power_on(task):
    manager_utils.node_power_action(task, old_power_state)
```
部署接口中的以下方法调用一个或多个配置/取消配置网络，应使用上述逻辑进行更新。
- iscsi 部署接口
  - iscsi_deploy::prepare
  - iscsi_deploy::deploy
  - iscsi_deploy::tear_down
- ansible 部署接口
  - ansible/deploy::reboot_and_finish_deploy
  - ansible/deploy::prepare
  - ansible/deploy::tear_down
  - ansible/deploy::prepare_cleaning
  - ansible/deploy::tear_down_cleaning
- direct 接口
  - agent::prepare
  - agent::tear_down
  - agent::deploy
  - agent::rescue
  - agent::unrescue
  - agent_base_vendor::reboot_and_finish_deploy
  - agent_base_vendor::_finalize_rescue
- RAM Disk 接口
  - pxe::deploy
- 通用的清理方法
  - deploy_utils::prepare_inband_cleaning
  - deploy_utils::tear_down_inband_clean
网络接口

扩展基础 network_interface，添加 need_power_on - 如果连接到节点的任何 ironic 端口是智能网卡，则返回 true

扩展 ironic.common.neutron add_ports_to_network/ remove_ports_from_network 方法，以支持智能网卡用例
- 在 add_ports_to_network 上并具有 smartNIC 时，执行以下操作
  - 检查 neutron 代理是否处于活动状态 - 验证 neutron 代理是否处于活动状态
  - 创建 neutron 端口
  - 检查 neutron 端口是否处于活动状态 - 验证 neutron 端口是否处于活动状态
- 在 remove_ports_from_network 上并具有 smartNIC 时，执行以下操作
  - 检查 neutron 代理是否处于活动状态 - 验证 neutron 代理是否处于活动状态
  - 删除 neutron 端口
  - 检查 neutron 端口是否已删除
Neutron ml2 OVS 更改
- 为 smart-nic 引入一个新的 vnic_type。
- 更新 Neutron ml2 OVS，将 smart-nic vnic_type 与 binding:profile 智能网卡配置绑定。
Neutron OVS 代理更改

智能网卡模型的示例

+---------------------+
|      baremetal      |
| +-----------------+ |
| |  OS Server    | | |
| |               | | |
| |      +A       | | |
| +------|--------+ | |
|        |          | |
| +------|--------+ | |
| |  OS SmartNIC  | | |
| |    +-+B-+     | | |
| |    |OVS |     | | |
| |    +-+C-+     | | |
| +------|--------+ | |
+--------|------------+
         |

A - port on the baremetal host.
B - port that represents the baremetal port in the smart NIC.
C - port that represents to the physical port in the smart NIC.

Add/Remove Port B to the OVS br-int with external-ids

In our case we will use the neutron OVS agent to plug the port on update
port event with the following external-ids: iface-id,iface-status, attached-mac
and node-uuid

备选方案¶

延迟 Neutron 端口绑定（端口绑定意味着在 SmartNIC 上设置所有 OVSDB/Openflows 配置），由 Neutron 稍后执行（在裸机启动后）。此方法的问题在于，我们无法保证规则何时会被编程，因此可能会在智能网卡仍在旧网络上编程时启动裸机。

数据模型影响¶

将在 Port 对象中添加一个新的 is_smartnic 布尔字段。

状态机影响¶

无

REST API 影响¶

REST API 将修改为支持新的 is_smartnic 字段。该字段将可被具有 baremetal observer 角色的用户读取，并可被具有 baremetal admin 角色的用户写入。

对端口的 is_smartnic 字段的更新将受到与用于其他连接相关字段（链路本地连接等）相同的限制 - 它们将限制为处于 enroll、inspecting 和 manageable 状态的节点。

客户端 (CLI) 影响¶

“ironic” CLI¶

无

“openstack baremetal” CLI¶

openstack baremetal CLI 将更新为支持获取和设置端口上的 is_smartnic 字段。

RPC API 影响¶

无

驱动程序 API 影响¶

无

Nova 驱动程序影响¶

无

Ramdisk 影响¶

无

安全影响¶

智能网卡隔离

两种用例都在智能网卡上运行基础设施功能，第一种用例还运行控制平面功能。

这需要在不受信任的裸机主机和智能网卡之间进行适当的隔离，以防止通过暴露给主机的网络接口以及通过平台 BMC 等侧信道进行任何直接或间接访问。

这种隔离由智能网卡设备和/或硬件平台供应商实现。这种隔离有多种方法，从完全物理断开智能网卡与平台 BMC 的连接，到平台具有受信任的 BMC，其中 BMC 将裸机主机视为不受信任的实体，并限制其功能/对平台的访问。

如果没有这种隔离，不受信任的裸机租户可能能够访问配置网络，并且在第二种情况下可能能够破坏控制平面。

适当的隔离取决于平台硬件/固件，不能由 ironic 直接强制/保证。智能网卡用例的用户应通过明确的文档了解这一点，并在启用此类用例时指导他们验证平台上是否存在适当的隔离。

安全组

这将允许使用 Neutron OVS 代理管道。管道中的一个功能是安全组，它将增强在云中使用裸机时的安全模型。

安全凭据

运行 Neutron OVS 代理的节点（智能网卡或远程，根据用例）应配置 Neutron 服务器的消息总线凭据。

此外，对于第二种用例，应为智能网卡端口配置 SSH 公钥和 OVSDB SSL 证书。

其他最终用户影响¶

裸机管理员需要手动更新 SmartNIC 配置。

可扩展性影响¶

无

性能影响¶

无

其他部署者影响¶

无

开发人员影响¶

无

实现¶

负责人¶

主要负责人: hamdyk - hamdy@mellanox.com

工作项¶

更新 Neutron 网络接口，以便将 ironic 端口中的 Smart NIC 配置填充到 Neutron 端口 binding:profilei 属性中。
更新 network_interface 和 common.neutron 如上所述
更新部署接口如上所述
文档更新。

依赖项¶

无，但 Neutron 规范 [1]、[2] 和 [3] 依赖于此规范。

测试¶

Mellanox CI Jobs 使用 Bluefield SmartNIC 进行测试

升级和向后兼容性¶

无

文档影响¶

更新 multitenancy.rst 以设置 SmartNIC 配置
在 admin/security.rst 下记录安全影响/指南

智能网卡网络