#架构

#第 1 章：简介

Alauda Storage 是 Alauda Container Platform (ACP) 的云原生存储层。它以 Kubernetes 原生系统的形式运行，并通过 operator、自定义资源和 CSI 驱动程序提供持久化存储服务。

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

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

Alauda Storage 集成了以下核心开源项目：

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

#第 2 章：架构概述

从较高层次来看，Alauda Storage 完全运行在 Alauda Container Platform 内部。

Alauda Storage 架构

Alauda Storage 使用故障域配置来确定数据副本在集群中的分布方式。故障域表示一个物理边界，例如主机、机架或可用区，数据副本会分布在该边界内以确保高可用性。Alauda Storage 根据分配给存储节点的标签自动识别这些故障域。

#第 3 章：Operators

Alauda Storage 由以下两个 Operator Lifecycle Manager (OLM) operator bundle 组成，其中部署的 operator 会将管理任务和自定义资源编码为规范，以便轻松实现任务和资源特征的自动化：

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

管理员定义集群的期望最终状态，operator 则确保集群达到或趋近该状态，同时尽量减少管理员的干预。

#Rook-Ceph operator

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

rook-ceph-operator 容器会自动引导存储集群，并监控存储守护进程以维护集群运行状况。

#组件

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

• Mons：Ceph 监视器（mons）负责维护集群元数据和仲裁。
• OSDs：对象存储守护进程（OSDs）负责存储和复制数据。
• Mgr：Ceph manager（mgr）提供指标和内部管理功能。
• RGW：RADOS Gateway（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 配置；为了简化运维模式，placement group 和 CRUSH map 等高级 Ceph 结构仍保持抽象。

#资源

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

operator 会监视并协调以下自定义资源：

• CephCluster
• CephObjectStore
• CephFilesystem
• CephBlockPool

#生命周期

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

• Rook operator：
  • 一个 operator pod。
• RBD CSI Driver：
  • 一个 deployment 管理两个 provisioner pod。
  • 一个 DaemonSet 管理每个节点上的一个 plugin pod。
• CephFS CSI Driver：
  • 一个 deployment 管理两个 provisioner pod。
  • 一个 DaemonSet 管理每个节点上的一个 plugin pod。
• 监视器（mons）：
  • 三个监视器 pod，每个 pod 都有自己的 deployment。
  • 在 Ceph 拉伸集群模式下，共有五个监视器 pod：仲裁区一个，每个数据区两个。
• Manager（mgr）：
  • 标准 deployment 中有两个 manager pod。
• 对象存储守护进程（OSDs）：
  • 初始创建至少三个 OSD。
  • 随着集群容量扩展，会添加更多 OSD。
• 元数据服务器（MDS）：
  • 两个元数据服务器 pod。
• RADOS Gateway（RGW）：
  • 至少两个 gateway pod。

#ACP storage operator

acp-storage-operator 是 ACP 专用 operator，负责协调 CephCluster 资源，并管理 ACP 内置的存储集成，涵盖运维、监控和故障排除。

#组件

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

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

#设计图

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

#职责

acp-storage-operator 负责执行以下操作：

• 监视并协调 CephCluster 资源。
• 通过变更型 webhook 在创建时修改 CephCluster 和 CephFilesystem 对象。
• 在变更过程中初始化 ACP 专用默认值，包括 resources、placement 和相关运行时设置。
• 创建 ACP 所需 Ceph manager 功能的内置 .mgr 池。
• 创建并维护 ACP 内置的 AlertRule 资源。
• 创建并维护 ACP 内置的 MonitorDashboard 资源。
• 自动启用并维护 rook-ceph-tools pod。

#资源

对于每个协调的 CephCluster，acp-storage-operator 都会创建和管理以下资源：

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

#生命周期

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

1. 引导阶段：operator deployment 启动，并为 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 内置存储集成安装 acp-storage-operator。
• OLM 从其软件包安装 rook-ceph-operator，并创建 operator deployment。
• 该 deployment 包含协调 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 引导 monitor 仲裁组并创建 manager 守护进程。
4. OSD 准备作业发现已配置的设备，然后创建 OSD deployment。
5. 为 RBD 和 CephFS 部署 Ceph CSI provisioner 和节点插件 pod。
6. acp-storage-operator 协调 ACP 内置资源，包括 .mgr 池、内置 AlertRule、内置 MonitorDashboard 和 rook-ceph-tools pod。
7. StorageClass 对象可通过 PVC 工作流用于动态置备。
8. 集群运行状况和就绪状态会通过 CephCluster 状态持续报告。

#外部模式

在外部模式下，Ceph 数据平面运行在外部 provider 集群中，而 ACP 承载使用方的控制集成。

1. operator 在使用方 ACP 集群中安装并协调 CSI 组件。
2. 导入外部 Ceph 连接数据（例如 monitor 端点、集群标识符和客户端 secret）。
3. 在外部模式下协调 CephCluster（external: true），以表示远程 Ceph 后端。
4. 不会在使用方集群中创建本地 monitor 或 OSD 守护进程。
5. RBD 和 CephFS CSI 驱动程序使用导入的连接信息，从外部 Ceph 集群置备并挂载卷。
6. 根据使用方组件和外部连接检查的结果协调状态和运行状况。

#第 5 章：升级概述

Alauda Storage 通过 Subscription、InstallPlan 和 ClusterServiceVersion（CSV）资源遵循由 OLM 管理的升级工作流。有关受支持的 operator 与数据平面升级操作步骤，请参阅升级。

当前 channel 中出现新 bundle 后，OLM 会创建一个 InstallPlan，其执行取决于自动或手动批准策略。

在批准 InstallPlan 后，OLM 执行 CSV 协调：

• 安装新的 CSV。
• 将 operator Deployment 更新为新镜像并重启。
• 成功完成转换检查后，替换旧 CSV。

安装的 CSV 变为 Succeeded 后，平台会将唯一的 CSV relatedImages 条目写入内部 CephCluster.spec.cephVersion.image，其 name 为 ceph。如果该镜像已经是正在运行的值，则不会滚动更新 Ceph 守护进程。外部模式集群不会接收本地 Ceph 镜像写入。

随后，operator 级别的协调会完成剩余配置：

• Operator 验证并重新应用来自面向用户的 CR 的期望状态。
• 检查 Ceph 和 CSI 资源，确保其配置与版本一致。
• 持续纠正偏差，直到集群状态报告运行正常且已收敛。

Ceph 是 Red Hat, Inc. 或其子公司在美国及其他国家/地区的商标或注册商标。 Rook® 是 The Linux Foundation 的注册商标。 Alauda 是一家独立的供应商。本产品与 LF Projects, LLC 或 The Linux Foundation 没有任何关联，也未获得其认可或赞助。所有商标均归其各自所有者所有，此处仅用于标识目的。