RBD、CephFS 与 RGW¶

选择依据¶

应用需要一块磁盘，由单个节点格式化和挂载？ → RBD
应用需要多个节点共享目录和 POSIX 文件语义？ → CephFS
应用通过 HTTP/S3 保存对象，不依赖本地文件路径？ → RGW

不能仅因为三种服务来自同一个 Ceph 集群就混用同一个 Pool。每种服务会创建或使用不同的数据与元数据结构，应按官方方式初始化 Pool 并设置应用类型。

RBD Image 对客户端表现为块设备，底层被切分为多个 RADOS Object。它常用于虚拟机系统盘、数据库数据盘以及 Kubernetes 持久卷。

ceph osd pool create rbd-pool
rbd pool init rbd-pool
rbd create rbd-pool/demo --size 20G
rbd info rbd-pool/demo
rbd ls rbd-pool

客户端可通过内核 RBD、librbd、QEMU/libvirt 或 CSI 使用 Image。生产环境应为平台创建最小权限的 CephX 用户，而不是分发 client.admin。

rbd snap create rbd-pool/demo@snap-01
rbd snap ls rbd-pool/demo
rbd du rbd-pool/demo

RBD 快照通常是崩溃一致性。数据库或应用需要先冻结 IO、执行 Flush，或由备份系统协调应用一致性。快照仍依赖原 Ceph 集群，不是独立备份。

克隆镜像可能依赖父快照。删除基础镜像前要检查子镜像依赖；flatten 可解除依赖，但会复制数据并增加容量与 IO。

CephFS 为客户端提供共享的 POSIX 文件系统：文件数据保存在 Data Pool，目录、inode 等元数据保存在 Metadata Pool，并由 MDS 提供元数据服务。

CephFS Client
   ├── 向 MDS 查询目录和元数据
   └── 直接向 OSD 读写文件数据

一个 CephFS 至少需要 Metadata Pool 和 Data Pool。Metadata Pool 丢失可能导致整个文件系统不可访问，因此应使用高可靠副本和低延迟设备，不使用纠删码池保存 CephFS 元数据。

ceph fs volume create cephfs
ceph fs status
ceph mds stat

默认单 Active MDS 已能提供高可用，配合 Standby 在故障时接管。多个 Active MDS 主要用于扩展高并发元数据负载，并不会让单客户端或单目录工作负载自动获得线性性能提升。

CephFS 适用于共享文件和 Kubernetes RWX，但海量小文件、目录热点、频繁 Rename 和大量客户端场景必须针对 MDS 缓存、Metadata Pool 延迟和目录布局进行压力测试。

RGW 提供与 Amazon S3 基本数据模型兼容的 REST API。应用通过 Access Key、Secret Key、Bucket 和 Object 访问数据，不需要挂载文件系统。

S3 Client
    ↓ HTTPS / Load Balancer
多个 RGW 实例
    ↓
RGW Metadata/Data Pools
    ↓
RADOS / OSD

生产入口通常部署多个 RGW，再通过负载均衡和 TLS 域名提供服务。网关扩容主要增加 API 处理能力，底层容量和数据可靠性仍由 OSD、Pool 和 CRUSH 决定。

对象存储适合不可变或以完整对象读写的数据。应用若依赖文件锁、随机修改文件中间字节、目录 Rename 或 POSIX 权限，不应直接把 RGW 当共享文件系统使用。

多站点 RGW 使用独立 Ceph 集群与 Zone 进行同步，可用于跨站点容灾。跨地域直接拉伸单个 Ceph 存储集群通常受网络时延和故障域影响，应优先评估 RGW Multisite 或应用级复制。

平台	常见集成
OpenNebula / PVE	使用 RBD 保存虚拟机磁盘，通过 CephX 控制访问
Kubernetes	RBD CSI 提供 RWO 卷；CephFS CSI 提供共享 RWX 卷
备份和归档系统	通过 RGW S3 API 写入对象
Linux 服务器	映射 RBD 或挂载 CephFS，按客户端身份授权

集成前要明确谁负责创建和删除卷、快照保留周期、密钥轮换、Pool 配额、故障时重连行为以及平台删除资源是否同时删除底层数据。