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
$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
$ oc label nodes worker0 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
:
如果您使用标签来限制运行 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
:
如果您使用标签来限制运行 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
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
进行以下操作:
如果您使用标签来限制运行 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 部分所述,您无法为所有卷服务设置全局默认值,因此您必须为每个卷服务定义它,如下所示:
请注意,对于具有使用 Secret
和 customServiceConfigSecrets
密钥的敏感信息的卷后端是推荐的方法。
1.13.7. 准备配置 复制链接链接已复制到粘贴板!
对于采用,而不是使用目标补丁的整个部署清单,比如在其他服务一样,以及在这个补丁中,您将启用不同的 cinder 服务及其特定配置。
警告: 检查所有配置选项是否仍然对新的 OpenStack 版本有效,因为配置选项可能已被弃用、删除或添加。这适用于后端驱动程序特定配置选项和其他通用选项。
有两种方法可以准备用于采用的 cinder 配置,对其进行定制或快速调整。虽然 Cinder 对这两种方法的操作方式没有区别,但建议尽可能定制。
定制方法的高级别解释是:
-
确定所有 Cinder 服务配置的通用部分,并删除在 OpenShift 中部署时更改的任何内容,如
[dabase]
部分中的连接
、[DEFAULT]
中的transport_url
和log_dir
(整个[coordination]
部分)。此配置进入了cinder: template:
level 的customServiceConfig
(或一个Secret
),然后在customServiceConfigSecrets
中使用。 -
确定是否有特定于调度程序的配置,并将其添加到
cinder: template: cinderScheduler
中的customServiceConfig
部分。 -
确定是否有特定于 API 的配置,并将其添加到
cinder: template: cinderAPI
中的customServiceConfig
部分。 -
如果您部署了 cinder 备份,则获取 cinder 备份相关的配置选项,并将它们添加到
cinder: template: cinderBackup:
level 的customServiceConfig
Secrets 中(或一个Secret
),然后在customServiceConfigSecrets
中使用。您应该删除[DEFAULT]
部分中的主机配置,以促进未来支持多个副本。 -
确定每个驱动程序的独立卷后端配置。该配置不仅是特定的驱动程序部分,它还应包含
[backend_defaults]
部分和 FC zoning 部分,因为 cinder operator 不支持所有卷服务的customServiceConfig
部分。每个后端在cinder: template: cinderVolumes
下都有自己的部分,配置将位于customServiceConfig
(或一个Secret
,然后在customServiceConfigSecrets
中使用)。 检查所使用的任何 cinder 卷驱动程序是否需要自定义供应商镜像。如果这样做,请在 w OpenStack Cinder 生态系统页面中的 厂商说明中找到镜像的位置,并使用
containerImage
键将其添加到特定驱动程序部分。例如,如果您有一个 Pure Storage 数组,且驱动程序已经认证了 OSP18,那么您将有如下内容:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 外部文件:Cinder 服务有时使用外部文件,如自定义策略或存储凭据或 SSL CA 捆绑包以连接到存储阵列,并且您需要将这些文件提供给正确的容器。要达到此目的,您可以使用
Secret
或ConfigMap
将信息存储在 OpenShift 中,然后是extraMounts
键。例如,对于存储在名为ceph-conf-files
的Secret
中的 Ceph 凭证,您可以在OpenstackControlPlane
中对顶层extraMounts
进行补丁:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 但是,对于特定于服务的一个服务(如 API 策略),您可以直接在服务本身上执行。在本例中,您可以包含引用从名为
my-cinder-conf
的ConfigMap
添加策略的 cinder API 配置,该配置具有策略
内容的密钥策略:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
快速和脏进程更为简单:
-
创建一个无关的配置文件,从旧部署的
cinder.conf
文件中删除任何特定的配置文件,如[dabase]
部分中的连接
、transport_url
和log_dir
中的[DEFAULT]
部分、整个[coordination]
部分等。 -
假设配置具有敏感信息,请将整个文件的修改内容放到
Secret
中。 -
在所有服务中引用此 secret,为每个后端创建一个 cinder 卷部分,并只添加对应的
enabled_backends
选项。 - 如上部的定制配置说明中所述,添加外部文件。
快速和脏配置补丁的示例如下:
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 后端的默认值调用设置输入和输出示例:
脚本会输出一些警告,以便您了解您可能需要做的 - 添加自定义策略,提供 ceph 配置文件,同时让您了解了 service_user
如何被删除。
使用多个后端时,其中一个是 3PAR FC,可以是:
在这种情况下,还有额外的信息。以下列表提供了每个列表的说明:
存在一个信息,提到这个后端驱动程序需要外部厂商依赖项,因此标准容器镜像将无法正常工作。不幸的是,此镜像仍不可用,因此输出补丁文件中会使用较旧的镜像供参考。然后,在镜像可用后,您可以将此镜像替换为您构建或使用红帽官方镜像。在这种情况下,您可以在
cinder.patch
文件中看到:cinderVolumes: hpe-fc: containerImage: registry.connect.redhat.com/hpe3parcinder/openstack-cinder-volume-hpe3parcinder17-0
cinderVolumes: hpe-fc: containerImage: registry.connect.redhat.com/hpe3parcinder/openstack-cinder-volume-hpe3parcinder17-0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
cinderVolumes: hpe-fc: customServiceConfigSecrets: - openstackcinder-volumes-hpe_fc
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.13.8. 流程 - Cinder 采用 复制链接链接已复制到粘贴板!
假设您已经停止了 Cinder 服务,准备了 OpenShift 节点,部署 OpenStack 操作器和裸机 OpenStack 清单,并迁移数据库,并准备好使用 Cinder 服务补丁清单,您必须应用补丁并等待操作器应用更改并部署 Cinder 服务。
建议将补丁清单写入文件中,如 cinder.patch
,然后使用类似如下的内容应用它:
oc patch openstackcontrolplane openstack --type=merge --patch-file=cinder.patch
oc patch openstackcontrolplane openstack --type=merge --patch-file=cinder.patch
例如,对于开发指南的 RBD 部署,cinder.patch
应如下所示:
部署服务后,您需要清理旧的调度程序和备份服务,这些服务将显示为 down,而其他服务显示为 up :
在这种情况下,您需要删除主机 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
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
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"
alias openstack="oc exec -t openstackclient -- openstack"
现在,您可以运行一组测试来确认部署正在使用旧的数据库内容:
查看 Cinder 端点已定义并指向 pod 指定的 FQDN:
openstack endpoint list --service cinderv3
openstack endpoint list --service cinderv3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检查 cinder 服务是否正在运行并已启动。API 不会被显示,但如果您获得响应,则还了解它:
openstack volume service list
openstack volume service list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检查您的旧卷类型、卷、快照和备份是否存在:
openstack volume type list openstack volume list openstack volume snapshot list openstack volume backup list
openstack volume type list openstack volume list openstack volume snapshot list openstack volume backup list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
要确认配置是否正常工作,建议使用以下基本操作:
从镜像创建卷,以检查与 glance 的连接是否正常工作。
openstack volume create --image cirros --bootable --size 1 disk_new
openstack volume create --image cirros --bootable --size 1 disk_new
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将旧的附加卷备份到新备份中。Example:
openstack --os-volume-api-version 3.47 volume create --backup backup restored
openstack --os-volume-api-version 3.47 volume create --backup backup restored
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
您不会从镜像使用新卷引导 nova 实例,或尝试分离旧卷,因为 nova 和 cinder 仍未连接。