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

1.13. 使用块存储服务

将 Cinder 服务部署到 OpenStack 中的 director 可能需要一些考虑，因为它并不始终是一种简单的流程。

通常，采用过程如下：

  • 检查现有的限制。
  • 考虑 Cinder 服务的放置。
  • 准备将运行卷和备份服务的 OpenShift 节点。
  • 根据现有的 cinder.conf 文件制作清单。
  • 部署 Cinder.
  • 验证新部署。

本指南提供在大多数情况下完成这些步骤的必要知识，但它仍需要了解 OpenStack 服务的工作原理和 Cinder 配置文件的结构。

1.13.1. 限制
复制链接

当前有一些限制值得突出显示；有些限制与本指南有关，而一些与 Operator 相关的：

  • 所有 cinder 卷都没有全局 nodeSelector，因此需要为每个后端指定它。这可能会在以后改变。
  • 所有 cinder 卷都没有全局 customServiceConfig 或 customServiceConfigSecrets，因此需要为每个后端指定它。这可能会在以后改变。
  • LVM 后端的使用（其中卷数据存储在计算节点上）目前没有在此过程中记录。以后可能会记录它。
  • 对需要 RHEL 中没有在部署 OpenStack 的 Operator 中测试的内核模块的 Cinder 后端的支持，因此本指南中未记录它。
  • 本指南目前没有描述 DCN/Edge 部署的使用。

1.13.2. 先决条件
复制链接

  • 以前的 Adoption 步骤已完成。值得注意的是，cinder 服务必须已经停止，服务数据库必须已导入到 pod 指定的 MariaDB 中。
  • 在 OpenShift 集群中正确配置了存储网络。

1.13.3. 变量
复制链接

不需要定义新的环境变量，但您使用上一步中定义的 CONTROLLER1_SSH 进行预检查。

1.13.4. pre-checks
复制链接

您需要 cinder.conf 文件的内容。下载该文件以便在本地访问该文件： 

$CONTROLLER1_SSH cat /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf > cinder.conf

1.13.5. 准备 OpenShift
复制链接

如 规划新部署 中所述，在 OpenShift 中部署 OpenStack 之前，您必须确保网络就绪，您决定节点选择，并确保已对 OpenShift 节点进行必要的更改。对于 Cinder 卷和备份服务，必须仔细考虑所有这些 3。

1.13.5.1. 节点选择
复制链接

您可能需要或希望限制运行 cinder 卷和备份服务的 OpenShift 节点。

当您需要为特定 Cinder 服务执行节点选择时，最好使用 LVM 驱动程序部署 Cinder。在这种情况下，卷存储的 LVM 数据仅存在于特定主机中，因此您需要将 cinder-volume 服务固定到该特定的 OpenShift 节点。在任何其他 OpenShift 节点上运行该服务不起作用。因为 nodeSelector 仅适用于标签，所以您无法使用 OpenShift 主机名来限制 LVM 后端，您需要使用唯一标签、现有标签或新标签来识别它： 

$ oc label nodes worker0 lvm=cinder-volumes
 
apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  secret: osp-secret
  storageClass: local-storage
  cinder:
    enabled: true
    template:
      cinderVolumes:
        lvm-iscsi:
          nodeSelector:
            lvm: cinder-volumes
< . . . >

如 About 节点选择器 中所述，您需要使用标签的示例是在使用 FC 存储时，所有 OpenShift 节点上没有 HBA 卡。在这种情况下，您需要限制所有 cinder 卷后端（不仅仅是 FC ），以及备份服务。

根据 cinder 后端、它们的配置和 Cinder 的使用，您可以拥有网络密集型 Cinder 卷服务，同时包含大量 I/O 以及 cinder 备份服务，不仅是网络密集型，而且也消耗了内存和 CPU 密集型的 cinder 备份服务。这可能是 OpenShift 人员 Operator 的问题，它们可能希望使用 nodeSelector 来防止这些服务干扰其他 OpenShift 工作负载。有关节点选择的更多信息，请参阅关于节点选择器。

当选择运行 cinder 卷的节点时，请记住，在从镜像操作下载 glance 镜像时，cinder-volume 也可能会使用本地存储，且在具有并发操作而不是使用 cinder 卷缓存时，可能需要大量空间。

如果您没有足够本地磁盘空间的节点用于临时镜像，您可以将远程 NFS 位置用于镜像。您必须在 Director 部署中手动设置此设置，但通过 operator，您可以使用额外的卷功能（）extraMount 自动执行。

1.13.5.2. 传输协议
复制链接

由于存储传输协议的具体内容需要在 OpenShift 端进行一些更改，虽然这是供应商必须被供应商记录的内容，但我们将提供一些通用说明，这些指令可作为不同传输协议的指南提供指导。

检查 cinder.conf 文件中的 backend 部分，该文件列在 enabled_backends 配置选项中，以找出后端使用的传输存储协议。

根据后端，您可以找到传输协议：

  • 查看 volume_driver 配置选项，因为它可能包含协议本身：RBD、iSCSI、FC…​
  • 查看 target_protocol 配置选项
警告

每当 MachineConfig 用于更改 OpenShift 节点时，节点将重新引导！！相应地操作。

1.13.5.2.1. NFS
复制链接

NFS 没有什么操作。OpenShift 可以在没有任何额外的更改的情况下连接到 NFS 后端。

1.13.5.2.2. RBD/Ceph
复制链接

在准备节点时，对 RBD/Ceph 没有什么操作，OpenShift 可以连接到 Ceph 后端，而无需额外的更改。需要向服务提供凭据和配置文件。

1.13.5.2.3. iSCSI
复制链接

连接到 iSCSI 卷要求 iSCSI 启动器在运行卷和备份服务的 OpenShift 主机上运行，因为 Linux Open iSCSI 启动器目前不支持网络命名空间，因此您必须仅运行 1 个服务实例用于普通 OpenShift 使用，以及 OpenShift CSI 插件以及 OpenStack 服务。

如果您还没有在 OpenShift 节点上运行 iscsid，则需要应用类似如下的 MachineConfig ： 

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
    service: cinder
  name: 99-master-cinder-enable-iscsid
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
      - enabled: true
        name: iscsid.service

如果您使用标签来限制运行 cinder 服务的节点，如 About 节点选择器 所述，将 MachineConfig 的影响限制为您的服务可能运行的节点。

如果您使用一个并行单一节点部署来测试进程，您可能需要在 MachineConfig 中将 worker 替换为 master。

1.13.5.2.4. FC
复制链接

FC 卷无法工作，但 cinder 卷和 cinder 备份服务需要在具有 HBA 的 OpenShift 主机中运行。因此，如果存在没有 HBA 的节点，您需要使用标签来限制这些服务可以运行的位置，如 [node 选择部分](#node-selection)中所述。

这也意味着，对于使用 FC 的虚拟化 OpenShift 集群，您需要在虚拟机内公开主机的 HBA。

1.13.5.2.5. NVMe-oF
复制链接

连接到 NVMe-oF 卷需要 nvme 内核模块加载到 OpenShift 主机上。

如果您还没有在运行卷和备份服务的 OpenShift 节点上载入 nvme-fabrics 模块，则需要应用类似如下的 MachineConfig ： 

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
    service: cinder
  name: 99-master-cinder-load-nvme-fabrics
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - path: /etc/modules-load.d/nvme_fabrics.conf
          overwrite: false
          # Mode must be decimal, this is 0644
          mode: 420
          user:
            name: root
          group:
            name: root
          contents:
            # Source can be a http, https, tftp, s3, gs, or data as defined in rfc2397.
            # This is the rfc2397 text/plain string format
            source: data:,nvme-fabrics

如果您使用标签来限制运行 cinder 服务的节点，您需要使用 MachineConfigPool，如 About 节点选择器 所述，将 MachineConfig 的影响限制为您的服务可能运行的节点。

如果您使用一个并行单一节点部署来测试您 migt 中的进程，则需要在 MachineConfig 中将 worker 替换为 master。

您只加载 nvme-fabrics 模块，因为它需要根据需要加载传输特定模块(tcp、rdma、fc)。

对于使用 NVMe-oF 卷的生产环境部署，建议您使用多路径。对于 NVMe-oF 卷 OpenStack 使用原生多路径，称为 ANA。

在 OpenShift 节点重启后，并加载 nvme-fabrics 模块后，您可以通过检查主机来确认操作系统已被配置并支持 ANA： 

cat /sys/module/nvme_core/parameters/multipath
重要

ANA 不使用 Linux 多路径设备映射器，但当前 OpenStack 代码需要在计算节点上运行 multipathd 以便 Nova 可以使用多路径，因此请记得在多路径部分跟踪计算节点的 多路径部分。

1.13.5.2.6. 多路径（Multipathing）
复制链接

对于 iSCSI 和 FC 协议，建议使用多路径，其有 4 个部分：

  • 准备 OpenShift 主机
  • 配置 Cinder 服务
  • 准备 Nova 计算
  • 配置 Nova 服务

要准备 OpenShift 主机，您需要确保配置 Linux 多路径设备映射器并在 OpenShift 主机上运行，并使用类似如下的 MachineConfig 进行以下操作： 

# Includes the /etc/multipathd.conf contents and the systemd unit changes
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
    service: cinder
  name: 99-master-cinder-enable-multipathd
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - path: /etc/multipath.conf
          overwrite: false
          # Mode must be decimal, this is 0600
          mode: 384
          user:
            name: root
          group:
            name: root
          contents:
            # Source can be a http, https, tftp, s3, gs, or data as defined in rfc2397.
            # This is the rfc2397 text/plain string format
            source: data:,defaults%20%7B%0A%20%20user_friendly_names%20no%0A%20%20recheck_wwid%20yes%0A%20%20skip_kpartx%20yes%0A%20%20find_multipaths%20yes%0A%7D%0A%0Ablacklist%20%7B%0A%7D
    systemd:
      units:
      - enabled: true
        name: multipathd.service

如果您使用标签来限制运行 cinder 服务的节点，如 About 节点选择器 所述，将 MachineConfig 的影响限制为您的服务可能运行的节点。

如果您使用一个并行单一节点部署来测试进程，您可能需要在 MachineConfig 中将 worker 替换为 master。

要将 Cinder 服务配置为使用多路径，您需要在所有 backend 部分和 [DEFAULT] 部分中启用 use_multipath_for_image_xfer 配置选项，但在 Podified 部署中，您不需要担心它，因为这是默认的。因此，只要您不覆盖它设置 use_multipath_for_image_xfer = false，只要服务在 OpenShift 主机上运行，多路径就可以正常工作。

1.13.6. 配置
复制链接

如 规划新部署 中所述，Cinder 使用配置代码段进行配置，而不使用安装程序定义的模糊配置参数。

部署 Cinder 卷后端的建议方法已更改，以删除旧的限制、增加灵活性并改进操作。

当使用 Director 部署时，您用来使用所有后端运行单个 Cinder 卷服务（每个后端将在其自己的进程中运行），即使仍支持部署方法，但不推荐这样做。建议为每个后端使用卷服务，因为它是一个高级部署模型。

因此，对于 LVM 和 Ceph 后端，您在 cinderVolume 中有 2 个条目，如 limitations 部分所述，您无法为所有卷服务设置全局默认值，因此您必须为每个卷服务定义它，如下所示： 

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  cinder:
    enabled: true
    template:
      cinderVolume:
        lvm:
          customServiceConfig: |
            [DEFAULT]
            debug = True
            [lvm]
< . . . >
        ceph:
          customServiceConfig: |
            [DEFAULT]
            debug = True
            [ceph]
< . . . >

请注意，对于具有使用 Secret 和 customServiceConfigSecrets 密钥的敏感信息的卷后端是推荐的方法。

1.13.7. 准备配置
复制链接

对于采用，而不是使用目标补丁的整个部署清单，比如在其他服务一样，以及在这个补丁中，您将启用不同的 cinder 服务及其特定配置。

警告： 检查所有配置选项是否仍然对新的 OpenStack 版本有效，因为配置选项可能已被弃用、删除或添加。这适用于后端驱动程序特定配置选项和其他通用选项。

有两种方法可以准备用于采用的 cinder 配置，对其进行定制或快速调整。虽然 Cinder 对这两种方法的操作方式没有区别，但建议尽可能定制。

定制方法的高级别解释是：

  1. 确定所有 Cinder 服务配置的通用部分，并删除在 OpenShift 中部署时更改的任何内容，如 [dabase] 部分中的 连接、[DEFAULT] 中的 transport_url 和 log_dir （整个 [coordination] 部分）。此配置进入了 cinder: template: level 的 customServiceConfig （或一个 Secret ），然后在 customServiceConfigSecrets中使用。
  2. 确定是否有特定于调度程序的配置，并将其添加到 cinder: template: cinderScheduler 中的 customServiceConfig 部分。
  3. 确定是否有特定于 API 的配置，并将其添加到 cinder: template: cinderAPI 中的 customServiceConfig 部分。
  4. 如果您部署了 cinder 备份，则获取 cinder 备份相关的配置选项，并将它们添加到 cinder: template: cinderBackup: level 的 customServiceConfig Secrets 中（或一个 Secret ），然后在 customServiceConfigSecrets中使用。您应该删除 [DEFAULT] 部分中的主机配置，以促进未来支持多个副本。
  5. 确定每个驱动程序的独立卷后端配置。该配置不仅是特定的驱动程序部分，它还应包含 [backend_defaults] 部分和 FC zoning 部分，因为 cinder operator 不支持所有卷服务的 customServiceConfig 部分。每个后端在 cinder: template: cinderVolumes 下都有自己的部分，配置将位于 customServiceConfig （或一个 Secret，然后在 customServiceConfigSecrets中使用）。

  6. 检查所使用的任何 cinder 卷驱动程序是否需要自定义供应商镜像。如果这样做，请在 w OpenStack Cinder 生态系统页面中的 厂商说明中找到镜像的位置，并使用 containerImage 键将其添加到特定驱动程序部分。例如，如果您有一个 Pure Storage 数组，且驱动程序已经认证了 OSP18，那么您将有如下内容： 

    spec:
  cinder:
    enabled: true
    template:
      cinderVolume:
        pure:
          containerImage: registry.connect.redhat.com/purestorage/openstack-cinder-volume-pure-rhosp-18-0'
          customServiceConfigSecrets:
            - openstack-cinder-pure-cfg
< . . . >

  7. 外部文件：Cinder 服务有时使用外部文件，如自定义策略或存储凭据或 SSL CA 捆绑包以连接到存储阵列，并且您需要将这些文件提供给正确的容器。要达到此目的，您可以使用 Secret 或 ConfigMap 将信息存储在 OpenShift 中，然后是 extraMounts 键。例如，对于存储在名为 ceph-conf-files 的 Secret 中的 Ceph 凭证，您可以在 OpenstackControlPlane 中对顶层 extraMounts 进行补丁： 

    spec:
  extraMounts:
  - extraVol:
    - extraVolType: Ceph
      mounts:
      - mountPath: /etc/ceph
        name: ceph
        readOnly: true
      propagation:
      - CinderVolume
      - CinderBackup
      - Glance
      volumes:
      - name: ceph
        projected:
          sources:
          - secret:
              name: ceph-conf-files

    但是，对于特定于服务的一个服务（如 API 策略），您可以直接在服务本身上执行。在本例中，您可以包含引用从名为 my-cinder-conf 的 ConfigMap 添加策略的 cinder API 配置，该配置具有 策略 内容的密钥策略： 

    spec:
  cinder:
    enabled: true
    template:
      cinderAPI:
        customServiceConfig: |
           [oslo_policy]
           policy_file=/etc/cinder/api/policy.yaml
      extraMounts:
      - extraVol:
        - extraVolType: Ceph
          mounts:
          - mountPath: /etc/cinder/api
            name: policy
            readOnly: true
          propagation:
          - CinderAPI
          volumes:
          - name: policy
            projected:
              sources:
              - configMap:
                  name: my-cinder-conf
                  items:
                    - key: policy
                      path: policy.yaml

快速和脏进程更为简单：

  1. 创建一个无关的配置文件，从旧部署的 cinder.conf 文件中删除任何特定的配置文件，如 [dabase] 部分中的 连接、transport_url 和 log_dir 中的 [DEFAULT] 部分、整个 [coordination] 部分等。
  2. 假设配置具有敏感信息，请将整个文件的修改内容放到 Secret 中。
  3. 在所有服务中引用此 secret，为每个后端创建一个 cinder 卷部分，并只添加对应的 enabled_backends 选项。
  4. 如上部的定制配置说明中所述，添加外部文件。

快速和脏配置补丁的示例如下： 

   spec:
     cinder:
       enabled: true
       template:
         cinderAPI:
           customServiceConfigSecrets:
             - cinder-conf
         cinderScheduler:
           customServiceConfigSecrets:
             - cinder-conf
         cinderBackup:
           customServiceConfigSecrets:
             - cinder-conf
         cinderVolume:
           lvm1:
             customServiceConfig: |
               [DEFAULT]
               enabled_backends = lvm1
             customServiceConfigSecrets:
               - cinder-conf
           lvm2:
             customServiceConfig: |
               [DEFAULT]
               enabled_backends = lvm2
             customServiceConfigSecrets:
               - cinder-conf

1.13.7.1. 配置生成帮助程序工具
复制链接

创建使用 Operator 部署的正确 Cinder 配置文件有时可能是复杂的体验，特别是第一次，因此您有一个帮助工具可以从 cinder.conf 文件创建文件草案。

这个工具并不是一个自动化工具。这主要是为了帮助您获得这些阶段，可能指出一些潜在的缺陷和提醒。

重要

工具需要安装 PyYAML Python 软件包(pip install PyYAML)。

此 cinder-cfg.py 脚本 默认为从当前目录中读取 cinder.conf 文件（使用 --config 选项），并将文件输出到当前目录（不使用 --out-dir 选项）。

在输出目录中，您始终获得一个带有 Cinder 特定配置补丁的 cinder.patch 文件，以应用到 OpenStackControlPlane CR，但您可能还会获得一个带有一些 Secrets 和 MachineConfigs 的名为 cinder-prereq.yaml 文件的额外文件。

明确为 Ceph 后端的默认值调用设置输入和输出示例： 

$ python cinder-cfg.py --config cinder.conf --out-dir ./
WARNING:root:Cinder is configured to use ['/etc/cinder/policy.yaml'] as policy file, please ensure this file is available for the podified cinder services using "extraMounts" or remove the option.

WARNING:root:Deployment uses Ceph, so make sure the Ceph credentials and configuration are present in OpenShift as a asecret and then use the extra volumes to make them available in all the services that would need them.

WARNING:root:You were using user ['nova'] to talk to Nova, but in podified using the service keystone username is preferred in this case ['cinder']. Dropping that configuration.

WARNING:root:ALWAYS REVIEW RESULTS, OUTPUT IS JUST A ROUGH DRAFT!!

Output written at ./: cinder.patch

脚本会输出一些警告，以便您了解您可能需要做的 - 添加自定义策略，提供 ceph 配置文件，同时让您了解了 service_user 如何被删除。

使用多个后端时，其中一个是 3PAR FC，可以是： 

$ python cinder-cfg.py --config cinder.conf --out-dir ./
WARNING:root:Cinder is configured to use ['/etc/cinder/policy.yaml'] as policy file, please ensure this file is available for the podified cinder services using "extraMounts" or remove the option.

ERROR:root:Backend hpe_fc requires a vendor container image, but there is no certified image available yet. Patch will use the last known image for reference, but IT WILL NOT WORK

WARNING:root:Deployment uses Ceph, so make sure the Ceph credentials and configuration are present in OpenShift as a asecret and then use the extra volumes to make them available in all the services that would need them.

WARNING:root:You were using user ['nova'] to talk to Nova, but in podified using the service keystone username is preferred, in this case ['cinder']. Dropping that configuration.

WARNING:root:Configuration is using FC, please ensure all your OpenShift nodes have HBAs or use labels to ensure that Volume and Backup services are scheduled on nodes with HBAs.

WARNING:root:ALWAYS REVIEW RESULTS, OUTPUT IS JUST A ROUGH DRAFT!!

Output written at ./: cinder.patch, cinder-prereq.yaml

在这种情况下，还有额外的信息。以下列表提供了每个列表的说明：

  • 存在一个信息，提到这个后端驱动程序需要外部厂商依赖项，因此标准容器镜像将无法正常工作。不幸的是，此镜像仍不可用，因此输出补丁文件中会使用较旧的镜像供参考。然后，在镜像可用后，您可以将此镜像替换为您构建或使用红帽官方镜像。在这种情况下，您可以在 cinder.patch 文件中看到： 

          cinderVolumes:
      hpe-fc:
        containerImage: registry.connect.redhat.com/hpe3parcinder/openstack-cinder-volume-hpe3parcinder17-0
  • FC 消息提醒您，此传输协议需要在运行 cinder 服务的节点上存在特定的 HBA 卡。

  • 在这种情况下，它已创建了 cinder-prereq.yaml 文件，并在文件中有一个 MachineConfig 和一个 Secret。MachineConfig 名为 99-master-cinder-enable-multipathd，如 name 推荐在所有 OCP worker 节点上启用多路径。Secret 名为 openstackcinder-volumes-hpe_fc，包含 3PAR 后端配置，因为它具有敏感信息（凭证）。cinder.patch 文件使用以下配置： 

       cinderVolumes:
      hpe-fc:
        customServiceConfigSecrets:
        - openstackcinder-volumes-hpe_fc

1.13.8. 流程 - Cinder 采用
复制链接

假设您已经停止了 Cinder 服务，准备了 OpenShift 节点，部署 OpenStack 操作器和裸机 OpenStack 清单，并迁移数据库，并准备好使用 Cinder 服务补丁清单，您必须应用补丁并等待操作器应用更改并部署 Cinder 服务。

建议将补丁清单写入文件中，如 cinder.patch，然后使用类似如下的内容应用它： 

oc patch openstackcontrolplane openstack --type=merge --patch-file=cinder.patch

例如，对于开发指南的 RBD 部署，cinder.patch 应如下所示： 

spec:
  extraMounts:
  - extraVol:
    - extraVolType: Ceph
      mounts:
      - mountPath: /etc/ceph
        name: ceph
        readOnly: true
      propagation:
      - CinderVolume
      - CinderBackup
      - Glance
      volumes:
      - name: ceph
        projected:
          sources:
          - secret:
              name: ceph-conf-files
  cinder:
    enabled: true
    apiOverride:
      route: {}
    template:
      databaseInstance: openstack
      secret: osp-secret
      cinderAPI:
        override:
          service:
            internal:
              metadata:
                annotations:
                  metallb.universe.tf/address-pool: internalapi
                  metallb.universe.tf/allow-shared-ip: internalapi
                  metallb.universe.tf/loadBalancerIPs: 172.17.0.80
              spec:
                type: LoadBalancer
        replicas: 1
        customServiceConfig: |
          [DEFAULT]
          default_volume_type=tripleo
      cinderScheduler:
        replicas: 1
      cinderBackup:
        networkAttachments:
        - storage
        replicas: 1
        customServiceConfig: |
          [DEFAULT]
          backup_driver=cinder.backup.drivers.ceph.CephBackupDriver
          backup_ceph_conf=/etc/ceph/ceph.conf
          backup_ceph_user=openstack
          backup_ceph_pool=backups
      cinderVolumes:
        ceph:
          networkAttachments:
          - storage
          replicas: 1
          customServiceConfig: |
            [tripleo_ceph]
            backend_host=hostgroup
            volume_backend_name=tripleo_ceph
            volume_driver=cinder.volume.drivers.rbd.RBDDriver
            rbd_ceph_conf=/etc/ceph/ceph.conf
            rbd_user=openstack
            rbd_pool=volumes
            rbd_flatten_volume_from_snapshot=False
            report_discard_supported=True

部署服务后，您需要清理旧的调度程序和备份服务，这些服务将显示为 down，而其他服务显示为 up ： 

openstack volume service list

+------------------+------------------------+------+---------+-------+----------------------------+
| Binary           | Host                   | Zone | Status  | State | Updated At                 |
+------------------+------------------------+------+---------+-------+----------------------------+
| cinder-backup    | standalone.localdomain | nova | enabled | down  | 2023-06-28T11:00:59.000000 |
| cinder-scheduler | standalone.localdomain | nova | enabled | down  | 2023-06-28T11:00:29.000000 |
| cinder-volume    | hostgroup@tripleo_ceph | nova | enabled | up    | 2023-06-28T17:00:03.000000 |
| cinder-scheduler | cinder-scheduler-0     | nova | enabled | up    | 2023-06-28T17:00:02.000000 |
| cinder-backup    | cinder-backup-0        | nova | enabled | up    | 2023-06-28T17:00:01.000000 |
+------------------+------------------------+------+---------+-------+----------------------------+

在这种情况下，您需要删除主机 standalone.localdomain的服务 

oc exec -it cinder-scheduler-0 -- cinder-manage service remove cinder-backup standalone.localdomain
oc exec -it cinder-scheduler-0 -- cinder-manage service remove cinder-scheduler standalone.localdomain

我们未保留备份服务名称的原因是，我们有机会更改其配置以支持 Active-Active，尽管现在我们没有这样做，因为我们现在有 1 个副本。

现在 Cinder 服务正在运行，DB 模式迁移已完成，您可以继续应用 DB 数据迁移。虽然这不是精确运行这些数据迁移所必需的，因为您可以在下一次升级前运行这些数据迁移，但最好在下次升级前运行它们，以便在部署上运行生产工作负载前确保没有问题。

运行 DB 数据迁移的命令是： 

oc exec -it cinder-scheduler-0 -- cinder-manage db online_data_migrations

1.13.9. post-checks
复制链接

在运行任何检查前，您需要为 openstack 命令设置正确的云配置，才能连接到 OpenShift control plane。

确保定义了 openstack 别名： 

alias openstack="oc exec -t openstackclient -- openstack"

现在，您可以运行一组测试来确认部署正在使用旧的数据库内容：

  • 查看 Cinder 端点已定义并指向 pod 指定的 FQDN： 

    openstack endpoint list --service cinderv3

  • 检查 cinder 服务是否正在运行并已启动。API 不会被显示，但如果您获得响应，则还了解它： 

    openstack volume service list

  • 检查您的旧卷类型、卷、快照和备份是否存在： 

    openstack volume type list
openstack volume list
openstack volume snapshot list
openstack volume backup list

要确认配置是否正常工作，建议使用以下基本操作：

  • 从镜像创建卷，以检查与 glance 的连接是否正常工作。 

    openstack volume create --image cirros --bootable --size 1 disk_new

  • 将旧的附加卷备份到新备份中。Example: 

    openstack --os-volume-api-version 3.47 volume create --backup backup restored

您不会从镜像使用新卷引导 nova 实例，或尝试分离旧卷，因为 nova 和 cinder 仍未连接。

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2026 Red Hat返回顶部