Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

5.5. 覆盖用于忽略 Ceph Storage 节点的参数

所有节点具有托管 Ceph OSD 的角色，如 CephStorage 或 ComputeHCI，使用 第 5.3 节 “映射 Ceph Storage 节点磁盘布局” 中创建的全局 devices 和 dedicated_devices 列表。这些列表假定所有这些服务器具有相同的硬件。如果有具有此硬件的服务器不相同，则必须使用特定于节点的磁盘配置更新不同设备和 dedicated_ devices 列表的详细信息。

注意

托管 Ceph OSD 的角色在 roles_data.yaml 文件中包括 OS::TripleO::Services::CephOSD 服务。

没有与其他节点相同的硬件的 Ceph Storage 节点可能会导致性能问题。在 Red Hat OpenStack Platform (RHOSP)环境中，标准节点和带有特定于节点覆盖的节点之间存在更多差异，这是可能的性能损失。

5.5.1. 特定于节点的磁盘配置
复制链接

必须为没有相同硬件的服务配置 director。这称为特定于节点的磁盘配置。

您可以使用以下方法之一创建特定于节点的磁盘配置：

  • 自动 ：您可以生成 JSON heat 环境文件，以自动创建特定于节点的磁盘配置。
  • 手动：您可以更改节点磁盘布局，以创建特定于节点的磁盘配置。

5.5.1.1. 为 Ceph 设备生成 JSON heat 环境文件
复制链接

您可以使用 /usr/share/openstack-tripleo-heat-templates/tools/make_ceph_disk_list.py 脚本从裸机置备服务(ironic)的内省数据自动创建有效的 JSON heat 环境文件。使用此 JSON 文件将特定于节点的磁盘配置传递给 director。

流程

  1. 为您要部署的 Ceph 节点导出来自裸机置备服务的内省数据： 

    openstack baremetal introspection data save oc0-ceph-0 > ceph0.json
openstack baremetal introspection data save oc0-ceph-1 > ceph1.json
...

  2. 将 实用程序复制到 undercloud 上 stack 用户的主目录，并使用它来生成 node_data_lookup.json 文件。 

    ./make_ceph_disk_list.py -i ceph*.json -o node_data_lookup.json -k by_path

  3. 将托管 Ceph OSD 的所有节点的 openstack baremetal introspection data save 命令的内省数据文件传递给 utility，因为您在部署过程中只能定义 NodeDataLookup。-i 选项可以采用类似 *.json 的表达式，或者将文件列表作为输入。

    使用 -k 选项定义您要用来识别 OSD 磁盘的裸机置备磁盘数据结构的密钥。不要使用 name，因为它会生成类似 /dev/sdd 的设备文件，这在重启过程中可能并不总是指向同一设备。反之，请使用 by_path。如果没有指定 -k，则这是默认设置。

    裸机置备服务保留系统中的其中一个可用磁盘作为根磁盘。实用程序始终从生成的设备列表中删除根磁盘。

  4. 可选： 您可以使用 ./make_ceph_disk_list.py -help 查看其他可用选项。

  5. 在部署 overcloud 时，将 node_data_lookup.json 文件包含与您环境相关的任何其他环境文件： 

    $ openstack overcloud deploy \
--templates \
…
-e <existing_overcloud_environment_files> \
-e node_data_lookup.json \
…

5.5.1.2. 更改 Ceph Storage 节点中的磁盘布局
复制链接

重要

非同构 Ceph Storage 节点可能会导致性能问题。在 Red Hat OpenStack Platform (RHOSP)环境中，标准节点和带有特定于节点覆盖的节点之间存在更多差异，这是可能的性能损失。

要将特定于节点的磁盘配置传递给 director，您必须将 heat 环境文件（如 node-spec-overrides.yaml ）传递给 openstack overcloud deploy 命令，文件内容必须通过机器唯一 UUID 和本地变量的列表来标识各个服务器，以覆盖全局变量。

您可以为每个独立的服务器或裸机置备服务(ironic)数据库提取机器唯一的 UUID。

备注
在以下步骤中，您可以创建包含嵌入式有效 JSON 的有效 YAML 环境文件。您还可以使用 make_ceph_disk_list.py 生成完整的 JSON 文件，并将它传递到部署命令，就像它是 YAML 一样。如需更多信息，请参阅为 Ceph 设备生成 JSON heat 环境文件。

流程

  1. 要找到单个服务器的 UUID，请登录到服务器并输入以下命令： 

    $ dmidecode -s system-uuid

  2. 要从裸机置备服务数据库中提取 UUID，请在 undercloud 上输入以下命令： 

    $ openstack baremetal introspection data save NODE-ID | jq .extra.system.product.uuid
    警告

    如果 undercloud.conf 在 undercloud 安装或升级和内省之前没有 inspection_extras = true，则 machine-unique UUID 不在裸机置备服务数据库中。

    重要

    machine-unique UUID 不是裸机置备服务 UUID。

    有效的 node-spec-overrides.yaml 文件可能类似如下： 

    parameter_defaults:
  NodeDataLookup: {"32E87B4C-C4A7-418E-865B-191684A6883B": {"devices": ["/dev/sdc"]}}

  3. 前两行后面的所有行都必须是有效的 JSON。使用 jq 命令验证 JSON 是否有效。

    1. 从文件中删除前两行(parameter_defaults: 和 NodeDataLookup:)。
    2. 运行 cat node-spec-overrides.yaml | jq .

  4. 随着 node-spec-overrides.yaml 文件增长，您还可以使用 jq 命令来确保嵌入的 JSON 有效。例如，由于 devices 和 dedicated_devices 列表必须有相同的长度，因此在开始部署前，使用以下命令来验证它们的长度是否相同。在以下示例中，node-spec-c05-h17-h21-h25-6048r.yaml 在机架 c05 中有三个服务器，其中插槽 h17、h21 和 h25 缺失磁盘。 

    (undercloud) [stack@b08-h02-r620 tht]$ cat node-spec-c05-h17-h21-h25-6048r.yaml | jq '.[] | .devices | length'
33
30
33
(undercloud) [stack@b08-h02-r620 tht]$ cat node-spec-c05-h17-h21-h25-6048r.yaml | jq '.[] | .dedicated_devices | length'
33
30
33
(undercloud) [stack@b08-h02-r620 tht]$
  5. 在验证了 JSON 被验证后，这两个行使其成为有效的环境 YAML 文件(parameter_defaults: 和 NodeDataLookup:)，并在部署中包括带有 -e 的行。在以下示例中，更新的 heat 环境文件对 Ceph 部署使用 NodeDataLookup。所有服务器都有一个设备列表，带有 35 磁盘的设备列表，但其中之一缺少磁盘。此环境文件只覆盖那个单一节点的默认设备列表，并为其提供必须使用的 34 磁盘列表，而不是全局列表。

  6. 验证 JSON 后，再添加这两行使其成为有效的环境 YAML 文件(parameter_defaults: 和 NodeDataLookup:)，并在部署命令中包括它并带有 -e。

    在以下示例中，更新的 heat 环境文件对 Ceph 部署使用 NodeDataLookup。所有服务器都有一个设备列表，带有 35 磁盘的设备列表，但其中之一缺少磁盘。此环境文件只覆盖那个单一节点的默认设备列表，并为该节点提供必须使用的 34 磁盘列表，而不是全局列表。 

    parameter_defaults:
  # c05-h01-6048r is missing scsi-0:2:35:0 (00000000-0000-0000-0000-0CC47A6EFD0C)
  NodeDataLookup: {
    "00000000-0000-0000-0000-0CC47A6EFD0C": {
      "devices": [
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:1:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:32:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:2:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:3:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:4:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:5:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:6:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:33:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:7:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:8:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:34:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:9:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:10:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:11:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:12:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:13:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:14:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:15:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:16:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:17:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:18:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:19:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:20:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:21:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:22:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:23:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:24:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:25:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:26:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:27:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:28:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:29:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:30:0",
    "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:31:0"
        ],
      "dedicated_devices": [
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
    "/dev/disk/by-path/pci-0000:84:00.0-nvme-1"
        ]
      }
    }

5.5.2. 更改 BlueStore block.db 大小
复制链接

BlueStore block.db 是数据片段和 BlueStore write-ahead 日志(WAL)的数据库。可以通过两种方法更改数据库大小。选择这些方法之一以更改大小。

使用 ceph-volume 时，使用以下步骤覆盖 block.db 大小。当 osd_scenario: lvm. ceph-volume 会自动设置 block.db 大小。但是，您可以在高级场景中覆盖 block.db 大小。

以下示例使用 ceph-ansible 主机变量，而不是 Ceph 配置文件覆盖，因此使用的 block_db_size 传递给 ceph-volume 调用。

流程

  1. 创建一个 JSON 环境文件，其内容类似以下示例，但根据您的要求替换值： 

    {
  "parameter_defaults": {
    "NodeDataLookup": {
      "32e87b4c-c4a7-41be-865b-191684a6883b": {
        "block_db_size": 3221225472
      },
      "ea6a84d6-cf89-4fe2-b7bd-869b3fe4dd6b": {
        "block_db_size": 3221225472
      }
    }
  }
}

  2. 在部署 overcloud 时，包括与环境相关的任何其他环境文件的 JSON 文件： 

    $ openstack overcloud deploy \
--templates \
…
-e <existing_overcloud_environment_files> \
-e <json_environment_file>  \
…

使用 ceph-disk 时，使用以下步骤覆盖 block.db 大小。当 osd_scenario: non-collocated 或 osd_scenario: collocated 时使用 ceph-disk。

以下示例对特定节点使用 Ceph 配置覆盖来设置 blustore_block_db_size。使用 ceph-volume 时会忽略此 Ceph 配置选项，但 ceph-disk 使用此配置选项。

流程

  1. 创建一个 JSON 环境文件，其内容类似以下示例，但根据您的要求替换值： 

    {
  "parameter_defaults": {
    "NodeDataLookup": {
      "32e87b4c-c4a7-41be-865b-191684a6883b": {
        "ceph_conf_overrides": {
          "osd": {
            "bluestore_block_db_size": 3221225472
          }
        }
      },
      "ea6a84d6-cf89-4fe2-b7bd-869b3fe4dd6b": {
        "ceph_conf_overrides": {
          "osd": {
            "bluestore_block_db_size": 3221225472
          }
        }
      }
    }
  }
}

  2. 在部署 overcloud 时，包括与环境相关的任何其他环境文件的 JSON 文件： 

    $ openstack overcloud deploy \
--templates \
…
-e <existing_overcloud_environment_files> \
-e <json_environment_file>  \
…
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2026 Red Hat返回顶部