Translated message

A translation of this page exists in English.

针对 Red Hat OpenStack Platform 16.x 的 CephFS NFS Manila-CSI 工作负载建议

已更新 -

在 Red Hat OpenStack Platform 16.x 中,OpenStack Manila 可以配置一个或多个后端存储系统。这些建议适用于通过 NFS 公开时使用 CephFS 作为后端

架构

共享文件系统服务(马尼拉)中的 CephFS NFS 后端利用多个组件提供对 CephFS 共享的 NFSv4.1 协议访问:Ceph 元数据服务器 (MDS)、CephFS NFS 网关 (NFS-Ganesha) 和 Ceph集群服务组件。当由 Director 部署时,NFS-Ganesha 服务默认在具有 Ceph 服务的 Controller 节点上运行。

下图显示了 API 和 NFS 客户端如何与 Red Hat OpenStack Platform 16.x 中的服务交互:

cephfs nfs 拓扑

Ceph 集群组件管理自己的高可用性 (HA) 状态,并且一般来说,这些守护进程有多个实例在运行。相比之下,在 Red Hat OpenStack Platform 16.x 中,一次只有一个 NFS-Ganesha 实例可以提供文件共享服务
为了避免 NFS 共享数据路径中的单点故障,NFS-Ganesha 在主动-被动配置中的 OpenStack 控制器节点上运行,由 Pacemaker-Corosync 集群管理。NFS-Ganesha 使用虚拟服务 IP 地址来跨 Controller 节点充当虚拟服务。

马尼拉CSI内部

Manila CSI 将协调与 Manila API 交互的 NFS 共享的创建/生命周期; OpenShift 工作节点将继续挂载共享并使 RWX 共享可供 POD 访问。

建议

在规划 Manila 和 NFS-Ganesha 网络的部署时,请注意根据此服务的预期用途调整控制器节点 CPU 和网络的大小。

  • 您必须确保 StorageNFS 网络的网络接口有足够的带宽来支持所有 OpenShift 和 OpenStack 使用方的工作负载。或者,将其隔离在专用 NIC 上可以避免带宽饱和,这对于同一 NIC 上的其他网络来说可能会出现问题。

  • 您还必须确保控制器节点有足够的 CPU,因为随着更多工作负载消耗 manila 共享,NFS-Ganesha 网关的 CPU 利用率会增加。

  • 使用 NFS 共享的工作负载还必须能够适应服务的故障转移窗口。如果托管服务的控制器节点发生故障或在计划维护期间发生故障转移。当服务在另一个节点上启动时,这些故障转移可能需要几分钟才能解决。

OSP 16.x 架构的其他限制

除非 OpenStack 管理员通过共享类型额外规范明确要求提供这些功能,否则 OpenStack Manila 的可选功能(例如创建快照或将其克隆到新共享的功能)不可用。请注意,从 OSP16.2 开始,Manila 的 CephFS 驱动程序当前不支持将快照克隆到共享中。此功能将在 Red Hat OpenStack 平台的未来版本中提供。

在 OpenShift 中对 OpenStack Manila 持久卷使用 ReadWriteOnce 访问模式时,将不支持 fsGroups。这不应影响 Pod 内的读/写操作。但是,这些持久卷并不适合任何需要特定文件系统所有权或权限的应用程序。

Comments