上一篇我们从架构和部署角度，讲了如何入门 Ceph。
这篇我们不再展开底层原理，而是站在“应用”和“落地”的角度，看看 Ceph 在实际工作中到底能做什么、分别适合哪些场景、如何避免常见踩坑。

整体可以把 Ceph 的应用分成三大类：

• 对象存储（RGW）：海量非结构化数据，如备份、日志、图片、音视频
• 块存储（RBD）：虚拟机云硬盘、数据库磁盘、容器持久卷
• 分布式文件系统（CephFS）：研发共享目录、大数据分析、模型与工程产物存储

1. 对象存储（RGW）：海量数据的“底座”

1.1 典型应用场景

• 备份与归档
  • 业务数据库定期冷备
  • 日志长期归档（7 天在线 + 若干月/年的冷存储）
  • 各类文档、报表、导出文件的集中保存
• 图片、音视频等静态资源存储
  • Web / App 的用户上传图片、头像、附件
  • 点播/直播平台的源视频、转码文件
• 大数据 / 日志平台的底层存储
  • ELK / Loki / ClickHouse 等日志、指标、埋点数据的冷热分层存储

在这些场景里，Ceph 的 RGW 通常扮演一个兼容 S3 接口的对象存储服务：

• 应用不需要感知 Ceph 的内部结构，只需要使用 S3 SDK/HTTP 接口读写对象
• 后端通过多副本或纠删码保证可靠性和成本平衡

1.2 和其他对象存储的比较

• 和公有云对象存储（如 OSS / COS / S3）相比：
  • 优势：可自建在机房或私有云内部，避免数据外流，成本可控；支持深度自定义
  • 劣势：需要自己维护运维团队，负责扩容、监控、容灾
• 和单机 MinIO / FastDFS 等组件相比：
  • 优势：天然分布式、自动重平衡、成熟的 CRUSH 算法
  • 劣势：整体系统复杂度更高，对运维能力要求更高

1.3 应用最佳实践（对象存储）

• 按业务或环境划分 Bucket
  • 按业务线：biz-a-logs、biz-b-assets
  • 按环境：prod-logs、stage-logs
• 生命周期管理（Lifecycle）
  • 热数据短期保留在高性能存储
  • 冷数据自动转低成本池/冷归档，降低成本
• 访问控制
  • 为不同业务/服务账号分配独立 AK/SK
  • 使用 Bucket Policy 或 IAM 控制读写权限
• 结合 CDN 使用
  • 对外提供图片/视频服务时，用 CDN 加速访问
  • Ceph RGW 只做“源站”和持久存储

2. 块存储（RBD）：云主机和容器的“硬盘”

2.1 典型应用场景

• 虚拟机云硬盘
  • OpenStack / oVirt /自研云平台，把 RBD 当作虚拟机系统盘、数据盘
• 数据库存储
  • MySQL、PostgreSQL、MongoDB 等，部署在虚拟机上，底层磁盘用 RBD
• Kubernetes 容器持久卷（PVC）
  • 通过 Ceph CSI 插件，为 Pod 提供动态创建的持久卷（RBD PVC）

在这些场景中，RBD 的角色就像“分布式云硬盘”：

• 支持快照、克隆、回滚
• 底层通过多副本或纠删码保证数据安全

2.2 RBD 在虚拟化中的应用示例

• 虚拟化平台（如 OpenStack Cinder）配置后端为 Ceph RBD：
  • 创建虚拟机时自动创建对应 RBD 镜像
  • 删除虚拟机时自动删除对应镜像
  • 支持在线扩容、快照备份等

这类场景非常适合企业私有云 / 内部 IaaS 平台：

• 统一由 Ceph 提供可靠存储
• 计算节点只负责 CPU/内存，存储弹性由 Ceph 集群保障

2.3 RBD 在 Kubernetes 中的应用

在 Kubernetes 中常见的应用方式：

• 部署 Ceph CSI 插件
• 在集群中创建 StorageClass，后端指向 Ceph RBD
• 应用通过 PVC 申请存储，即可获得一个独立的 RBD 卷

适合场景包括：

• 有状态服务：MySQL、Redis、Kafka、ElasticSearch 等
• 自建中间件平台：数据库即服务（DBaaS）等

2.4 应用最佳实践（块存储）

• 数据库类工作负载
  • 优先使用 SSD OSD 或为 WAL/DB 单独分配 SSD
  • 选用合适的副本数或纠删码策略，平衡性能与成本
  • 结合业务 RPO/RTO 设计快照与备份方案
• 虚拟桌面 / 通用虚拟机
  • 使用配额和限速（QoS）避免单个 VM 把存储打爆
  • 通过镜像模板 + 克隆提升创建速度
• Kubernetes 场景
  • 对延迟敏感的服务尽量靠近存储节点部署（同机架/同可用区）
  • 使用 PodAntiAffinity + Ceph 多副本，保证真正跨物理节点高可用

3. CephFS：研发&大数据的“共享盘”

3.1 典型应用场景

• 研发共享目录
  • 代码仓库镜像存储、构建产物缓存
  • 团队共享文档、测试数据集
• 大数据分析 / AI 训练
  • 存放训练数据集、模型文件、实验结果
  • 多台计算节点同时读取同一批数据
• CI/CD 构建缓存
  • CI 集群的构建缓存、依赖包缓存等，提高构建效率

CephFS 提供 POSIX 语义，对上层应用来说就像一个“分布式 NFS / NAS”：

• 文件、目录、权限等操作基本和本地文件系统一致
• 多客户端同时挂载，适合多节点访问同一数据集

3.2 与 NFS、HDFS 等的对比

• 和 NFS / 传统 NAS 相比：
  • 优势：易于水平扩展，底层由 Ceph 集群支撑，多副本高可靠
  • 劣势：部署和运维复杂度更高
• 和 HDFS 相比：
  • 优势：POSIX 语义更完整，适合通用应用，不仅限于大数据框架
  • 劣势：在纯大数据批处理场景中，HDFS 与 Hadoop 生态结合更紧密

3.3 应用最佳实践（CephFS）

• 控制元数据压力
  • 尽量避免单目录下千万级小文件
  • 合理规划目录结构，按日期/业务/项目分级
• 合理使用权限
  • 使用 POSIX 权限 + ACL 控制多团队访问
  • 对敏感数据做额外加密或访问控制
• 配合备份与版本管理
  • 对重要目录定期快照
  • 在 CephFS 之上加一层版本管理逻辑（如每日归档目录）

4. 不同业务场景下如何选择：对象、块、文件？

可以用一个简单的决策思路来判断：

• 优先选对象存储（RGW） 的场景：
  • 写多读多、文件大小差异大、长期存放的数据：备份、日志、图片、音视频
  • 需要通过 HTTP / S3 接口直接访问的数据
• 优先选块存储（RBD） 的场景：
  • 需要一个“虚拟硬盘”的场景：虚拟机系统盘、数据库磁盘、容器持久卷
  • 业务期望看到的是 块设备 而不是文件或对象
• 优先选文件系统（CephFS） 的场景：
  • 多节点共享读写同一目录：研发共享盘、大数据/AI 训练数据
  • 需要 POSIX 语义、路径/目录/文件操作的传统应用

简化一句话：

• 应用 + HTTP + 海量文件 → RGW（对象）
• 虚拟机 / 容器磁盘 → RBD（块）
• 多机共享文件目录 → CephFS（文件）

5. Ceph 在典型企业架构中的几种落地模式

下面给出几种常见的企业落地组合方案，你可以对照自己的现状考虑：

5.1 私有云 / 混合云：统一存储底座

• 计算层：KVM / OpenStack / Kubernetes
• 存储层：统一使用 Ceph
  • 虚拟机磁盘：RBD
  • 容器持久卷：RBD（或 CephFS，根据场景）
  • 备份与归档：RGW 对象存储

优点：

• 一套存储系统服务多个计算平台
• 存储运维团队集中，统一监控和扩容

5.2 日志与监控平台：冷热分层存储

• 热数据：近几天的日志放在 ES / Loki 等系统使用的高性能存储（可以是 SSD OSD 池）
• 冷数据：历史日志（>30 天）通过任务离线转存到 RGW 对象存储

好处：

• 保证近端查询性能
• 通过 Ceph 的大容量对象存储，显著降低长期存储成本

5.3 AI / 大数据平台：训练数据与模型仓库

• 使用 CephFS：
  • 存放训练数据集和中间结果
  • 多个训练节点并行读取同一数据集
• 使用 RGW：
  • 存放归档后的历史数据、训练日志、模型版本包

可以实现：

• 在线训练 + 离线归档 的整体数据生命周期管理

6. 运维与 SRE 视角下的注意事项

6.1 容量与性能规划

• 不要低估日志和备份对存储的消耗
  • 提前规划对象存储池、生命周期策略
  • 定期清理无效数据和过期备份
• 对高性能负载（如数据库/消息队列）
  • 预留足够的 SSD 资源
  • 监控延迟和 IOPS，必要时做池分离（热池/冷池）

6.2 监控与告警

重点关注：

• ceph status 健康状态（HEALTH_WARN / ERR）
• OSD 使用率（避免单盘 90%+）
• PG 状态：active+clean 以外的状态要及时排查
• 对象网关的请求量、错误率、延迟

结合：

• Prometheus + Grafana
• Ceph Dashboard

建立一套可视化面板，让“容量/性能/故障”一眼可见。

6.3 变更与扩容策略

• 扩容尽量 小步快跑：一次加少量 OSD，观察重平衡情况
• 高峰时段避免做大规模数据迁移和 OSD 重权重调整
• 在生产上做任何操作前，先在测试集群演练：
  • OSD 下线 / 换盘
  • 扩容新 OSD、新节点
  • Pool 参数调整（副本数、纠删码策略）

7. 小结：把 Ceph 真正用起来

从“入门”到“应用”，可以总结为三步：

1. 理解能力边界：知道 Ceph 在对象、块、文件三个维度分别能做什么
2. 对号入座场景：根据业务特点匹配 RGW / RBD / CephFS 的最佳组合
3. 做好运维与 SRE 保障：容量规划、监控告警、变更流程、故障预案

当你能在实际项目中自如地回答这几个问题时，说明你已经真正掌握了 Ceph 的应用：

• 这个业务的数据应该放在 对象 / 块 / 文件 哪一类上？为什么？
• 这次扩容会对线上产生什么影响？如何控制风险？
• 当前集群健康状态是否支撑“再上一个新业务”？瓶颈在哪里？

如果你愿意，下一篇我们可以写一篇 《Ceph 生产环境部署与运维实战》，专门结合你实际的硬件条件和业务类型，给出一套更贴近你环境的部署与运维方案。