流程

1. 创建清单文件后，将文件保存到 stack 用户的主目录(/home/stack/instackenv.json)。

2. 初始化 stack 用户，然后将 instackenv.json 清单文件导入到 director：

   $ source ~/stackrc
   $ openstack overcloud node import ~/instackenv.json

   openstack overcloud node import 命令导入清单文件，并将每个节点注册到 director。

3. 将内核和 ramdisk 镜像分配给每个节点：

   $ openstack overcloud node configure <node>

   结果

   节点在 director 中注册和配置。

流程

1. 触发硬件内省以检索每个节点的硬件属性：

   $ openstack overcloud node introspect --all-manageable --provide

   • --all-manageable 选项仅内省处于受管状态的节点。在此示例中，所有节点都处于受管理状态。

   • --provide 选项会在内省后将所有节点重置 为活动状态。

     重要

     确保此过程成功完成。它可能需要 15 分钟来检查这些裸机节点。

2. 检索节点列表来识别它们的 UUID：

   $ openstack baremetal node list

3. 在每个节点的 properties/capabilities 参数中添加 profile 选项，来手动将节点标记到特定的配置集。添加 profile 选项会将节点标记为相关的配置集。

   注意

   作为手动标记的替代选择，请使用 Automated Health Check (AHC)工具根据基准测试数据自动标记更多节点。

   例如，典型的部署包含三个配置文件： control、compute、和 ceph-storage。运行以下命令为每个配置集标记三个节点：

   $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
   $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 6faba1a9-e2d8-4b7c-95a2-c7fbdc12129a
   $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 6faba1a9-e2d8-4b7c-95a2-c7fbdc12129a
   $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 484587b2-b3b3-40d5-925b-a26a2fa3036f
   $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' d010460b-38f2-4800-9cc4-d69f0d067efe
   $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' d930e613-3e14-44b9-8240-4f3559801ea6
   $ openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 484587b2-b3b3-40d5-925b-a26a2fa3036f
   $ openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' d010460b-38f2-4800-9cc4-d69f0d067efe
   $ openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' d930e613-3e14-44b9-8240-4f3559801ea6

步骤

1. 从每个节点的硬件内省检查磁盘信息。运行以下命令以显示节点的磁盘信息：

   (undercloud)$ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"

   例如，一个节点的数据可能会显示 3 个磁盘：

   [
     {
       "size": 299439751168,
       "rotational": true,
       "vendor": "DELL",
       "name": "/dev/sda",
       "wwn_vendor_extension": "0x1ea4dcc412a9632b",
       "wwn_with_extension": "0x61866da04f3807001ea4dcc412a9632b",
       "model": "PERC H330 Mini",
       "wwn": "0x61866da04f380700",
       "serial": "61866da04f3807001ea4dcc412a9632b"
     }
     {
       "size": 299439751168,
       "rotational": true,
       "vendor": "DELL",
       "name": "/dev/sdb",
       "wwn_vendor_extension": "0x1ea4e13c12e36ad6",
       "wwn_with_extension": "0x61866da04f380d001ea4e13c12e36ad6",
       "model": "PERC H330 Mini",
       "wwn": "0x61866da04f380d00",
       "serial": "61866da04f380d001ea4e13c12e36ad6"
     }
     {
       "size": 299439751168,
       "rotational": true,
       "vendor": "DELL",
       "name": "/dev/sdc",
       "wwn_vendor_extension": "0x1ea4e31e121cfb45",
       "wwn_with_extension": "0x61866da04f37fc001ea4e31e121cfb45",
       "model": "PERC H330 Mini",
       "wwn": "0x61866da04f37fc00",
       "serial": "61866da04f37fc001ea4e31e121cfb45"
     }
   ]

2. 输入 openstack baremetal node set --property root_device=，为节点设置根磁盘。包括用于定义根磁盘的最合适的硬件属性值。

   (undercloud)$ openstack baremetal node set --property root_device='{"serial":"<serial_number>"}' <node-uuid>

   例如：要将根设备设定为磁盘 2，其序列号为 61866da04f380d001ea4e13c12e36ad6，输入以下命令：

   (undercloud)$ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0

   注意

   确保配置每个节点的 BIOS 以包括从您选择的根磁盘引导。将引导顺序配置为首先从网络引导，然后从根磁盘引导。

   director 识别特定磁盘以用作根磁盘。运行 openstack overcloud deploy 命令时，director 置备 overcloud 镜像并将其写入根磁盘。

步骤

1. 要配置 director 使用 overcloud-minimal 镜像，创建包含以下镜像定义的环境文件：

   parameter_defaults:
     <roleName>Image: overcloud-minimal

2. 将 <roleName> 替换为角色的名称，并将 Image 加到角色名称的后面。以下示例显示了 Ceph 存储节点的 overcloud-minimal 镜像：

   parameter_defaults:
     CephStorageImage: overcloud-minimal

3. 在 roles_data.yaml 角色定义文件中，将 rhsm_enforce 参数设置为 False。

   rhsm_enforce: False

4. 将环境文件传递给 openstack overcloud deploy 命令。

流程

1. 在 /home/stack/templates/ 中生成 roles_data.yaml 文件的副本，以便您可以添加自定义角色：

   $ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/templates/roles_data_custom.yaml

2. 在 openstack overcloud deploy 命令中包含新的自定义角色文件。

流程

1. 打开 /home/stack/templates/roles_data_custom.yaml 文件。
2. 从 Controller 角色移除 Ceph MON 服务 OS::TripleO::Services::CephMon 的服务条目。

3. 将 OS::TripleO::Services::CephClient 服务添加到 Controller 角色：

   [...]
   - name: Controller # the 'primary' role goes first
     CountDefault: 1
     ServicesDefault:
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::CephMds
       - OS::TripleO::Services::CephClient
       - OS::TripleO::Services::CephExternal
       - OS::TripleO::Services::CephRbdMirror
       - OS::TripleO::Services::CephRgw
       - OS::TripleO::Services::CinderApi
   [...]

4. 在 roles_data_custom.yaml 文件的末尾，添加一个自定义 CephMon 角色，其中包含 Ceph MON 服务和所有其他必要的节点服务：

   - name: CephMon
     ServicesDefault:
       # Common Services
       - OS::TripleO::Services::AuditD
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::CertmongerUser
       - OS::TripleO::Services::Collectd
       - OS::TripleO::Services::Docker
       - OS::TripleO::Services::FluentdClient
       - OS::TripleO::Services::Kernel
       - OS::TripleO::Services::Ntp
       - OS::TripleO::Services::ContainersLogrotateCrond
       - OS::TripleO::Services::SensuClient
       - OS::TripleO::Services::Snmp
       - OS::TripleO::Services::Timezone
       - OS::TripleO::Services::TripleoFirewall
       - OS::TripleO::Services::TripleoPackages
       - OS::TripleO::Services::Tuned
       # Role-Specific Services
       - OS::TripleO::Services::CephMon

5. 输入 openstack flavor create 命令，为 CephMon 角色定义一个名为 ceph-mon 的新类别：

   $ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 ceph-mon

   注意

   有关此命令的更多信息，请输入： openstack flavor create --help。

6. 将此类别映射到一个新的配置文件，也称为 ceph-mon ：

   $ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="ceph-mon" ceph-mon

   注意

   有关此命令的更多信息，请输入 openstack flavor set --help。

7. 将节点标记到新的 ceph-mon 配置集中：

   $ openstack baremetal node set --property capabilities='profile:ceph-mon,boot_option:local' UUID

8. 将以下配置添加到 node-info.yaml 文件中，将 ceph-mon 类别与 CephMon 角色关联：

   parameter_defaults:
     OvercloudCephMonFlavor: CephMon
     CephMonCount: 3

流程

1. 打开 /home/stack/templates/roles_data_custom.yaml 文件。

2. 从 Controller 角色中删除 Ceph MDS 服务 OS::TripleO::Services::CephMds 的服务条目：

   [...]
   - name: Controller # the 'primary' role goes first
     CountDefault: 1
     ServicesDefault:
       - OS::TripleO::Services::CACerts
       # - OS::TripleO::Services::CephMds 1
       - OS::TripleO::Services::CephMon
       - OS::TripleO::Services::CephExternal
       - OS::TripleO::Services::CephRbdMirror
       - OS::TripleO::Services::CephRgw
       - OS::TripleO::Services::CinderApi
   [...]

   1

   注释掉此行。在下一步中，您要将此服务添加到新的自定义角色。

3. 在 roles_data_custom.yaml 文件的末尾，添加一个自定义 CephMDS 角色，其中包含 Ceph MDS 服务以及所有其他必要的节点服务：

   - name: CephMDS
     ServicesDefault:
       # Common Services
       - OS::TripleO::Services::AuditD
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::CertmongerUser
       - OS::TripleO::Services::Collectd
       - OS::TripleO::Services::Docker
       - OS::TripleO::Services::FluentdClient
       - OS::TripleO::Services::Kernel
       - OS::TripleO::Services::Ntp
       - OS::TripleO::Services::ContainersLogrotateCrond
       - OS::TripleO::Services::SensuClient
       - OS::TripleO::Services::Snmp
       - OS::TripleO::Services::Timezone
       - OS::TripleO::Services::TripleoFirewall
       - OS::TripleO::Services::TripleoPackages
       - OS::TripleO::Services::Tuned
       # Role-Specific Services
       - OS::TripleO::Services::CephMds
       - OS::TripleO::Services::CephClient 1

   1

   Ceph MDS 服务需要 admin 密钥环，您可以使用 Ceph MON 或 Ceph 客户端服务进行设置。如果您在没有 Ceph MON 服务的专用节点上部署 Ceph MDS，还必须将 Ceph 客户端服务包含在新的 CephMDS 角色中。

4. 输入 openstack flavor create 命令，为此角色定义一个名为 ceph-mds 的新类别：

   $ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 ceph-mds

   注意

   有关这个命令的更多信息，请输入 openstack flavor create --help。

5. 将新的 ceph-mds 类别映射到新配置文件，也称为 ceph-mds ：

   $ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="ceph-mds" ceph-mds

   注意

   有关此命令的更多信息，请输入 openstack flavor set --help。

6. 将节点标记到新的 ceph-mds 配置集中：

   $ openstack baremetal node set --property capabilities='profile:ceph-mds,boot_option:local' UUID

流程

1. 将以下 parameter_defaults 添加到自定义环境文件中，如 swift-external-params.yaml，并调整值以适合您的部署：

   parameter_defaults:
      ExternalSwiftPublicUrl: 'http://<Public RGW endpoint or loadbalancer>:8080/swift/v1/AUTH_%(project_id)s'
      ExternalSwiftInternalUrl: 'http://<Internal RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
      ExternalSwiftAdminUrl: 'http://<Admin RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
      ExternalSwiftUserTenant: 'service'
      SwiftPassword: 'choose_a_random_password'

   注意

   代码片段示例包含的参数值可能与您在环境中使用的值不同：

   • 远程 RGW 实例侦听的默认端口 8080。端口可能根据外部 RGW 的配置方式而有所不同。
   • overcloud 中创建的 swift 用户使用 SwiftPassword 参数定义的密码。您必须使用 rgw_keystone_admin_password，将外部 RGW 实例配置为使用同一密码与 Identity 服务进行身份验证。

2. 将以下代码添加到 Ceph 配置文件中，将 RGW 配置为使用 Identity 服务。替换变量值以适合您的环境：

       rgw_keystone_api_version = 3
       rgw_keystone_url = http://<public Keystone endpoint>:5000/
       rgw_keystone_accepted_roles = member, Member, admin
       rgw_keystone_accepted_admin_roles = ResellerAdmin, swiftoperator
       rgw_keystone_admin_domain = default
       rgw_keystone_admin_project = service
       rgw_keystone_admin_user = swift
       rgw_keystone_admin_password = <password_as_defined_in_the_environment_parameters>
       rgw_keystone_implicit_tenants = true
       rgw_keystone_revocation_interval = 0
       rgw_s3_auth_use_keystone = true
       rgw_swift_versioning_enabled = true
       rgw_swift_account_in_url = true

   注意

   director 默认在 Identity 服务中创建以下角色和用户：

   • rgw_keystone_accepted_admin_roles: ResellerAdmin, swiftoperator
   • rgw_keystone_admin_domain: default
   • rgw_keystone_admin_project: service
   • rgw_keystone_admin_user: swift

3. 使用与部署相关的任何其他环境文件，使用额外的环境文件部署 overcloud：

   openstack overcloud deploy --templates \
   -e <your_environment_files>
   -e /usr/share/openstack-tripleo-heat-templates/environments/swift-external.yaml
   -e swift-external-params.yaml

验证

1. 以 stack 用户的身份登录 undercloud。

2. 获取 overcloudrc 文件：

   $ source ~/stackrc

3. 验证 Identity 服务(keystone)中是否存在端点：

   $ openstack endpoint list --service object-store
   
   +---------+-----------+-------+-------+---------+-----------+---------------+
   | ID | Region    | Service Name | Service Type | Enabled | Interface | URL |
   +---------+-----------+-------+-------+---------+-----------+---------------+
   | 233b7ea32aaf40c1ad782c696128aa0e | regionOne | swift | object-store | True    | admin     | http://192.168.24.3:8080/v1/AUTH_%(project_id)s |
   | 4ccde35ac76444d7bb82c5816a97abd8 | regionOne | swift | object-store | True    | public    | https://192.168.24.2:13808/v1/AUTH_%(project_id)s |
   | b4ff283f445348639864f560aa2b2b41 | regionOne | swift | object-store | True    | internal  | http://192.168.24.3:8080/v1/AUTH_%(project_id)s |
   +---------+-----------+-------+-------+---------+-----------+---------------+

4. 创建测试容器：

   $ openstack container create <testcontainer>
   +----------------+---------------+------------------------------------+
   | account | container | x-trans-id |
   +----------------+---------------+------------------------------------+
   | AUTH_2852da3cf2fc490081114c434d1fc157 | testcontainer | tx6f5253e710a2449b8ef7e-005f2d29e8 |
   +----------------+---------------+------------------------------------+

5. 创建配置文件以确认您可以上传数据到容器：

   $ openstack object create testcontainer undercloud.conf
   +-----------------+---------------+----------------------------------+
   | object          | container     | etag                             |
   +-----------------+---------------+----------------------------------+
   | undercloud.conf | testcontainer | 09fcffe126cac1dbac7b89b8fd7a3e4b |
   +-----------------+---------------+----------------------------------+

6. 删除测试容器：

   $ openstack container delete -r <testcontainer>

流程

1. 将 POOL 替换为您要配置的池的名称：

   parameter_defaults:
     CephPools:
       - name: POOL

2. 通过执行以下操作之一配置放置组：

   • 要手动覆盖默认设置，将 pg_num 设置为放置组数量：

     parameter_defaults:
       CephPools:
         - name: POOL
           pg_num: 128
           application: rbd

   • 或者，要自动扩展放置组，将 pg_autoscale_mode 设置为 True，并将 target_size_ratio 设置为相对于预期的 Ceph Storage 要求的百分比：

     parameter_defaults:
       CephPools:
         - name: POOL
           pg_autoscale_mode: True
           target_size_ratio: PERCENTAGE
           application: rbd

     用十进制替换 PERCENTAGE。例如，0.5 等于 50%。总计百分比必须等于 1.0 或 100 百分比。

     例如，以下值只包括：

     paramter_defaults:
       CephPools:
         - {"name": backups, "target_size_ratio": 0.1, "pg_autoscale_mode": True, "application": rbd}
         - {"name": volumes, "target_size_ratio": 0.5, "pg_autoscale_mode": True, "application": rbd}
         - {"name": vms,     "target_size_ratio": 0.2, "pg_autoscale_mode": True, "application": rbd}
         - {"name": images,  "target_size_ratio": 0.2, "pg_autoscale_mode": True, "application": rbd}

     有关更多信息，请参阅 Red Hat Ceph Storage 安装指南中的放置组自动缩放器。

3. 指定应用程序类型。

   Compute、Block Storage 和 Image Storage 的应用类型是'rbd'。但是，根据您使用池的内容，您可以指定不同的应用程序类型。

   例如，gnocchi 指标池的应用类型是 openstack_gnocchi。如需更多信息，请参阅存储策略指南中的 启用应用程序。

   注意

   如果不使用 CephPools 参数，则 director 会自动设置适当的应用类型，但仅适用于默认的池列表。

4. 可选：添加名为 custompool 的池来创建一个自定义池，并设置特定于您的环境需求的参数：

   parameter_defaults:
     CephPools:
       - name: custompool
         pg_num: 128
         application: rbd

流程

1. 更新 CephAnsibleExtraConfig 参数，以更改默认延迟和重试值：

   parameter_defaults:
     CephAnsibleExtraConfig:
       health_osd_check_delay: 40
       health_osd_check_retries: 30
       health_mon_check_delay: 20
       health_mon_check_retries: 10

   本例使集群检查 30 次，在每次检查 Ceph OSD 的每个检查之间等待 40 秒，再检查 Ceph MON 的每个检查之间等待 10 秒。

2. 要纳入这些更改，请使用 -e 使用 openstack overcloud deploy 传递更新的 yaml 文件。

流程

1. 以 stack 用户身份登录 undercloud 节点。
2. 创建一个环境文件，如 /home/stack/templates/ceph-config.yaml，使其包含 Ceph 配置参数和设备类变量。或者，您还可以将以下配置添加到现有环境文件中。

3. 在环境文件中，使用 CephAnsibleDisksConfig 参数列出您要用作 Ceph OSD 的块设备：

   CephAnsibleDisksConfig:
       devices:
         - /dev/sdb
         - /dev/sdc
         - /dev/sdd
       osd_scenario: lvm
       osd_objectstore: bluestore

4. 可选：Ceph 会自动检测磁盘类型，并将其分配给对应的设备类。但是，您还可以使用 crush_device_class 属性来强制特定设备属于特定的类或创建自己的自定义类。以下示例包含具有指定类的相同 OSD 列表：

   CephAnsibleDisksConfig:
       lvm_volumes:
         - data: '/dev/sdb'
           crush_device_class: 'hdd'
         - data: '/dev/sdc'
           crush_device_class: 'hdd'
         - data: '/dev/sdd'
           crush_device_class: 'ssd'
       osd_scenario: lvm
       osd_objectstore: bluestore

5. 添加 CephAnsibleExtraVars 参数。crush_rules 参数必须包含您定义或 Ceph 检测到的每个类的规则。在创建新池时，如果没有指定规则，则会选择 Ceph 用作默认值的规则。

   CephAnsibleExtraConfig:
       crush_rule_config: true
       create_crush_tree: true
       crush_rules:
         - name: HDD
           root: default
           type: host
           class: hdd
           default: true
         - name: SSD
           root: default
           type: host
           class: ssd
           default: false

6. 添加 CephPools 参数：

   • 使用 rule_name 参数指定不使用默认规则的每个池的层。在以下示例中，fastpool 池使用配置为快速层的 SSD 设备类来管理块存储卷。

   • 将 <appropriate_PG_num > 替换为适当的放置组数量(PG)。或者，使用放置组 auto-scaler 计算 Ceph 池的 PG 数量。

     有关更多信息，请参阅将自定义属性分配到不同的 Ceph 池。

   • 使用 CinderRbdExtraPools 参数将 fastpool 配置为块存储后端。

     CephPools:
       - name: fastpool
         pg_num: <appropraiate_PG_num>
         rule_name: SSD
         application: rbd
     CinderRbdExtraPools: fastpool

7. 使用以下示例来确保环境文件包含正确的值：

   parameter_defaults:
       CephAnsibleDisksConfig:
           devices:
               - '/dev/sdb'
               - '/dev/sdc'
               - '/dev/sdd'
           osd_scenario: lvm
           osd_objectstore: bluestore
       CephAnsibleExtraConfig:
           crush_rule_config: true
           create_crush_tree: true
           crush_rules:
               - name: HDD
                 root: default
                 type: host
                 class: hdd
                 default: true
               - name: SSD
                 root: default
                 type: host
                 class: ssd
                 default: false
       CinderRbdExtraPools: fastpool
       CephPools:
           - name: fastpool
             pg_num: <appropriate_PG_num>
             rule_name: SSD
             application: rbd

8. 在 openstack overcloud deploy 命令中包含新的环境文件。

   $ openstack overcloud deploy \
   --templates \
   …
   -e <other_overcloud_environment_files> \
   -e /home/stack/templates/ceph-config.yaml  \
   …

   将 <other_overcloud_environment_files > 替换为属于该部署的环境文件列表。

流程

1. 以 stack 用户身份登录 undercloud 节点。

2. 获取 overcloudrc 文件：

   $ source overcloudrc

3. 检查 Block Storage 卷现有的类型：

   $ cinder type-list

4. 创建新的块存储卷 fast_tier：

   $ cinder type-create fast_tier

5. 检查是否创建了 Block Storage 类型：

   $ cinder type-list

6. 当 fast_tier Block Storage 类型可用时，将您创建的新层的 fastpool 设置为块存储卷后端：

   $ cinder type-key fast_tier set volume_backend_name=tripleo_ceph_fastpool

7. 使用新层来创建新卷：

   $ cinder create 1 --volume-type fast_tier --name fastdisk

流程

1. 以 heat-admin 用户身份登录 overcloud Controller 节点。

2. 要验证您的 OSD 层是否已成功设置，请输入以下命令。将 <controller_hostname > 替换为主机控制器节点的名称。

   $ sudo podman exec -it ceph-mon-<controller_hostname> ceph osd tree

3. 在生成的树视图中，验证 CLASS 列是否显示您设置的每个 OSD 的正确设备类。

4. 另外，使用以下命令验证 OSD 是否已正确分配给设备类。将 <controller_hostname > 替换为主机控制器节点的名称。

   $ sudo podman exec -it ceph-mon-<controller_hostname> ceph osd crush tree --show-shadow

5. 将生成的层次结构与以下命令的结果进行比较，以确保每个规则都应用相同的值。

   • 将 <controller_hostname > 替换为主机控制器节点的名称。

   • 将 <rule_name > 替换为您要检查的规则的名称。

     $ sudo podman exec <controller_hostname> ceph osd crush rule dump <rule_name>

6. 根据部署期间使用的 crush_rules 参数，验证您创建的规则名称和 ID 是否正确。将 <controller_hostname > 替换为主机控制器节点的名称。

   $ sudo podman exec -it ceph-mon-<controller_hostname>  ceph osd crush rule dump | grep -E "rule_(id|name)"

7. 验证 Ceph 池已绑定到在第 3 步中获得的正确 CRUSH 规则 ID。将 <controller_hostname > 替换为主机控制器节点的名称。

   $ sudo podman exec -it ceph-mon-<controller_hostname> ceph osd dump | grep pool

8. 对于每个池，确保规则 ID 与您所期望的规则名称匹配。

流程

1. 以 stack 用户身份登录 undercloud 主机。

2. 生成默认的容器镜像准备文件：

   $ sudo openstack tripleo container image prepare default \
     --local-push-destination \
     --output-env-file containers-prepare-parameter.yaml

3. 编辑 containers-prepare-parameter.yaml 文件并进行修改以符合您的要求。以下 containers-prepare-parameter.yaml 文件示例包含与 Dashboard 服务相关的镜像位置和标签，如 Grafana、Prometheus、Alertmanager 和 Node Exporter。根据您的具体情况编辑值：

   parameter_defaults:
       ContainerImagePrepare:
       - push_destination: true
           set:
               ceph_alertmanager_image: ose-prometheus-alertmanager
               ceph_alertmanager_namespace: registry.redhat.io/openshift4
               ceph_alertmanager_tag: v4.1
               ceph_grafana_image: rhceph-4-dashboard-rhel8
               ceph_grafana_namespace: registry.redhat.io/rhceph
               ceph_grafana_tag: 4
               ceph_image: rhceph-4-rhel8
               ceph_namespace: registry.redhat.io/rhceph
               ceph_node_exporter_image: ose-prometheus-node-exporter
               ceph_node_exporter_namespace: registry.redhat.io/openshift4
               ceph_node_exporter_tag: v4.1
               ceph_prometheus_image: ose-prometheus
               ceph_prometheus_namespace: registry.redhat.io/openshift4
               ceph_prometheus_tag: v4.1
               ceph_tag: latest

流程

1. 以 stack 用户身份登录 undercloud 节点。

2. 在 openstack overcloud deploy 命令中包含以下环境文件，以及属于部署的所有环境文件：

   $ openstack overcloud deploy \
    --templates \
    -e <overcloud_environment_files> \
    -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-dashboard.yaml

   将 <overcloud_environment_files > 替换为属于该部署的环境文件列表。

   结果

   生成的部署包含 grafana、prometheus、alertmanager 和 node-exporter 容器的外部堆栈。Ceph Dashboard manager 模块是此堆栈的后端，它会嵌入 grafana 布局，以便为最终用户提供 ceph 集群特定的指标。

流程

1. 以 stack 用户身份登录 undercloud。

2. 生成特定于 Controller 的角色，使其包含 Dashboard 可组合网络：

   $ openstack overcloud roles generate -o /home/stack/roles_data_dashboard.yaml ControllerStorageDashboard Compute BlockStorage ObjectStorage CephStorage

   结果

   • 在定义为命令输出的 roles_data.yaml 中生成新的 ControllerStorageDashboard 角色。在使用 overcloud deploy 命令时，您必须将此文件包含在模板列表中。

     注： ControllerStorageDashboard 角色不包含 CephNFS 或 network_data_dashboard.yaml。

   • director 提供了一个网络环境文件，它定义了可组合网络。此文件的默认位置为 /usr/share/openstack-tripleo-heat-templates/network_data_dashboard.yaml。在使用 overcloud deploy 命令时，您必须将此文件包含在 overcloud 模板列表中。

3. 在 openstack overcloud deploy 命令中包含以下环境文件，以及属于部署的所有环境文件：

   $ openstack overcloud deploy \
     --templates \
     -r /home/stack/roles_data.yaml \
     -n /usr/share/openstack-tripleo-heat-templates/network_data_dashboard.yaml \
     -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
     -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
     -e <overcloud_environment_files> \
     -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
     -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-dashboard.yaml

   将 <overcloud_environment_files > 替换为属于该部署的环境文件列表。

   结果

   生成的部署包含 grafana、prometheus、alertmanager 和 node-exporter 容器的外部堆栈。Ceph 控制面板管理器模块是此堆栈的后端，它嵌入了 grafana 布局，以便为最终用户提供 Ceph 集群特定的指标。

流程

1. 以 stack 用户的身份登录 undercloud。

2. 创建以下 ceph_dashboard_admin.yaml 环境文件：

     parameter_defaults:
        CephDashboardAdminRO: false

3. 运行 overcloud deploy 命令以更新现有堆栈，并包括您使用现有部署一部分的所有其他环境文件创建的环境文件：

   $ openstack overcloud deploy \
   --templates \
   -e <existing_overcloud_environment_files> \
   -e ceph_dashboard_admin.yml

   使用 <existing_overcloud_environment_files> 属于您现有部署的环境文件列表替换。

流程

1. 以 stack 用户身份登录 undercloud 节点。

2. 检索仪表板 admin 登录凭证：

   [stack@undercloud ~]$ grep dashboard_admin_password /var/lib/mistral/overcloud/ceph-ansible/group_vars/all.yml

3. 检索 VIP 地址以访问 Ceph 仪表板：

   [stack@undercloud-0 ~]$ grep dashboard_frontend_vip /var/lib/mistral/overcloud/ceph-ansible/group_vars/all.yml

4. 使用 Web 浏览器指向前端 VIP 并访问控制面板。director 在 provisioning 网络上配置并公开控制面板，因此您可以使用您检索到的 VIP 在 TCP 端口 8444 上直接访问仪表板。确保满足以下条件：

   • Web 客户端主机连接到 provisioning 网络的第 2 层。

   • 调配网络已正确路由或代理，可以从 Web 客户端主机访问。如果没有满足这些条件，您仍然可以打开 SSH 隧道来访问 overcloud 上的 Dashboard VIP：

     client_host$ ssh -L 8444:<dashboard_vip>:8444 stack@<your undercloud>

     将 <dashboard_vip> 替换为您检索到的 control plane VIP 的 IP 地址。

5. 要访问仪表板，使用浏览器访问 http://localhost:8444，并使用以下详情进行登录：

   • ceph-ansible 创建的默认用户： admin。

   • /var/lib/mistral/overcloud/ceph-ansible/group_vars/all.yml 中的密码。

     结果

   • 您可以访问 Ceph 控制面板。
   • 控制面板显示的数字和图形反映了 CLI 命令 ceph -s 返回的同一集群状态。

流程

1. 以 heat-admin 用户身份登录 Controller 节点：

   $ nova list
   $ ssh heat-admin@192.168.0.25

2. 检查集群的健康状况：

   $ sudo podman exec ceph-mon-<HOSTNAME> ceph health

   如果集群没有问题，该命令将报告回 HEALTH_OK。这意味着集群可以安全地使用。

3. 登录运行 Ceph 监控服务的 overcloud 节点，并检查集群中的所有 OSD 的状态：

   $ sudo podman exec ceph-mon-<HOSTNAME> ceph osd tree

4. 检查 Ceph Monitor 仲裁的状态：

   $ sudo podman exec ceph-mon-<HOSTNAME> ceph quorum_status

   这显示了参与仲裁的监控器，以及哪个是领导的。

5. 验证所有 Ceph OSD 都在运行：

   $ sudo podman exec ceph-mon-<HOSTNAME> ceph osd stat

步骤

1. 登录到运行 ceph-mon 服务的 Ceph Monitor 或 Controller 节点，并临时禁用 Ceph Storage 集群重新平衡：

   $ sudo podman exec -it ceph-mon-controller-0 ceph osd set noout
   $ sudo podman exec -it ceph-mon-controller-0 ceph osd set norebalance

   注意

   如果您有多堆栈或分布式计算节点(DCN)架构，则必须在设置 noout 和 norebalance 标志时指定集群名称。例如： sudo podman exec -it ceph-mon-controller-0 ceph osd set noout --cluster <cluster_name>

2. 选择第一个要重新引导的 Ceph Storage 节点并登录到该节点。

3. 重新引导节点：

   $ sudo reboot

4. 稍等片刻，直到节点启动。

5. 登录到节点，并检查集群的状态：

   $ sudo podman exec -it ceph-mon-controller-0 ceph status

   确认 pgmap 报告的所有 pgs 的状态是否都正常 (active+clean)。

6. 注销节点，重新引导下一个节点，并检查其状态。重复此流程，直到您已重新引导所有 Ceph 存储节点。

7. 完成后，登录到运行 ceph-mon 服务的 Ceph Monitor 或 Controller 节点，并重新启用集群重新平衡：

   $ sudo podman exec -it ceph-mon-controller-0 ceph osd unset noout
   $ sudo podman exec -it ceph-mon-controller-0 ceph osd unset norebalance

   注意

   如果您有多堆栈或分布式计算节点(DCN)架构，您必须在取消设置 noout 和 norebalance 标志时指定集群名称。例如： sudo podman exec -it ceph-mon-controller-0 ceph osd set noout --cluster <cluster_name>

8. 执行最后的状态检查，确认集群报告 HEALTH_OK：

   $ sudo podman exec -it ceph-mon-controller-0 ceph status

流程

1. 以 stack 用户身份登录 undercloud，并初始化 director 配置：

   $ source ~/stackrc

2. 在新节点定义模板中定义新节点的硬件和电源管理详情，例如 instackenv-scale.json。

3. 将此文件导入到 director：

   $ openstack overcloud node import ~/instackenv-scale.json

   导入节点定义模板会将此处定义的每个节点注册到 director。

4. 将内核和 ramdisk 镜像分配给所有节点：

   $ openstack overcloud node configure

流程

1. 触发硬件内省以检索每个节点的硬件属性：

   $ openstack overcloud node introspect --all-manageable --provide

   • --all-manageable 选项仅内省处于受管状态的节点。在此示例中，所有节点都处于受管理状态。

   • --provide 选项会在内省后将所有节点重置 为活动状态。

     重要

     确保此过程成功完成。它可能需要 15 分钟来检查这些裸机节点。

2. 检索节点列表来识别它们的 UUID：

   $ openstack baremetal node list

3. 在每个节点的 properties/capabilities 参数中添加 profile 选项，来手动将节点标记到特定的配置集。添加 profile 选项会将节点标记为相关的配置集。

   注意

   作为手动标记的替代选择，请使用 Automated Health Check (AHC)工具根据基准测试数据自动标记更多节点。例如，以下命令使用 ceph-storage 配置集标记三个额外的节点：

   $ openstack baremetal node set --property capabilities='profile:baremetal,boot_option:local' 551d81f5-4df2-4e0f-93da-6c5de0b868f7
   $ openstack baremetal node set --property capabilities='profile:baremetal,boot_option:local' 5e735154-bd6b-42dd-9cc2-b6195c4196d7
   $ openstack baremetal node set --property capabilities='profile:baremetal,boot_option:local' 1a2b090c-299d-4c20-a25d-57dd21a7085b

流程

1. 在重新部署 overcloud 之前，在环境文件的 parameter_defaults 中设置 CephStorageCount 参数，本例中为 ~/templates/storage-config.yaml。在 第 7.1 节 “为角色分配节点和类别” 中，overcloud 配置为部署具有三个 Ceph Storage 节点。以下示例将 overcloud 扩展到 6 个节点：

   parameter_defaults:
     ControllerCount: 3
     OvercloudControlFlavor: control
     ComputeCount: 3
     OvercloudComputeFlavor: compute
     CephStorageCount: 6
     OvercloudCephStorageFlavor: ceph-storage
     CephMonCount: 3
     OvercloudCephMonFlavor: ceph-mon

2. 重新部署 overcloud。overcloud 现在有六个 Ceph Storage 节点，而不是三个。

流程

1. 以 heat-admin 用户身份登录 Controller 节点。director stack 用户具有访问 heat-admin 用户的 SSH 密钥。

2. 列出 OSD 树，并查找节点的 OSD。例如，您要删除的节点可能包含以下 OSD：

   -2 0.09998     host overcloud-cephstorage-0
   0 0.04999         osd.0                         up  1.00000          1.00000
   1 0.04999         osd.1                         up  1.00000          1.00000

3. 禁用 Ceph Storage 节点上的 OSD。在本例中，OSD ID 为 0 和 1。

   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd out 0
   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd out 1

4. Ceph Storage 集群开始重新平衡。等待此过程完成。使用以下命令跟踪状态：

   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph -w

5. 在 Ceph 集群完成重新平衡后，以 heat-admin 用户身份登录到您要删除的 Ceph Storage 节点，本例中为 overcloud-cephstorage-0，并停止并禁用该节点。

   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl stop ceph-osd@0
   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl stop ceph-osd@1
   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl disable ceph-osd@0
   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl disable ceph-osd@1

6. 停止 OSD。

   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl stop ceph-osd@0
   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl stop ceph-osd@1

7. 在登录到 Controller 节点时，从 CRUSH map 中删除 OSD，以便它们不再接收数据。

   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd crush remove osd.0
   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd crush remove osd.1

8. 移除 OSD 身份验证密钥。

   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph auth del osd.0
   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph auth del osd.1

9. 从集群中移除该 OSD。

   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd rm 0
   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd rm 1

10. 从 CRUSH 映射中删除存储节点：

    [heat-admin@overcloud-controller-0 ~]$ sudo docker exec ceph-mon-<HOSTNAME> ceph osd crush rm <NODE>
    [heat-admin@overcloud-controller-0 ~]$ sudo ceph osd crush remove <NODE>

    您可以通过搜索 CRUSH 树，确认 CRUSH map 中定义的 <NODE> 名称：

    [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd crush tree | grep overcloud-osd-compute-3 -A 4
                    "name": "overcloud-osd-compute-3",
                    "type": "host",
                    "type_id": 1,
                    "items": []
                },
    [heat-admin@overcloud-controller-0 ~]$

    在 CRUSH 树中，确保 items 列表为空。如果列表不为空，请重新访问第 7 步。

11. 保留节点，并以 stack 用户身份返回到 undercloud。

    [heat-admin@overcloud-controller-0 ~]$ exit
    [stack@director ~]$

12. 禁用 Ceph Storage 节点，以便 director 不会重新置备它。

    [stack@director ~]$ openstack baremetal node list
    [stack@director ~]$ openstack baremetal node maintenance set UUID

13. 移除 Ceph Storage 节点需要使用本地模板文件更新 director 中的 overcloud 堆栈。首先识别 overcloud 堆栈的 UUID：

    $ openstack stack list

14. 识别您要删除的 Ceph Storage 节点的 UUID：

    $ openstack server list

15. 从堆栈中删除节点并相应地更新计划：

    重要

    如果您在创建 overcloud 时传递任何额外的环境文件，请使用 -e 选项再次传递它们，以避免对 overcloud 进行不必要的更改。有关更多信息，请参阅 Director 安装和使用指南中的修改 overcloud 环境。

    $ openstack overcloud node delete /
    --stack <stack-name> /
    --templates /
    -e <other-environment-files> /
    <node_UUID>

16. 等待堆栈完成更新。使用 heat stack-list --show-nested 命令来监控堆栈更新。

17. 将新节点添加到 director 节点池中，并将它们部署为 Ceph Storage 节点。使用环境文件的 parameter_defaults 中的 CephStorageCount 参数，在本例中为 ~/templates/storage-config.yaml 来定义 overcloud 中 Ceph Storage 节点的总数量。

    parameter_defaults:
      ControllerCount: 3
      OvercloudControlFlavor: control
      ComputeCount: 3
      OvercloudComputeFlavor: compute
      CephStorageCount: 3
      OvercloudCephStorageFlavor: ceph-storage
      CephMonCount: 3
      OvercloudCephMonFlavor: ceph-mon

    注意

    有关如何为每个角色定义节点数量的更多信息，请参阅 第 7.1 节 “为角色分配节点和类别”。

18. 更新环境文件后，重新部署 overcloud：

    $ openstack overcloud deploy --templates -e <ENVIRONMENT_FILE>

    director 置备新节点，并使用新节点的详细信息更新整个堆栈。

19. 以 heat-admin 用户身份登录 Controller 节点，并检查 Ceph Storage 节点的状态：

    [heat-admin@overcloud-controller-0 ~]$ sudo ceph status

20. 确认 osdmap 部分中的值与您想要的集群中的节点数量匹配。您移除的 Ceph Storage 节点会替换为新节点。

1. 请注意，以下 heat 模板将使用三个 OSD 设备部署 Ceph Storage：

   parameter_defaults:
     CephAnsibleDisksConfig:
       devices:
         - /dev/sdb
         - /dev/sdc
         - /dev/sdd
       osd_scenario: lvm
       osd_objectstore: bluestore

2. 要添加 OSD，请更新节点磁盘布局，如 第 5.3 节 “映射 Ceph Storage 节点磁盘布局” 所述。在本例中，将 /dev/sde 添加到模板中：

   parameter_defaults:
     CephAnsibleDisksConfig:
       devices:
         - /dev/sdb
         - /dev/sdc
         - /dev/sdd
         - /dev/sde
       osd_scenario: lvm
       osd_objectstore: bluestore

3. 运行 openstack overcloud deploy 以更新 overcloud。

1. SSH 连接到 ceph-storage0，并以 root 身份登录。

2. 禁用和停止 OSD 服务：

   [root@ceph-storage0 ~]# systemctl disable ceph-osd@4
   [root@ceph-stoarge0 ~]# systemctl stop ceph-osd@4

3. 从 ceph-storage0 断开连接。
4. SSH 连接到 controller0，然后以 root 身份登录。

5. 识别 Ceph 监控容器的名称：

   [root@controller0 ~]# podman ps | grep ceph-mon
   ceph-mon-controller0
   [root@controller0 ~]#

6. 启用 Ceph 监控容器，将不需要的 OSD 标记为 out ：

   [root@controller0 ~]# podman exec ceph-mon-controller0 ceph osd out 4

   注意

   此命令会导致 Ceph 重新平衡存储集群，并将数据复制到集群中的其他 OSD。在重新平衡完成前，集群会临时保留 active+clean 状态。

7. 运行以下命令并等待存储集群状态变为 active+clean ：

   [root@controller0 ~]# podman exec ceph-mon-controller0 ceph -w

8. 从 CRUSH map 中删除 OSD，使其不再接收数据：

   [root@controller0 ~]# podman exec ceph-mon-controller0 ceph osd crush remove osd.4

9. 删除 OSD 身份验证密钥：

   [root@controller0 ~]# podman exec ceph-mon-controller0 ceph auth del osd.4

10. 删除 OSD：

    [root@controller0 ~]# podman exec ceph-mon-controller0 ceph osd rm 4

11. 从 controller0 断开连接。
12. 以 stack 用户身份通过 SSH 连接到 undercloud，再找到您定义 CephAnsibleDisksConfig 参数的 heat 环境文件。

13. 注意 heat 模板包含四个 OSD：

    parameter_defaults:
      CephAnsibleDisksConfig:
        devices:
          - /dev/sdb
          - /dev/sdc
          - /dev/sdd
          - /dev/sde
        osd_scenario: lvm
        osd_objectstore: bluestore

14. 修改模板以删除 /dev/sde。

    parameter_defaults:
      CephAnsibleDisksConfig:
        devices:
          - /dev/sdb
          - /dev/sdc
          - /dev/sdd
        osd_scenario: lvm
        osd_objectstore: bluestore

15. 运行 openstack overcloud deploy 以更新 overcloud。

    注意

    在本例中，您将从具有 OSD 的所有主机中删除 /dev/sde 设备。如果您没有从所有节点中删除同一设备，请更新 heat 模板。有关如何使用不同 devices 列表定义主机的详情，请参考 第 5.5 节 “覆盖用于忽略 Ceph Storage 节点的参数”。

流程

1. 识别正在运行的 Ceph 监控容器的名称，并将其存储在名为 MON 的环境变量中：

   MON=$(podman ps | grep ceph-mon | awk {'print $1'})

2. 对 ceph 命令的别名，使其在运行的 Ceph 监控容器内执行：

   alias ceph="podman exec $MON ceph"

3. 使用新别名验证您要替换的 OSD 的状态是否为 down ：

   [root@overcloud-controller-0 ~]# ceph osd tree | grep 27
   27   hdd 0.04790         osd.27                    down  1.00000 1.00000

4. 销毁 OSD。以下示例命令销毁 OSD 27 ：

   [root@overcloud-controller-0 ~]# ceph osd destroy 27 --yes-i-really-mean-it
   destroyed osd.27

流程

1. 确保失败的 OSD 没有运行：

   systemctl stop ceph-osd@27

2. 识别 ceph 容器镜像的镜像 ID，并将其存储在名为 IMG 的环境变量中：

   IMG=$(podman images | grep ceph | awk {'print $3'})

3. 为 ceph-volume 命令别名，使其在 $IMG Ceph 容器内运行，使用 ceph-volume 入口点和相关目录：

   alias ceph-volume="podman run --rm --privileged --net=host --ipc=host -v /run/lock/lvm:/run/lock/lvm:z -v /var/run/udev/:/var/run/udev/:z -v /dev:/dev -v /etc/ceph:/etc/ceph:z -v /var/lib/ceph/:/var/lib/ceph/:z -v /var/log/ceph/:/var/log/ceph/:z --entrypoint=ceph-volume $IMG --cluster ceph"

4. 验证 aliased 命令是否已成功运行：

   ceph-volume lvm list

5. 检查您的新 OSD 设备是否还没有作为 LVM 的一部分。使用 pvdisplay 命令检查设备，并确保 VG Name 字段为空。将 <NEW_DEVICE > 替换为新 OSD 设备的 /dev sections 路径：

   [root@overcloud-computehci-2 ~]# pvdisplay <NEW_DEVICE>
     --- Physical volume ---
     PV Name               /dev/sdj
     VG Name               ceph-0fb0de13-fc8e-44c8-99ea-911e343191d2
     PV Size               50.00 GiB / not usable 1.00 GiB
     Allocatable           yes (but full)
     PE Size               1.00 GiB
     Total PE              49
     Free PE               0
     Allocated PE          49
     PV UUID               kOO0If-ge2F-UH44-6S1z-9tAv-7ypT-7by4cp
   [root@overcloud-computehci-2 ~]#

   如果 VG Name 字段不为空，则设备将属于您必须删除的卷组。

6. 如果设备属于卷组，请使用 lvdisplay 命令检查卷组中是否存在逻辑卷。将 <VOLUME_GROUP > 替换为您从 pvdisplay 命令检索到的 VG Name 字段的值：

   [root@overcloud-computehci-2 ~]# lvdisplay | grep <VOLUME_GROUP>
     LV Path                /dev/ceph-0fb0de13-fc8e-44c8-99ea-911e343191d2/osd-data-a0810722-7673-43c7-8511-2fd9db1dbbc6
     VG Name                ceph-0fb0de13-fc8e-44c8-99ea-911e343191d2
   [root@overcloud-computehci-2 ~]#

   如果 LV Path 字段不为空，则该设备会包含您必须删除的逻辑卷。

7. 如果新设备是逻辑卷或卷组的一部分，请删除逻辑卷、卷组和逻辑卷以及设备关联作为 LVM 系统中的物理卷。

   • 将 <LV_PATH > 替换为 LV Path 字段的值。
   • 将 <VOLUME_GROUP > 替换为 VG Name 字段的值。

   • 将 <NEW_DEVICE > 替换为新 OSD 设备的 /dev sections 路径。

     [root@overcloud-computehci-2 ~]# lvremove --force <LV_PATH>
       Logical volume "osd-data-a0810722-7673-43c7-8511-2fd9db1dbbc6" successfully removed

     [root@overcloud-computehci-2 ~]# vgremove --force <VOLUME_GROUP>
       Volume group "ceph-0fb0de13-fc8e-44c8-99ea-911e343191d2" successfully removed

     [root@overcloud-computehci-2 ~]# pvremove <NEW_DEVICE>
       Labels on physical volume "/dev/sdj" successfully wiped.

8. 确保新 OSD 设备清理干净。在以下示例中，该设备为 /dev/sdj ：

   [root@overcloud-computehci-2 ~]# ceph-volume lvm zap /dev/sdj
   --> Zapping: /dev/sdj
   --> --destroy was not specified, but zapping a whole device will remove the partition table
   Running command: /usr/sbin/wipefs --all /dev/sdj
   Running command: /bin/dd if=/dev/zero of=/dev/sdj bs=1M count=10
    stderr: 10+0 records in
   10+0 records out
   10485760 bytes (10 MB, 10 MiB) copied, 0.010618 s, 988 MB/s
   --> Zapping successful for: <Raw Device: /dev/sdj>
   [root@overcloud-computehci-2 ~]#

9. 使用新设备创建具有现有 OSD ID 的新 OSD，但传递 --no-systemd，以便 ceph-volume 不会尝试启动 OSD。这无法从容器中实现：

   ceph-volume lvm create --osd-id 27 --data /dev/sdj --no-systemd

10. 启动容器外的 OSD：

    systemctl start ceph-osd@27

流程

1. 检查设备名称是否已改变，根据您用于部署 Ceph 的命名方法更新 devices 列表。更多信息请参阅 第 12.1 节 “确定是否存在设备名称更改”。
2. 为确保更改没有引入任何不一致的情况，请重新运行 overcloud deploy 命令来执行堆栈更新。

3. 如果您有具有不同设备列表的主机，您可能需要定义例外。例如，您可以使用以下示例 heat 环境文件来部署具有三个 OSD 设备的节点。

   parameter_defaults:
     CephAnsibleDisksConfig:
       devices:
         - /dev/sdb
         - /dev/sdc
         - /dev/sdd
       osd_scenario: lvm
       osd_objectstore: bluestore

   CephAnsibleDisksConfig 参数应用到托管 OSD 的所有节点，因此您无法使用新设备列表更新 devices 参数。反之，您必须为具有不同设备列表的新主机定义例外。有关定义例外的更多信息，请参阅 第 5.5 节 “覆盖用于忽略 Ceph Storage 节点的参数” 和 第 5.5.1.2 节 “更改 Ceph Storage 节点中的磁盘布局”。