应用预定义的系统硬件配置，一步到位

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

Ironic 的普及以及部署数量，无论是集成 OpenStack 还是独立部署，都在持续增长。与此同时，每个部署管理的裸机系统数量也在增加。这些趋势促使运维人员要求改进硬件系统配置的运营管理——BIOS 设置、RAID、启动模式、网络端口、清单等。解决方案必须降低运营成本并缩短满足租户对新部署和激活的裸机系统的需求的时间。

以下用例将受益于此提案

• 在部署具有相似硬件能力的裸机系统群组时，硬件配置正确、一致且快速

• 生产环境，其中物理系统被重新用于需要不同配置的工作负载，且快速周转至关重要

• 单个系统配置的清单

为了实现这一目标，潜在的解决方案应提供

• 从常用或“黄金”系统创建裸机系统配置

• 管理存储在指定存储位置的配置

• 将存储的配置应用于裸机系统

• 在应用完整或部分配置后，获取系统的完整配置

• 通过减少时间（通常通过减少所需的重启次数）来加速硬件配置，这取决于系统和 ironic 硬件类型支持

本规范提出了一种通用的解决方案，包括新的清理和部署步骤，用于处理系统配置。每个硬件类型可以根据其自身及其系统的功能来实现它。

问题描述

大量具有相同或相似硬件的系统到达。用户希望对其所有硬件进行相同的配置。

• 在 ironic 中，这可能是一项繁琐且容易出错的任务。

• Ironic 当前具有配置 BIOS 和 RAID 的 API，但它没有提供供应商提供的所有子系统的接口。

• 应用配置可能需要花费大量时间，通常需要多次重启。

当在同一系统上运行不同的工作流程时，每个工作流程需要不同的硬件配置，也面临相同的挑战。

提议的变更

简介

本规范中使用以下概念

配置模具

一份描述硬件系统当前或所需配置的文档。它还提供了一个系统硬件配置的清单。

本规范建议

• 添加新的可选清理 [1] 和部署 [2] 步骤，这些步骤可以一步完成系统硬件的完整配置。它们可以应用具有足够相似硬件能力的系统的保存配置。还提出了获取和持久存储系统配置的步骤。

  • export_configuration –

    获取系统的硬件配置并将其持久存储为配置模具，以便将其用于配置其他具有足够能力的系统，以及作为清单。更多详细信息请参见 导出配置。

  • import_configuration –

    将现有且持久存储的配置模具中描述的硬件配置应用于具有足够能力的系统。更多详细信息请参见 导入配置。

  • import_export_configuration –

    将同一系统的硬件配置导入然后导出，作为一个原子步骤，从 ironic 的清理和部署机制的角度来看。这可以进一步减少配置系统所需的时间，而不是单独的导入和导出步骤序列。更多详细信息请参见 导入和导出配置。

• 定义配置模具的供应商无关内容的的数据格式。它包含一个支持的每个硬件子系统（RAID 和 BIOS）的部分。对于 ironic 已经提供配置支持的子系统（同样是 RAID 和 BIOS），所需的配置尽可能以 ironic 的术语表示。

  为了支持 ironic 定义之外的硬件配置，但供应商、系统及其硬件类型可以以特定于系统的方式提供，建议使用第三部分，OEM。OEM 部分也可以用于指定 ironic 已经支持的配置。OEM 部分的内容特定于系统及其硬件类型。

  更多详细信息以及示例，请参见 配置数据格式。

• 描述配置模具的持久存储，用于集成 OpenStack 和独立 ironic 环境，以及 ironic 及其用户如何与它们交互。请参见 配置数据存储。

• 声明在本规范目的范围内被认为是完整的实现。如果它提供所有三个（3）对的清理和部署步骤，并支持所有定义的配置模具部分（目前是 BIOS 和 RAID），则实现将被认为完整。此外，必须支持集成 OpenStack 和独立 ironic 环境的配置模具的持久存储。

• 提供一种替代方案，而不是替代 ironic 当前可用的粒度配置步骤，这些步骤在单个子系统上运行：RAID 和 BIOS。它与 ironic 当前的功能的比较在 替代方案 中描述。

• 概述 idrac 硬件类型由 MVP（最小可行产品）实现，在 idrac-redfish 实现 中。我们旨在提供所有三个（3）对的清理和部署步骤。在 MVP 中，将仅支持 OEM 配置模具部分。两种持久配置模具存储方法都将实现和支持。

• 说明通用的 redfish 硬件类型的可能实现，在 redfish 实现 中。

目标

通过本规范，我们将实现以下目标

• 定义一个 ironic 硬件类型框架，该框架提供更高效的裸机硬件配置

• 促进一致的方法来加速裸机硬件配置，在硬件系统及其 ironic 硬件类型支持的情况下，减少重启次数

• 描述 idrac 硬件类型提供的第一个 MVP 实现

非目标

以下内容被认为不属于本规范的范围

• 所有硬件类型实施该方法；它是可选的

• 要求硬件类型的实施完整；它可以是部分的

导出配置

导出配置清理/部署步骤提取指示服务器（“黄金服务器”）的现有配置，并将其存储在指定的存储位置，以便在 导入配置 清理/部署步骤中使用。

清理/部署步骤的详细信息是

接口

管理界面

名称

export_configuration

详情

获取正在运行步骤的服务器的配置，并将其以 ironic 配置的特定格式存储在指示的存储中。

优先级

0

可停止

否

参数

• 用于保存配置的位置 URL

清理/部署步骤配置示例

{
  "interface": "management",
  "step": "export_configuration",
  "args": {
    "export_configuration_location": "https://server/edge_dell_emc-poweredge_r640"
  }
}

配置导出的工作流程包括 3 个部分

1. 获取当前节点的配置（驱动程序特定）

2. 将配置转换为通用格式（转换是驱动程序特定的；格式是通用的，请参见 配置数据格式）

3. 将存储项保存到指定的存储（所有驱动程序通用，请参见 配置数据存储）

使用 export_configuration 不是强制性的。如果之前或以其他方式获取了配置，用户也可以直接将其上传到存储。

导入配置

配置可用后，用户可以在导入配置清理/部署步骤中使用它来配置服务器。

清理/部署步骤的详细信息是

接口

管理界面

名称

import_configuration

详情

通过给定的位置 URL 获取预创建的配置，并将其导入到给定的服务器。

优先级

0

可停止

否

参数

• 用于获取所需配置的位置 URL

示例

{
  "interface": "management",
  "step": "import_configuration",
  "args": {
    "import_configuration_location": "https://server/edge_dell_emc-poweredge_r640"
  }
}

配置导入的工作流程包括 3 个部分

1. 使用给定的配置位置和 ironic 的存储设置，从存储中获取配置（所有驱动程序通用）。

2. 将配置转换为驱动程序特定的格式（驱动程序特定）

3. 应用配置（驱动程序特定）

• 配置模具中未指定的节保持不变，例如，可以配置 BIOS 设置的子集，而其他 BIOS 设置和 RAID 设置保持不变。

• 如果遇到错误，清理/部署步骤将失败。失败后，无法保证系统配置的状态，因为配置的应用取决于系统和 ironic 硬件类型，并且存在许多可能的故障模式。定义的子系统配置序列和事务性回滚语义似乎不适用。

• 当步骤失败时，ironic 节点将被置于 clean failed 或 deploy failed 状态，并且节点的 last_error 字段可能包含有关故障原因的更多信息。

• 成功应用配置对节点的字段（如 BIOS 和 RAID 配置）没有副作用。

警告

根据每个供应商的功能，导入可以是一个强大的步骤，可以配置各种内容。用户和供应商需要了解这些功能，并确保不要覆盖不打算替换的设置，例如删除 RAID 设置或静态 BMC IP 地址。

导入和导出配置

导入和导出配置清理/部署步骤是一个组合步骤，它将导入和导出一个接一个地执行为原子操作。这可用于在配置后获取清单，并且在未配置系统的所有方面时，但需要了解所有方面的结果时很有用。

清理/部署步骤的详细信息是

接口

管理界面

名称

import_export_configuration

详情

从存储中获取预创建的配置，将其导入到给定的服务器，并导出结果配置。

优先级

0

可停止

否

参数

• 用于获取所需配置的位置 URL

• 用于保存配置的位置 URL

清理/部署步骤配置示例

{
  "interface": "management",
  "step": "import_export_configuration",
  "args": {
      "import_configuration_location": "https://server/edge_dell_emc-poweredge_r640"
      "export_configuration_location": "https://server/edge_dell_emc-poweredge_r640_server005"
  }
}

配置导入和导出的工作流程包括以下部分

1. 执行步骤 导入配置 中的工作流程

2. 导入成功后，执行步骤 导出配置 中的工作流程

配置数据格式

存储可重用配置的格式是 JSON 格式，包含 3 个部分

• bios – reset 指示在应用 settings 部分中列出的 BIOS 属性键值对中的设置之前是否需要重置，如应用 BIOS 配置步骤 [3] 中所述。如果 reset 为 false，则未包含在 settings 部分中的设置保持不变。

• raid – 如 RAID 创建配置步骤，具有键值对设置和 target_raid_config 属性 [4]

• oem – 驱动程序特定的部分，其中包含不适合 bios 和 raid 部分的所有内容，以及可以处理此数据的接口名称。接口名称可用于区分此配置数据是用于哪个硬件类型，并在导入期间进行验证，以便尽早捕获不兼容性。此部分的数据格式由实现接口控制，唯一的限制是它需要适合 JSON 属性。

• oem 和供应商无关的部分（如 bios 和 raid）之间没有重叠。

• 如果在导入期间确定存在重叠，则配置数据将被认为无效，清理/部署步骤将失败。

导出数据格式示例

{
  "bios": {
    "reset": false,
    "settings": [
      {
        "name": "ProcVirtualization",
        "value": "Enabled"
      },
      {
        "name": "MemTest",
        "value": "Disabled"
      }
    ]
  }
  "raid": {
    "create_nonroot_volumes": true,
    "create_root_volume": true,
    "delete_existing": false,
    "target_raid_config": {
      "logical_disks": [
        {
          "size_gb": 50,
          "raid_level": "1+0",
          "controller": "RAID.Integrated.1-1",
          "volume_name": "root_volume",
          "is_root_volume": true,
          "physical_disks": [
            "Disk.Bay.0:Encl.Int.0-1:RAID.Integrated.1-1",
            "Disk.Bay.1:Encl.Int.0-1:RAID.Integrated.1-1"
          ]
        },
        {
          "size_gb": 100,
          "raid_level": "5",
          "controller": "RAID.Integrated.1-1",
          "volume_name": "data_volume",
          "physical_disks": [
            "Disk.Bay.2:Encl.Int.0-1:RAID.Integrated.1-1",
            "Disk.Bay.3:Encl.Int.0-1:RAID.Integrated.1-1",
            "Disk.Bay.4:Encl.Int.0-1:RAID.Integrated.1-1"
          ]
        }
      ]
    }
  }
  "oem": {
    "interface": "idrac-redfish",
    "data": {
      "SystemConfiguration": {
        "Model": "PowerEdge R640",
        "ServiceTag": "8CY9Z99",
        "TimeStamp": "Fri Jun 26 08:43:15 2020",
        "Components": [
          {
            [...]
            "FQDD": "NIC.Slot.1-1-1",
            "Attributes": [
              {
              "Name": "BlnkLeds",
              "Value": "15",
              "Set On Import": "True",
              "Comment": "Read and Write"
              },
              {
              "Name": "VirtMacAddr",
              "Value": "00:00:00:00:00:00",
              "Set On Import": "False",
              "Comment": "Read and Write"
              },
              {
              "Name": "VirtualizationMode",
              "Value": "NONE",
              "Set On Import": "True",
              "Comment": "Read and Write"
              },
            [...]
            ]
          }
        ]
      }
  }
}

oem 部分的示例数据描绘了来自 Dell SCP 文件（请参见 idrac-redfish 实现）的片段，其中包含有关配置来源的一些元数据（Model、ServiceTag、TimeStamp），并且在 Components 部分中列出了可以在导入期间应用的属性，并由 Set On Import 属性控制。

配置数据存储

硬件类型之间的通用功能是配置存储，将为所有供应商实施，以便在各自的实施中使用。

存储的要求是

1. 支持节点多租户

2. 支持多个调度器

3. 支持独立 ironic 模式

4. 支持具有临时 ironic 数据库的 ironic 运营商

5. 用户可以管理（列出、创建、查看、编辑、删除）配置模具

为了满足这些要求，建议使用存储解决方案

• 使用完整的 URL 指示配置模具位置

• Swift 用作存储后端

  • 完整的 URL 指向 Swift 容器内的对象

  • 访问受项目/租户/帐户限制

  • 使用 HTTP GET 和 HTTP PUT 获取和存储数据

  • ironic 服务帐户具有对使用的容器的访问权限

  • 用户可以通过直接访问 Swift 容器来管理配置模具

• Web 服务器用作独立 ironic 模式的存储后端

  • 仅用于 Ironic 独立模式或当只有一个租户时，因为这不能防止访问其他租户的数据。

  • 使用 HTTP GET 和 HTTP PUT 获取和存储数据。Web 服务器需要配置 HTTP PUT（默认情况下未启用）

  • 基本身份验证与 ironic 配置中的预定义凭据一起用于访问数据

  • 用户可以通过直接访问 Web 服务器来管理配置模具

• 将来可以添加其他存储后端

为了实现这一点，将进行以下更改

添加新设置

[molds]storage
[molds]user
[molds]password

[molds]storage 用于定义使用的存储后端。默认情况下，它将是 Swift，可以选择配置 Web 服务器。将来可以添加更多选项。

[molds]user 和 [molds]password 在 Web 服务器配置为存储后端时使用。Ironic 将使用这些信息进行 Base64 编码，并将其作为 HTTP 请求的头部添加。默认情况下，它们将为空，表示未使用授权。

获取存储配置数据的流程

1. 给定配置模版的完整 URL 和在 [molds]storage 中配置的存储机制，使用适当的凭据获取数据。

2. 处理任何错误，包括访问权限错误。如果遇到错误，则步骤将失败。

存储配置数据的流程

1. 给定配置模版的完整 URL 和在 [molds]storage 中配置的存储机制，使用适当的凭据存储数据。

2. 处理任何错误，包括访问权限错误。如果遇到错误，则步骤将失败。

Swift 支持

对于 Swift，作为发起清理或部署的最终用户与实际执行清理或部署的服务用户不同，因此有必要允许 ironic conductor（服务用户）访问步骤中使用的 Swift 容器。将访问所有租户容器存在安全风险，这在 安全影响 部分中描述。

Web 服务器支持

对于 Web 服务器授权，将从 [molds]user 和 [molds]password 使用基本身份验证。强烈建议在 Web 服务器上配置 TLS。

idrac-redfish 实现

为了使 iDRAC 实现这些提议的步骤，它将使用服务器配置配置文件 (SCP) [5]，该配置文件允许导出现有的配置服务器并将相同的配置文件导入到另一个服务器。BIOS、RAID、NIC 等不同子系统的设置包含在配置文件中。

该实现将转换 SCP 数据格式和 ironic 数据格式之间的配置。在第一个版本 (MVP) 中，所有 SCP 数据都以原样导出到并从 oem 部分导出，没有任何转换。在后续版本中，这将改进为开始使用 bios 和 raid 部分。该实现将使用 Redfish 协议。由于这是 Redfish 服务中 OEM 部分的一部分，因此将在 sushy-oem-idrac 库中实现通信。在 MVP 完成后的下一个版本中，将在 idrac-redfish 接口的 ironic 部分实现 SCP 数据格式和 ironic 数据格式之间的转换。

在 R640 上比较使用单独的 BIOS 和 RAID 配置作业与 SCP 方法的配置运行时，差异为 11 分钟与 7 分钟，其中 SCP 在一次重启内更快。

redfish 实现

本节描述了如何为通用的 redfish 驱动程序实现这些步骤。与在 idrac-redfish 实现 中描述的 idrac-redfish 提议实现不同，后者使用 iDRAC 特定功能来实现这些步骤，Redfish 规范相反，没有一个资源和操作可以一次性接受所有配置数据，并且 redfish 的实现需要采取不同的方法。

这说明了 Redfish 服务中可用的专用资源如何组装起来用于单个步骤。实施此内容不在本规范的范围内。

以下描述了此实现将如何支持 RAID、BIOS 的配置。

对于 import_configuration

1. 给定包含 bios 和 raid 部分的配置模版。

2. 应用 RAID 配置以创建具有立即应用或在重置时应用的卷（如果更改需要重启）。

3. 将 BIOS 更新应用于待定设置，并在重置时应用。

4. 重启系统以使待定更改生效。

与 ironic 中现有功能的区别

1. 只有一个步骤，而不是两个专用的步骤。

2. 由于所有配置在重启之前组装在一起，因此重启次数较少（取决于 RAID 是否需要重启）。

对于 export_configuration

1. 使用 BIOS 资源获取当前的 BIOS 设置。

2. 使用存储资源和相关资源获取当前的 RAID 设置。

3. 将结果转换为配置模版的格式。

与 ironic 中现有功能的区别

1. 没有一个步骤可以获取各个子系统中的当前配置。

2. 最接近实现此目标的方法是获取节点的 raid_config 字段并获取 BIOS 属性，然后将其转换为使用现有 RAID 和 BIOS 步骤的部署模板。

对于 import_export_configuration，将 import_configuration 和 export_configuration 的实现结合起来。

备选方案

我们可以继续仅支持当前的、细粒度的硬件配置部署和清理步骤。

ironic 中当前可用的最接近的功能是部署模板，这些模板可以组装几个现有的步骤。以同样的方式，这些部署模板可以根据需要为尽可能多的系统重用。但是，将部署模板与提议的解决方案进行比较，目前

• 没有功能可以从已经配置的系统获取配置，用户必须手动或通过脚本构建初始配置文件。为了使其更容易，可以使用从已部署节点缓存的 BIOS 和 RAID 设置，但这种重用仍然没有内置在 ironic 中。

• 根据供应商的功能，每个步骤可能需要重启才能完成。例如，iDRAC BIOS 配置应用需要重启才能生效并认为该步骤已完成。目前 ironic 无法将需要重启的几个步骤排队，然后通过一次重启完成所有步骤。为了开始下一个步骤，需要先完成上一个步骤。该提议使其能够在导入步骤内部处理此问题，也就是说，如果这是硬件类型实现此方式，它可以为 BIOS、RAID 配置创建 2 个任务，然后重启并监视这两个任务完成以认为该步骤已完成。

• 使用 OEM 部分，每个供应商可以添加支持配置更多当前无法使用通用（与供应商无关）ironic 清理/部署步骤的设置的功能。

本提议不建议替换当前的清理/部署步骤和部署模板，而是添加一种用于系统配置的替代方法。

数据模型影响

无

状态机影响

无

REST API 影响

无

客户端 (CLI) 影响

无

RPC API 影响

无

驱动程序 API 影响

无

Nova 驱动程序影响

无

Ramdisk 影响

无

安全影响

JSON 将用作用户输入。它将被验证、清理并视为文本。通用的存储工具将使用 Python 的 json.loads 在检索时，并使用 json.dumps 在存储数据时。如果对于供应商特定的实现，例如 OEM 部分，需要额外的验证和清理，则需要在驱动程序的实现中添加这些内容。

配置模版被认为是敏感数据，它们也可能包含纯文本密码，例如，用于 BMC。配置模版的存储实现将支持授权和租户分离。建议操作员添加额外的安全措施，例如，配置存储后端加密和 Web 服务器的 TLS。

由于清理/部署是由 ironic 服务帐户执行的，而不是发起清理或部署的用户，因此 ironic 服务帐户需要访问用户提供的 Swift 容器。在多租户、最终用户可访问的 Ironic API 中，这可能导致访问不属于租户的数据，例如，通过猜测或以某种方式找到另一个租户的 URL 并将其提供给具有访问权限的 ironic，而最终用户没有访问权限。需要在未来的版本中单独解决此问题。可能还有其他受此限制影响并从解决此问题中受益的用例。

其他最终用户影响

配置项目可以累积在存储中，因为没有默认的超时或删除一段时间后配置的逻辑，因为这些配置项目应该在节点的清理或部署后可用。如果用户不再需要可重用的配置项目，则他们应该自己从存储中删除这些项目。

这添加了新的配置部分 [molds] 以控制存储位置。提供了默认值。

可扩展性影响

无

性能影响

根据硬件类型实现，部署可能会更快。处理配置模版时，它会在内存中读取，但预计这些配置模版不会很大。

此外，基于供应商的实现，这些步骤可以是同步的或异步的。如果步骤是同步的，这将消耗一个长期线程，操作员可能需要调整工作线程的数量。

其他部署者影响

需要配置存储后端，Swift 或 Web 服务器。

开发人员影响

将提供新的清理和部署步骤，每个驱动程序都可以实现这些步骤。它们是可选的，其他开发人员可以在需要时随时实现这些步骤。

实现

负责人

主要负责人

• Aija Jaunteva (@ajya, aija.jaunteva@dell.com)

• Richard Pioso (@rpioso, richard.pioso@dell.com)

其他贡献者

无

工作项

对于通用功能

• 实现配置存储的通用功能

  • Swift 支持

  • Web 服务器支持

对于 idrac-redfish 实现

• 实现新的清理和部署步骤的初始 idrac 硬件类型派生，这些步骤使用 Redfish 协议 (MVP)

• 更新 iDRAC 驱动程序文档

• 增强 idrac 硬件类型实现以支持配置数据的 bios 部分

• 增强 idrac 硬件类型实现以支持配置数据的 raid 部分

依赖项

无

测试

目前，tempest 测试不在范围内，但在未来可以为实现新的清理和部署步骤的每个驱动程序添加第三方持续集成 (CI) 测试。

升级和向后兼容性

此更改旨在向后兼容。新的清理和部署步骤是可选的。当尝试在不实现这些步骤的硬件类型上使用它们时，清理或部署将失败，并显示错误消息，说明节点不支持这些步骤。

文档影响

节点清理文档 [6] 已更新，以描述 idrac-redfish 的管理界面下的新的清理步骤。

参考资料

[1]

https://docs.openstack.org/ironic/latest/admin/cleaning.html#cleaning-steps

[2]

https://docs.openstack.org/ironic/latest/admin/node-deployment.html#node-deployment-deploy-steps

[3]

https://docs.openstack.org/ironic/latest/admin/bios.html#apply-bios-configuration

[4]

https://opendev.org/openstack/ironic/src/branch/master/ironic/drivers/raid_config_schema.json

[5]

https://downloads.dell.com/manuals/all-products/esuprt_solutions_int/esuprt_solutions_int_solutions_resources/dell-management-solution-resources_white-papers15_en-us.pdf

[6]

https://docs.openstack.org/ironic/latest/admin/cleaning.html