【Ceph RADOS】对照替代路径：MinIO、云块存储与本机 NVMe+SPDK

前 16 篇把 Ceph RADOS 内核拆到可排障的精度：OSD Op 路径、BlueStore 读写分配、recovery/backfill 与 RBD/CephFS/RGW 接入税。接下来的问题是：什么时候这些内核机制的代价不值得付，对象存储只需要 S3 语义、块存储选托管磁盘、或者本机 NVMe 根本不需要分布式这一层。

本文不做延迟排行榜——跨方案延迟比较需要固定的负载模型、硬件代际与副本策略，单个数字比较是口径欺骗。本文从机制分歧出发：每条对照路径赢在哪个前提，假设不成立时代价是什么。

本文是「Ceph / RADOS 存储内核」系列第 17 篇（共 18 篇）。→ 系列目录

篇目	核心内容
第 16 篇 · 排障坐标系	slow ops、peering、满盘、恢复拖死、checksum
第 17 篇 · 对照替代路径	MinIO / 云块 / 本机 NVMe+SPDK
第 18 篇 · 选型收束	排除树；Crimson、Tentacle、Rook/CSI 续作

版本锚定：机制结论基于 Ceph Squid v19.2.5；MinIO 对应其当前 AGPL 版本主线；云块存储以 AWS EBS/GCP PD 为参照（不代表所有厂商实现）；SPDK 对应 v26.01。

一、对照维度的确定

三条替代路径与 Ceph 的分歧不在「功能更多/更少」，而在以下四个维度的取舍：

二、对照 MinIO

MinIO 的选型前提

MinIO 是一个以 S3 兼容接口为核心设计的对象存储，Go 语言实现，用纠删码（Reed-Solomon，默认 EC:4+4 或 EC:8+8）提供 durability，没有元数据 DB 外部依赖（早期有 etcd 依赖，后来已内化）。

MinIO 赢在的前提： - 纯 S3 API 场景：不需要 POSIX（CephFS 代价），不需要块设备（RBD COW 税），只需要 PUT/GET/DELETE/LIST 与 multipart。 - 运维简单性：单二进制（minio server），配置通过环境变量管理，无 MON/MGR/OSD 多角色协作，无 CRUSH map，无 peering 协议。对中小规模（数十个节点以下）对象存储需求，运维门槛远低于 Ceph。 - LIST 性能：MinIO 的 bucket 元数据本地化（无跨 RADOS 的 OMAP 路径），LIST 延迟在小对象高频列举场景优于 Ceph RGW 的多 shard 合并模型。

Ceph RGW 赢在的前提： - 已有 Ceph 集群：RBD + CephFS + RGW 共用同一个 RADOS 集群，减少了独立部署与运维 MinIO 的成本。 - 多站点一致性模型已被接受：Ceph RGW 的 multi-site bi-log 同步与 MinIO 的全局多站点复制（MinIO Replication）机制相近，但 Ceph 在与其他接口层（RBD/CephFS）的统一运维上有优势。 - 超大规模：Ceph RGW 在 PB 级集群下的 bucket index sharding 与 dynamic resharding 成熟度，经生产验证的记录更长。

争论点：MinIO 社区主张「S3 兼容的存储不需要也不应该用 Ceph 的复杂性」，Ceph 社区的回应是「多接口统一的运维价值在 PB 以上规模才体现」。这两个立场都有合理的前提假设，并非一个普遍正确。对一个只运行 S3 工作负载、规模 < 100 TB 的团队，MinIO 的运维成本优势是真实的。

三、对照云块存储

云托管块的选型前提

云块存储（AWS EBS、GCP Persistent Disk 等）是 IaaS 层提供的托管块设备，以 API 附加到虚机，durability 和可用性由云服务商 SLA 保证，用户无需维护任何存储集群。

云块存储赢在的前提： - 零存储运维：不需要 Ceph 集群规划、CRUSH map 调整、OSD 故障处理、版本升级。在人力成本上，对于没有专职存储工程师的团队，这是硬条件。 - 弹性：存储容量可在线扩展，IOPS/带宽档位可按需调整（对应 EBS io2 IOPS provisioning 等），不需要提前规划 OSD 容量与 PG 数。 - 延迟可预测：云块存储的 P99 延迟由服务商管理，虽然高于本机 NVMe，但其波动由 SLA 约束，不会因 recovery/backfill 抖动（Ceph 的典型问题）。

Ceph 赢在的前提： - 私有化 / 混合云：不依赖特定云厂商，可运行在自有数据中心，数据主权清晰。 - 大规模统一：在数千台物理服务器的私有云中，Ceph 的 CRUSH map 可以感知机架/机房/AZ 拓扑，统一提供块/文件/对象三种接口，而云块存储是厂商服务，不可二次定制。 - 成本：超过一定规模（PB 级持久化数据）时，自建 Ceph 的 TCO 低于按量付费云块存储（前提是有运维能力）。这是弹性伸缩成本与规模固定成本的权衡，不同团队的 breakeven point 不同。

延迟对比的口径问题：自建 Ceph SSD 集群的 commit latency（ceph osd perf 的值）与 EBS io2 的 P99 延迟不能直接比较——前者是 OSD 层延迟（不含客户端网络），后者是端到端延迟（含存储网络）。若需要对比，至少要在同一测试框架下测量「应用侧感知延迟」，区分尾延迟（P99/P999）与均值。

四、对照本机 NVMe + SPDK

本机 NVMe 的选型前提

本机 NVMe（不经网络，直连服务器本地 PCIe）是存储延迟的绝对下限：没有网络往返，没有 RADOS op 路径，没有副本写。加上 SPDK 用户态存储栈（绕过内核块层，用户态轮询驱动），可以把 RADOS op 路径中每一跳的延迟都消掉。

SPDK 系列第 16 篇选型收束 给出了 SPDK 的排除树：必须付得起专用轮询核、设备独占、RPC 库存纪律。本节聚焦 Ceph 视角：何时「本机 NVMe（含 SPDK）」是对 Ceph RBD 的有效替代，何时不是。

本机 NVMe 赢在的前提： - 延迟敏感型数据库（OLTP 主库、交易系统）：P999 延迟需要 < 1ms 的场景，Ceph RBD 的 commit latency（含副本网络 RTT，典型 SSD 集群 1–10ms）超过预算。 - 计算与存储共置（超融合 with ephemeral data）：数据不需要跨节点持久化（日志暂存、中间计算结果），或应用层已做了分片 + 主动复制（如 Cassandra、TiKV），不需要存储层额外副本。 - 已选 SPDK 作为数据面：若服务已基于 SPDK NVMe-oF 构建存储目标端（如定制化 NVMe-oF disaggregation），引入 Ceph RADOS 层反而增加了一层不必要的间接性。

Ceph RBD 赢在的前提： - 数据需要跨节点冗余：应用不自带复制语义（传统数据库单节点、虚机磁盘），需要存储层保证 durability。本机 NVMe 宕机即数据丢失（除非应用层管理副本）。 - 快照、克隆、远程迁移：RBD image 的快照 COW、跨集群 mirror，是本机 NVMe 在应用层很难等价实现的功能。 - 资源池化：多台虚机共享 Ceph 存储池，允许 overcommit 与动态分配；本机 NVMe 是固定容量，利用率受宿主机绑定。

SPDK 开放问题的回收（§4.3 → 可检验实验）

SPDK 系列第 16 篇 §4.3 留下一句边界题：

若 OSD 数据面采用用户态 NVMe 轮询，故障域与 Ceph 恢复/回填线程的 CPU 隔离如何声明？

本系列在 Squid ClassicOSD + BlueStore 主线上的具体化如下。

工程现状（Squid v19.2.5）：

• 默认 OSD 走内核块设备；SPDK 作 BlueStore BlockDevice 后端不是主流发行配置。
• Crimson（第 18 篇）用 SeaStar reactor，文档要求配置 crimson_cpu_num / 可选 crimson_cpu_set；若仍挂 BlueStore，还需 crimson_bluestore_num_threads 与 互斥 的 crimson_bluestore_cpu_set——这是官方已经写出的「隔离声明」雏形，但仍属 tech preview，不能当生产 runbook。
• ClassicOSD 的 recovery/backfill 线程走 Linux CFS；与同机 SPDK reactor（isolcpus + 轮询核）共置时，没有 Ceph 官方「一键声明故障域」的配置面。

可检验实验（关闭条件必须是测量，不是口号）：

仍开放的判定句：在 ClassicOSD 路径上，即使 numactl+isolcpus 做对，recovery 相关 softirq / 内核块层是否仍会污染 \(C_r\)？若步骤 2–3 失败，排除树上「本机 NVMe+SPDK 与 Ceph OSD 共置」应判负，直到 Crimson 全 SeaStar 路径把恢复也内化进 reactor 模型（Tentacle+ 跟踪，非 Squid 承诺）。

五、机制差异对照表（分歧点，非功能清单）

表后判决：四条路径赢在不同不变量。Ceph 赢在跨节点冗余、多接口与可命名失败；MinIO 赢在纯对象接口且元数据不经 RADOS 对象映射表；云块赢在把 peering、满盘与恢复从值班手册里删掉；用户态本地盘栈赢在删掉网络与 RADOS 税。用同一张每秒输入输出次数榜替代表格，是口径欺骗。

六、什么时候不应该用 Ceph

排除树的反向视角（机制判据，不是品牌偏好）：

1. 少于 3 个故障域：副本/quorum 假设不成立，复杂度税无回报。
2. P99 低于 1ms 硬 SLO：副本 RTT + WAL 路径通常越界；只剩本机 NVMe/SPDK。
3. 无存储排障编制：付不起第 16 篇五轴。
4. 公有云上用云盘做 OSD 底层：云块延迟 + RADOS 税叠两层，且运维全自担——典型反模式。
5. 纯 S3、中小规模、要 LIST 简单：MinIO 的元数据路径更短（见上表）。

七、谱系、争论与开放问题

谱系：Weil et al. OSDI 2006 / PDSW 2007 把「客户端算放置 + OSD 自治」钉成 Ceph 主线；对象/块/文件适配层（RGW/RBD/CephFS）是同一 RADOS 上的不同税。MinIO 走「S3-first、元数据不经分布式对象映射表」另一格；云块把一致性与恢复收进厂商 SLA；SPDK 删掉跨节点层。四条路径不是同一问题的四个品牌答案。

争论：自建 Ceph「功能全」是否总优于拆分（块用云盘、对象用 MinIO、热数据用本机 SPDK）？
A 侧：统一故障方言与一套 CRUSH 编制，降低接口碎片。
B 侧：统一意味着每条路径都付 RADOS 税；接口异构时总账更贵。
裁决必须走排除树（第 18 篇），禁止用未标定的延迟榜代替机制判据。

开放问题：第 4 节 CPU 隔离四步实验是否在本编制下可复现；若不可复现，共置判负应写进 ADR，而不是口头「调优一下」。

参考资料

站内对照

• MinIO（storage/48） — MinIO 对象存储机制详解
• 云块存储（storage/70） — 云托管块存储设计与 SLA
• SPDK 用户态存储栈（spdk/index） — SPDK 全系列入口
• SPDK 选型收束（spdk/16） — SPDK 排除树与开放问题（含 Ceph OSD 边界）
• Ceph 与 CRUSH（distributed/38） — Ceph 工程概览（科普向）

官方文档 / 论文（A）

• Ceph Squid — Architecture / RBD / RADOS Gateway（docs.ceph.com/en/squid/）
• Weil, S. A. et al. (2006). Ceph: A Scalable, High-Performance Distributed File System. OSDI ’06
• Weil, S. A. et al. (2007). RADOS. PDSW ’07
• MinIO — Architecture documentation

→ 上一篇：排障坐标系 · 系列目录 · 下一篇：选型收束