红帽全球峰会OpenShift Container Storage is now OpenShift Data Foundation starting with version 4.9.
4.3. 存储集群创建
OpenShift Data Foundation 操作器本身不提供存储功能，而且必须定义所需的存储配置。
安装 Operator 后，可使用 OpenShift Container Platform 控制台向导或 CLI 创建新的 StorageCluster，并使用 ocs-operator 协调这个 StorageCluster。OpenShift Data Foundation 在每次安装中支持单个 StorageCluster。ocs-operator 协调忽略了在第一个 CR 之后创建的 StorageCluster CR。
OpenShift Data Foundation 允许以下 StorageCluster 配置：
- 内部
-
在 Internal 模式下，所有组件都在 OpenShift Container Platform 集群中容器化，并使用在安装向导中根据管理员指定的
StorageClass创建的动态置备持久性卷(PV)。 - 内部附加
-
此模式与内部模式类似，但管理员需要定义直接附加到 Ceph 用于其后备存储的群集节点的本地存储设备。另外，管理员需要创建与本地存储 operator 协调的 CR 以提供
StorageClass。ocs-operator使用这个StorageClass作为 Ceph 的后备存储。 - 外部
- 在这种模式下，Ceph 组件不会在 OpenShift Container Platform 集群内运行，而是为应用程序可以为其创建 PV 的外部 OpenShift Container Storage 安装提供连接。其他组件根据需要在集群中运行。
- MCG 独立
- 此模式有助于在没有附带的 CephCluster 的情况下安装多云对象网关系统。
找到 StorageCluster CR 后，ocs-operator 会对其进行验证，并开始创建后续资源来定义存储组件。
4.3.1. 内部模式存储集群
内部和外部附加存储集群的设置过程相同，如下所示：
|
| 创建集群应用用于创建 Ceph 卷的存储类。 |
|
| 创建集群应用用于创建 Ceph 卷快照的卷快照类。 |
| Ceph RGW 配置 | 创建各种 Ceph 对象 CR，以启用和提供对 Ceph RGW 对象存储端点的访问。 |
| Ceph RBD 配置 |
创建 |
| CephFS 配置 |
创建 |
| Rook-Ceph 配置 |
创建 |
|
|
创建 |
|
|
创建 |
| 作业模板 |
创建 |
| Quickstarts |
创建 |
4.3.1.1. 集群创建
在 ocs-operator 创建 CephCluster CR 后，rook-operator 根据所需的配置创建 Ceph 集群。rook-operator 配置以下组件：
|
Ceph |
在集群中的不同节点上启动三个 Ceph |
|
Ceph | 此守护进程已启动，它会为集群收集指标并将其报告到 Prometheus。 |
| Ceph OSD |
这些 OSD 根据 |
| CSI 置备程序 |
为 RBD 和 |
|
CSI 卷插件和 |
RBD 和 |
配置 CephCluster CR 后，Rook 会协调剩余的 Ceph CR 以完成设置：
|
|
|
|
|
|
|
|
|
|
|
|
操作器监控 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)部署 |
|
| Microsoft Azure 部署 |
|
| Google Cloud Platform(GCP)部署 |
|
| On-prem 部署 |
如果 RGW 存在， |
| 以上所述部署都不适用 |
|
默认 BucketClass
创建带有放置策略到默认 BackingStore 的 BucketClass。
NooBaa pod
以下 NooBaa pod 已创建并启动：
| 数据库(DB) | 一个 Postgres DB 用来保存元数据、统计信息和事件等。然而，它不会保存存储的实际数据。 |
| Core | 这是处理配置、后台进程、元数据管理、统计信息等的 pod。 |
| Endpoints |
这些 pod 执行与 I/O 相关的实际工作，如重复数据删除和压缩、与不同服务通信以写入和读取数据等。端点与 |
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 配置 |
指定外部 |
| 外部 Ceph 凭据 Secret | 包含用于连接外部 Ceph 实例的凭据的 Secret。 |
| 外部 Ceph StorageClasses | 一个或多个 StorageClasses，用于为 RBD、CephFS 和/或 RGW 创建卷。 |
| 启用 CephFS CSI 驱动程序 |
如果指定了 |
| Ceph RGW 配置 | 如果指定了 RGW StorageClass，请创建各种 Ceph 对象 CR 来启用和提供对 Ceph RGW 对象存储端点的访问。 |
创建 ConfigMap 中指定的资源后，StorageCluster 创建过程会进行如下：
|
|
创建 |
|
|
创建应用程序用于创建 Ceph 卷快照的 |
|
|
创建 |
|
|
创建 |
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)部署 |
|
| Microsoft Azure 部署 |
|
| Google Cloud Platform(GCP)部署 |
|
| On-prem 部署 |
如果 RGW 存在， |
| 以上所述部署都不适用 |
|
默认 BucketClass
创建带有放置策略到默认 BackingStore 的 BucketClass。
NooBaa pod
以下 NooBaa pod 已创建并启动：
| 数据库(DB) | 一个 Postgres DB 用来保存元数据、统计信息和事件等。然而，它不会保存存储的实际数据。 |
| Core | 这是处理配置、后台进程、元数据管理、统计信息等的 pod。 |
| Endpoints |
这些 pod 执行与 I/O 相关的实际工作，如重复数据删除和压缩、与不同服务通信以写入和读取数据等。端点与 |
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)部署 |
|
| Microsoft Azure 部署 |
|
| Google Cloud Platform(GCP)部署 |
|
| On-prem 部署 |
如果 RGW 存在， |
| 以上所述部署都不适用 |
|
默认 BucketClass
创建带有放置策略到默认 BackingStore 的 BucketClass。
NooBaa pod
以下 NooBaa pod 已创建并启动：
| 数据库(DB) | 一个 Postgres DB 用来保存元数据、统计信息和事件等。然而，它不会保存存储的实际数据。 |
| Core | 这是处理配置、后台进程、元数据管理、统计信息等的 pod。 |
| Endpoints |
这些 pod 执行与 I/O 相关的实际工作，如重复数据删除和压缩、与不同服务通信以写入和读取数据等。端点与 |
Route
为使用 S3 的应用创建 NooBaa S3 接口的路由。
服务
为 NooBaa S3 接口创建一个服务，供使用 S3 的应用创建。
4.3.3.2. StorageSystem 创建
作为 StorageCluster 创建的一部分，odf-operator 会自动创建一个对应的 StorageSystem CR，它将 StorageCluster 公开给 OpenShift Data Foundation。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}