4.3. 存储集群创建


OpenShift Data Foundation 操作器本身不提供存储功能,而且必须定义所需的存储配置。

安装 Operator 后,可使用 OpenShift Container Platform 控制台向导或 CLI 创建新的 StorageCluster,并使用 ocs-operator 协调这个 StorageCluster。OpenShift Data Foundation 在每次安装中支持单个 StorageClusterocs-operator 协调忽略了在第一个 CR 之后创建的 StorageCluster CR。

OpenShift Data Foundation 允许以下 StorageCluster 配置:

内部
在 Internal 模式下,所有组件都在 OpenShift Container Platform 集群中容器化,并使用在安装向导中根据管理员指定的 StorageClass 创建的动态置备持久性卷(PV)。
内部附加
此模式与内部模式类似,但管理员需要定义直接附加到 Ceph 用于其后备存储的群集节点的本地存储设备。另外,管理员需要创建与本地存储 operator 协调的 CR 以提供 StorageClassocs-operator 使用这个 StorageClass 作为 Ceph 的后备存储。
外部
在这种模式下,Ceph 组件不会在 OpenShift Container Platform 集群内运行,而是为应用程序可以为其创建 PV 的外部 OpenShift Container Storage 安装提供连接。其他组件根据需要在集群中运行。
MCG 独立
此模式有助于在没有附带的 CephCluster 的情况下安装多云对象网关系统。

找到 StorageCluster CR 后,ocs-operator 会对其进行验证,并开始创建后续资源来定义存储组件。

4.3.1. 内部模式存储集群

内部和外部附加存储集群的设置过程相同,如下所示:

StorageClasses

创建集群应用用于创建 Ceph 卷的存储类。

SnapshotClasses

创建集群应用用于创建 Ceph 卷快照的卷快照类。

Ceph RGW 配置

创建各种 Ceph 对象 CR,以启用和提供对 Ceph RGW 对象存储端点的访问。

Ceph RBD 配置

创建 CephBlockPool CR 以启用 RBD 存储。

CephFS 配置

创建 CephFilesystem CR 以启用 CephFS 存储。

Rook-Ceph 配置

创建 rook-config-override ConfigMap,以管理底层 Ceph 集群的整体行为。

CephCluster

创建 CephCluster CR,以从 rook-ceph-operator 触发 Ceph 协调。如需更多信息,请参阅 Rook-Ceph 操作器

NoobaaSystem

创建 NooBaa CR,以触发从 mcg-operator 的协调。如需更多信息,请参阅 MCG operator

作业模板

创建 OpenShift Template CR,以定义作业,以运行 OpenShift Container Storage 的管理操作。

Quickstarts

创建 QuickStart CR,在 Web 控制台中显示 Quickstart 指南。

4.3.1.1. 集群创建

ocs-operator 创建 CephCluster CR 后,rook-operator 根据所需的配置创建 Ceph 集群。rook-operator 配置以下组件:

Ceph mon 守护进程

在集群中的不同节点上启动三个 Ceph mon 守护进程。它们管理 Ceph 集群的核心元数据,它们必须组成大多数仲裁。如果每个 mon 的元数据位于云环境中,则由 PV 支持,如果它位于本地存储设备环境中,则由本地主机上的路径支持。

Ceph mgr 守护进程

此守护进程已启动,它会为集群收集指标并将其报告到 Prometheus。

Ceph OSD

这些 OSD 根据 storageClassDeviceSets 的配置创建。每一 OSD 使用一个存储用户数据的 PV。默认情况下,Ceph 使用 CRUSH 算法在不同的 OSD 之间维护三个应用数据副本,以实现高持久性和可用性。

CSI 置备程序

为 RBD 和 CephFS 启动这些调配器。当为 OpenShift Container Storage 的存储类请求卷时,请求将定向到 Ceph-CSI 驱动程序来置备 Ceph 中的卷。

CSI 卷插件和 CephFS

RBD 和 CephFS 的 CSI 卷插件在集群中的每一节点上启动。卷插件需要处于运行状态,只要应用需要挂载 Ceph 卷的位置。

配置 CephCluster CR 后,Rook 会协调剩余的 Ceph CR 以完成设置:

CephBlockPool

CephBlockPool CR 提供 Rook operator 的配置,以便为 RWO 卷创建 Ceph 池。

CephFilesystem

CephFilesystem CR 指示 Rook 操作器使用 CephFS 配置共享文件系统,通常用于 RWX 卷。CephFS 元数据服务器(MDS)已启动,以管理共享卷。

CephObjectStore

CephObjectStore CR 指示 Rook 操作器使用 RGW 服务配置对象存储

CephObjectStoreUser CR

CephObjectStoreUser CR 指示 Rook 操作器将 NooBaa 的对象存储用户配置为使用,发布 access/private 密钥和 CephObjectStore 端点。

操作器监控 Ceph 健康状况,以确保存储平台健康。如果某个 mon 守护进程长时间停机(10 分钟),Rook 会在其位置启动一个新的 mon,以便能够完全恢复仲裁。

ocs-operator 更新 CephCluster CR 时,Rook 会立即响应请求的更改,以更新集群配置。

4.3.1.2. NooBaa 系统创建

当创建 NooBaa 系统时,mcg-operator 会协调以下内容:

默认 BackingStore

根据部署 OpenShift Container Platform 和 OpenShift Data Foundation 的平台,会创建一个默认的后备存储资源,以便存储桶可以将其用于放置策略。不同的选项如下:

Amazon Web Services(AWS)部署

mcg-operator 使用 CloudCredentialsOperator (CCO)来 mint 凭证,以便创建新的 AWS::S3 存储桶并在该存储桶上创建 BackingStore

Microsoft Azure 部署

mcg-operator 使用 CCO 来 mint 凭证,以便创建新的 Azure Blob 并在该存储桶上创建一个 BackingStore

Google Cloud Platform(GCP)部署

mcg-operator 使用 CCO 来 mint 凭证以创建新的 GCP 存储桶,并将在该存储桶上创建一个 BackingStore。

On-prem 部署

如果 RGW 存在,scg-operator 会在 RGW 上创建新的 CephUser 和新存储桶,并在该存储桶基础上创建 BackingStore

以上所述部署都不适用

mcg-operator 基于默认存储类创建一个 pv-pool,并在该存储桶之上创建一个 BackingStore

默认 BucketClass

创建带有放置策略到默认 BackingStoreBucketClass

NooBaa pod

以下 NooBaa pod 已创建并启动:

数据库(DB)

一个 Postgres DB 用来保存元数据、统计信息和事件等。然而,它不会保存存储的实际数据。

Core

这是处理配置、后台进程、元数据管理、统计信息等的 pod。

Endpoints

这些 pod 执行与 I/O 相关的实际工作,如重复数据删除和压缩、与不同服务通信以写入和读取数据等。端点与 HorizonalPodAutoscaler 集成,并根据现有端点 pod 上观察到的 CPU 使用量增加和减少。

Route

为使用 S3 的应用创建 NooBaa S3 接口的路由。

服务

为 NooBaa S3 接口创建一个服务,供使用 S3 的应用创建。

4.3.2. 外部模式存储集群

对于外部存储集群,ocs-operator 的设置过程略有不同。ocs-operator 会查找是否存在 rook-ceph-external-cluster-details ConfigMap,该 ConfigMap 必须由其他人(管理员或控制台)创建。有关如何创建 ConfigMap 的详情,请参考为外部模式创建 OpenShift Data Foundation。然后,ocs-operator 会创建部分或全部以下资源,如 ConfigMap 中指定的:

外部 Ceph 配置

指定外部 mon 的端点的 ConfigMap。

外部 Ceph 凭据 Secret

包含用于连接外部 Ceph 实例的凭据的 Secret。

外部 Ceph StorageClasses

一个或多个 StorageClasses,用于为 RBD、CephFS 和/或 RGW 创建卷。

启用 CephFS CSI 驱动程序

如果指定了 CephFS StorageClass,请配置 rook-ceph-operator 以部署 CephFS CSI Pod。

Ceph RGW 配置

如果指定了 RGW StorageClass,请创建各种 Ceph 对象 CR 来启用和提供对 Ceph RGW 对象存储端点的访问。

创建 ConfigMap 中指定的资源后,StorageCluster 创建过程会进行如下:

CephCluster

创建 CephCluster CR,从 rook-ceph-operator 触发 Ceph 协调(请参阅后续小节)。

SnapshotClasses

创建应用程序用于创建 Ceph 卷快照的 SnapshotClasses

NoobaaSystem

创建 NooBaa CR,以从 noobaa-operator 触发协调(请参阅后续部分)。

QuickStarts

创建 Quickstart CR,在控制台中显示 Quickstart 指南。

4.3.2.1. 集群创建

当以外部模式创建 CephCluster CR 时,Rook operator 会执行以下操作:

  • 操作器验证连接可供远程 Ceph 集群使用。连接需要将 mon 端点和 secret 导入到本地集群中。
  • CSI 驱动程序通过与 Ceph 的远程连接进行配置。在内部模式中配置时,RBD 和 CephFS 调配器和卷插件的启动方式与 CSI 驱动程序相似,与 Ceph 的连接正好与 OpenShift 集群外部。
  • 定期监控地址更改,并相应地更新 Ceph-CSI 配置。

4.3.2.2. NooBaa 系统创建

当创建 NooBaa 系统时,mcg-operator 会协调以下内容:

默认 BackingStore

根据部署 OpenShift Container Platform 和 OpenShift Data Foundation 的平台,会创建一个默认的后备存储资源,以便存储桶可以将其用于放置策略。不同的选项如下:

Amazon Web Services(AWS)部署

mcg-operator 使用 CloudCredentialsOperator (CCO)来 mint 凭证,以便创建新的 AWS::S3 存储桶并在该存储桶上创建 BackingStore

Microsoft Azure 部署

mcg-operator 使用 CCO 来 mint 凭证,以便创建新的 Azure Blob 并在该存储桶上创建一个 BackingStore

Google Cloud Platform(GCP)部署

mcg-operator 使用 CCO 来 mint 凭证以创建新的 GCP 存储桶,并将在该存储桶上创建一个 BackingStore。

On-prem 部署

如果 RGW 存在,scg-operator 会在 RGW 上创建新的 CephUser 和新存储桶,并在该存储桶基础上创建 BackingStore

以上所述部署都不适用

mcg-operator 基于默认存储类创建一个 pv-pool,并在该存储桶之上创建一个 BackingStore

默认 BucketClass

创建带有放置策略到默认 BackingStoreBucketClass

NooBaa pod

以下 NooBaa pod 已创建并启动:

数据库(DB)

一个 Postgres DB 用来保存元数据、统计信息和事件等。然而,它不会保存存储的实际数据。

Core

这是处理配置、后台进程、元数据管理、统计信息等的 pod。

Endpoints

这些 pod 执行与 I/O 相关的实际工作,如重复数据删除和压缩、与不同服务通信以写入和读取数据等。端点与 HorizonalPodAutoscaler 集成,并根据现有端点 pod 上观察到的 CPU 使用量增加和减少。

Route

为使用 S3 的应用创建 NooBaa S3 接口的路由。

服务

为 NooBaa S3 接口创建一个服务,供使用 S3 的应用创建。

4.3.3. MCG 独立存储集群

在这种模式中,不会创建 CephCluster。相反,会使用默认值创建一个 NooBaa 系统 CR,以利用 OpenShift Container Platform 中的预先存在的 StorageClasses。

4.3.3.1. NooBaa 系统创建

当创建 NooBaa 系统时,mcg-operator 会协调以下内容:

默认 BackingStore

根据部署 OpenShift Container Platform 和 OpenShift Data Foundation 的平台,会创建一个默认的后备存储资源,以便存储桶可以将其用于放置策略。不同的选项如下:

Amazon Web Services(AWS)部署

mcg-operator 使用 CloudCredentialsOperator (CCO)来 mint 凭证,以便创建新的 AWS::S3 存储桶并在该存储桶上创建 BackingStore

Microsoft Azure 部署

mcg-operator 使用 CCO 来 mint 凭证,以便创建新的 Azure Blob 并在该存储桶上创建一个 BackingStore

Google Cloud Platform(GCP)部署

mcg-operator 使用 CCO 来 mint 凭证以创建新的 GCP 存储桶,并将在该存储桶上创建一个 BackingStore。

On-prem 部署

如果 RGW 存在,scg-operator 会在 RGW 上创建新的 CephUser 和新存储桶,并在该存储桶基础上创建 BackingStore

以上所述部署都不适用

mcg-operator 基于默认存储类创建一个 pv-pool,并在该存储桶之上创建一个 BackingStore

默认 BucketClass

创建带有放置策略到默认 BackingStoreBucketClass

NooBaa pod

以下 NooBaa pod 已创建并启动:

数据库(DB)

一个 Postgres DB 用来保存元数据、统计信息和事件等。然而,它不会保存存储的实际数据。

Core

这是处理配置、后台进程、元数据管理、统计信息等的 pod。

Endpoints

这些 pod 执行与 I/O 相关的实际工作,如重复数据删除和压缩、与不同服务通信以写入和读取数据等。端点与 HorizonalPodAutoscaler 集成,并根据现有端点 pod 上观察到的 CPU 使用量增加和减少。

Route

为使用 S3 的应用创建 NooBaa S3 接口的路由。

服务

为 NooBaa S3 接口创建一个服务,供使用 S3 的应用创建。

4.3.3.2. StorageSystem 创建

作为 StorageCluster 创建的一部分,odf-operator 会自动创建一个对应的 StorageSystem CR,它将 StorageCluster 公开给 OpenShift Data Foundation。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.