1.13. 使用块存储服务


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

通常,采用过程如下:

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

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

1.13.1. 限制

当前有一些限制值得突出显示;有些限制与本指南有关,而一些与 Operator 相关的:

  • 所有 cinder 卷都没有全局 nodeSelector,因此需要为每个后端指定它。这可能会在以后改变。
  • 所有 cinder 卷都没有全局 customServiceConfigcustomServiceConfigSecrets,因此需要为每个后端指定它。这可能会在以后改变。
  • 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
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap
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
< . . . >
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

如果您使用标签来限制运行 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
Copy to Clipboard Toggle word wrap

如果您使用标签来限制运行 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
Copy to Clipboard Toggle word wrap
重要

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
Copy to Clipboard Toggle word wrap

如果您使用标签来限制运行 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]
< . . . >
Copy to Clipboard Toggle word wrap

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

1.13.7. 准备配置

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

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

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

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

  1. 确定所有 Cinder 服务配置的通用部分,并删除在 OpenShift 中部署时更改的任何内容,如 [dabase] 部分中的 连接[DEFAULT] 中的 transport_urllog_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
    < . . . >
    Copy to Clipboard Toggle word wrap
  7. 外部文件:Cinder 服务有时使用外部文件,如自定义策略或存储凭据或 SSL CA 捆绑包以连接到存储阵列,并且您需要将这些文件提供给正确的容器。要达到此目的,您可以使用 SecretConfigMap 将信息存储在 OpenShift 中,然后是 extraMounts 键。例如,对于存储在名为 ceph-conf-filesSecret 中的 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
    Copy to Clipboard Toggle word wrap

    但是,对于特定于服务的一个服务(如 API 策略),您可以直接在服务本身上执行。在本例中,您可以包含引用从名为 my-cinder-confConfigMap 添加策略的 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
    Copy to Clipboard Toggle word wrap

快速和脏进程更为简单:

  1. 创建一个无关的配置文件,从旧部署的 cinder.conf 文件中删除任何特定的配置文件,如 [dabase] 部分中的 连接transport_urllog_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
Copy to Clipboard Toggle word wrap

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,但您可能还会获得一个带有一些 SecretsMachineConfigs 的名为 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
Copy to Clipboard Toggle word wrap

脚本会输出一些警告,以便您了解您可能需要做的 - 添加自定义策略,提供 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
Copy to Clipboard Toggle word wrap

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

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

          cinderVolumes:
          hpe-fc:
            containerImage: registry.connect.redhat.com/hpe3parcinder/openstack-cinder-volume-hpe3parcinder17-0
    Copy to Clipboard Toggle word wrap
  • FC 消息提醒您,此传输协议需要在运行 cinder 服务的节点上存在特定的 HBA 卡。
  • 在这种情况下,它已创建了 cinder-prereq.yaml 文件,并在文件中有一个 MachineConfig 和一个 SecretMachineConfig 名为 99-master-cinder-enable-multipathd,如 name 推荐在所有 OCP worker 节点上启用多路径。Secret 名为 openstackcinder-volumes-hpe_fc,包含 3PAR 后端配置,因为它具有敏感信息(凭证)。cinder.patch 文件使用以下配置:

       cinderVolumes:
          hpe-fc:
            customServiceConfigSecrets:
            - openstackcinder-volumes-hpe_fc
    Copy to Clipboard Toggle word wrap

1.13.8. 流程 - Cinder 采用

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

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

oc patch openstackcontrolplane openstack --type=merge --patch-file=cinder.patch
Copy to Clipboard Toggle word wrap

例如,对于开发指南的 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
Copy to Clipboard Toggle word wrap

部署服务后,您需要清理旧的调度程序和备份服务,这些服务将显示为 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 |
+------------------+------------------------+------+---------+-------+----------------------------+
Copy to Clipboard Toggle word wrap

在这种情况下,您需要删除主机 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
Copy to Clipboard Toggle word wrap

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

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

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

oc exec -it cinder-scheduler-0 -- cinder-manage db online_data_migrations
Copy to Clipboard Toggle word wrap

1.13.9. post-checks

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

确保定义了 openstack 别名:

alias openstack="oc exec -t openstackclient -- openstack"
Copy to Clipboard Toggle word wrap

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

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

    openstack endpoint list --service cinderv3
    Copy to Clipboard Toggle word wrap
  • 检查 cinder 服务是否正在运行并已启动。API 不会被显示,但如果您获得响应,则还了解它:

    openstack volume service list
    Copy to Clipboard Toggle word wrap
  • 检查您的旧卷类型、卷、快照和备份是否存在:

    openstack volume type list
    openstack volume list
    openstack volume snapshot list
    openstack volume backup list
    Copy to Clipboard Toggle word wrap

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

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

    openstack volume create --image cirros --bootable --size 1 disk_new
    Copy to Clipboard Toggle word wrap
  • 将旧的附加卷备份到新备份中。Example:

    openstack --os-volume-api-version 3.47 volume create --backup backup restored
    Copy to Clipboard Toggle word wrap

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

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat