#架构

#第1章：简介

Alauda Build of Rook-Ceph 是 Alauda Container Platform (ACP) 的云原生存储层。它作为 Kubernetes 原生系统运行，通过 operator、自定义资源和 CSI 驱动提供持久存储服务。

从应用角度来看，平台提供三种主要存储类型：

• 文件存储：为需要多个 Pod 并发读写访问的工作负载提供共享文件系统语义（例如 RWX 场景）。
• 块存储：为延迟敏感或数据库类工作负载提供低级块设备，需专用卷。
• 对象存储：兼容 S3 的对象访问，用于非结构化数据、备份工件和数据平台集成。

Alauda Build of Rook-Ceph 集成了以下核心开源项目：

• Ceph：分布式存储引擎，提供块、文件和对象能力。
• Rook：用于部署和管理 Ceph 集群的 Kubernetes operator 框架。
• Ceph CSI Operator：管理 Ceph CSI 驱动组件及其生命周期的 operator。
• Ceph CSI：Kubernetes 用于动态配置、挂载/卸载及 Ceph 支持卷生命周期操作的 CSI 实现。

#第2章：架构概览

从整体来看，Alauda Build of Rook-Ceph 完全运行在 Alauda Container Platform 内部。

Alauda Build of Rook-Ceph 架构

Alauda Build of Rook-Ceph 使用故障域配置来确定数据副本如何分布在集群中。故障域代表物理边界，如主机、机架或可用区，数据副本在这些边界内分散以确保高可用性。Alauda Build of Rook-Ceph 根据分配给存储节点的标签自动识别这些故障域。

#第3章：Operators

Alauda Build of Rook-Ceph 由以下两个 Operator Lifecycle Manager (OLM) operator 包组成，部署的 operators 将管理任务和自定义资源编码化，以便任务和资源特性可以轻松自动化：

• acp-storage-operator
• rook-ceph-operator

管理员定义集群的期望最终状态，operators 确保集群处于该状态或接近该状态，且管理员干预最小。

#Rook-Ceph operator

rook-ceph-operator 是 Alauda Build of Rook-Ceph 中 Ceph 的 operator。它使 Ceph 存储系统能够作为 Kubernetes 管理的服务在 Alauda Container Platform 上运行。

rook-ceph-operator 容器自动引导存储集群并监控存储守护进程以维护集群健康。

#组件

rook-ceph-operator 管理以下 Ceph 守护进程组件：

• Mons：Ceph 监视器（mons）维护集群元数据和仲裁。
• OSDs：对象存储守护进程（OSDs）存储和复制数据。
• Mgr：Ceph 管理器（mgr）提供指标和内部管理能力。
• RGW：RADOS 网关（RGW）通过兼容 S3 的 API 提供对象存储访问。
• MDS：元数据服务器（MDS）为 CephFS 共享文件系统提供元数据服务。

#设计图

设计图展示了 rook-ceph-operator 如何将 Ceph 集成到 ACP 中。

应用可以通过挂载块设备和共享文件系统，或使用对象存储 API 来使用此存储层。

#职责

rook-ceph-operator 负责引导和监控存储集群，具体职责包括：

• 自动配置存储组件。
• 启动、监控和管理 RADOS 集群的 Ceph 监视器 Pod 和 Ceph OSD 守护进程。
• 初始化用于管理以下内容的 Pod 和工件：
  • 池的自定义资源
  • 对象存储（S3）
  • 文件系统
• 监控 Ceph 监视器和 OSD 守护进程，保持存储可用和健康。
• 部署和管理监视器的位置，并随着集群规模变化更新监视器配置。
• 监听通过 API 服务请求的期望状态变更并应用这些变更。
• 初始化 Ceph-CSI 驱动。
• 自动配置 Ceph-CSI 将 Ceph 存储挂载到应用 Pod。

rook-ceph-operator 镜像包含生命周期管理所需的工具，不修改数据路径，也不暴露所有低级 Ceph 配置；高级 Ceph 构造如 placement groups 和 CRUSH maps 保持抽象，以简化运维模型。

#资源

operator 会为其在 rook-ceph 命名空间创建的资源添加所有者引用。卸载时，这些引用确保相关资源也被删除，包括 ConfigMaps、Secrets、Services、Deployments 和 DaemonSets。

operator 监听并调和以下自定义资源：

• CephCluster
• CephObjectStore
• CephFilesystem
• CephBlockPool

#生命周期

operator 管理以下 Ceph 和 CSI Pod 的生命周期：

• Rook operator：
  • 一个 operator Pod。
• RBD CSI 驱动：
  • 两个由一个 Deployment 管理的 provisioner Pod。
  • 每个节点一个由 DaemonSet 管理的插件 Pod。
• CephFS CSI 驱动：
  • 两个由一个 Deployment 管理的 provisioner Pod。
  • 每个节点一个由 DaemonSet 管理的插件 Pod。
• 监视器（mons）：
  • 三个监视器 Pod，每个有独立的 Deployment。
  • 在跨区域集群中，五个监视器 Pod：一个在仲裁区，两个在每个数据区。
• 管理器（mgr）：
  • 标准部署中两个管理器 Pod。
• 对象存储守护进程（OSDs）：
  • 初始创建至少三个 OSD。
  • 随集群容量扩展增加更多 OSD。
• 元数据服务器（MDS）：
  • 两个元数据服务器 Pod。
• RADOS 网关（RGW）：
  • 至少两个网关 Pod。

#ACP storage operator

acp-storage-operator 是 ACP 特定的 operator，负责调和 CephCluster 资源并管理围绕操作、监控和故障排除的内置 ACP 存储集成。

#组件

acp-storage-operator 管理以下内置集成组件：

• 用于 CephCluster 的 Ceph 调和控制器。
• 两个 MutatingWebhookConfiguration 条目：
  • 一个用于 CephCluster
  • 一个用于 CephFilesystem

#设计图

acp-storage-operator 作为 ACP 中的控制平面 operator 运行，扩展 Ceph 集群生命周期，提供 ACP 原生的监控和运维资源。

#职责

acp-storage-operator 执行以下职责：

• 监听并调和 CephCluster 资源。
• 通过变更 webhook 在创建时变更 CephCluster 和 CephFilesystem 对象。
• 在变更过程中初始化 ACP 特定默认值，包括 resources、placement 和相关运行时设置。
• 创建内置的 .mgr 池以支持 ACP 所需的 Ceph 管理器功能。
• 创建并维护 ACP 内置的 AlertRule 资源。
• 创建并维护 ACP 内置的 MonitorDashboard 资源。
• 自动启用并维护 rook-ceph-tools Pod。

#资源

acp-storage-operator 为每个调和的 CephCluster 创建并管理以下资源：

• 内置 Ceph .mgr 池。
• ACP 内置的 AlertRule 对象。
• ACP 内置的 MonitorDashboard 对象。
• rook-ceph-tools Pod 及其相关运行时资源。

#生命周期

acp-storage-operator 在内部模式下遵循以下生命周期：

1. 引导阶段：operator 部署启动，注册 CephCluster 和 CephFilesystem 的控制器及变更准入 webhook。
2. 准入阶段：在创建请求时，webhook 注入 ACP 默认值（如 resources 和 placement），然后对象被持久化。
3. 调和阶段：CephCluster 可用后，operator 持续调和 ACP 内置资源，包括 .mgr 池、AlertRule、MonitorDashboard 和 rook-ceph-tools Pod。
4. 清理阶段：当 CephCluster 被删除时，operator 移除其为该集群创建的所有 ACP 管理资源。

#第4章：安装概览

本章描述内部模式和外部模式的安装流程。

#Operator 安装

• OLM 安装 acp-storage-operator 以支持 ACP 内置存储集成。
• OLM 从其包中安装 rook-ceph-operator 并创建 operator 部署。
• 部署包含调和 CephCluster 和 Ceph 相关资源所需的控制组件。
• acp-storage-operator 注册 CephCluster 和 CephFilesystem 对象的变更准入 webhook。
• 启动后，operator 开始监听 CRD 并准备存储消费所需的 CSI 组件。

#Ceph 集群创建概览

• 管理员创建 CephCluster 自定义资源。
• operator 使用该声明协调 Ceph 相关资源和 CSI 服务。
• 在内部模式下，acp-storage-operator 还调和围绕同一 CephCluster 的 ACP 内置存储资源。
• 具体调和路径根据部署模式不同而异：内部模式或外部模式。

#CephCluster 创建

#内部模式

在内部模式下，存储守护进程运行在创建 CephCluster 的 ACP 集群内。

1. operator 接收存储命名空间中的 CephCluster。
2. acp-storage-operator 变更 webhook 初始化 CephCluster 和 CephFilesystem 资源的 ACP 默认值（如 resources 和 placement）。
3. rook-ceph-operator 引导监视器仲裁并创建管理守护进程。
4. OSD 准备作业发现配置的设备，然后创建 OSD 部署。
5. 部署 Ceph CSI provisioner 和节点插件 Pod，用于 RBD 和 CephFS。
6. acp-storage-operator 调和 ACP 内置资源，包括 .mgr 池、内置 AlertRule、内置 MonitorDashboard 和 rook-ceph-tools Pod。
7. StorageClass 对象可用于通过 PVC 工作流动态配置。
8. 通过 CephCluster 状态持续报告集群健康和就绪状态。

#外部模式

在外部模式下，Ceph 数据平面运行在外部提供者集群，而 ACP 托管消费者侧控制集成。

1. operator 在消费者 ACP 集群中安装并调和 CSI 组件。
2. 导入外部 Ceph 连接数据（如监视器端点、集群标识符和客户端密钥）。
3. 以外部模式（external: true）调和 CephCluster，表示远程 Ceph 后端。
4. 消费者集群中不创建本地监视器或 OSD 守护进程。
5. RBD 和 CephFS CSI 驱动使用导入的连接信息从外部 Ceph 集群配置和挂载卷。
6. 从消费者侧组件和外部连通性检查调和状态和健康。

#第5章：升级概览

Alauda Build of Rook-Ceph 通过 Subscription、InstallPlan 和 ClusterServiceVersion (CSV) 资源遵循 OLM 管理的升级工作流。

当当前频道出现新版本包时，OLM 创建 InstallPlan，执行取决于自动或手动批准策略。

InstallPlan 批准后，OLM 执行 CSV 调和：

• 安装新 CSV。
• 更新 operator Deployment 到新镜像并重启。
• 成功过渡检查后替换旧 CSV。

随后 operator 级调和完成升级：

• operators 验证并重新应用用户面 CR 的期望状态。
• 检查 Ceph 和 CSI 资源的版本一致配置。
• 纠正漂移，直到集群状态报告健康且收敛。