【Ceph RADOS】选型收束：排除树、Crimson 边界与系列开放问题
内容提要
本文为Ceph RADOS系列终章，聚焦选型收束：通过排除树机制判据（如跨节点冗余、P99延迟、接口语义）指导决策，明确Crimson在Squid v19.2.5仅为技术预览、不可生产，Tentacle+特性需标注版本边界，并划清Rook/CSI编排续作分工，提出可证伪的开放问题（如混跑、CPU隔离），强调先排除、再实验、再迁移的纪律。
延伸解读
排除树：把选型从“看场景”变成可证伪判断
本文提出的排除树以机制问题为节点，每个分支都指向可观察的判据，如跨节点冗余需求、P99延迟、接口语义等。这种结构避免了“各有优劣看场景”的模糊结论，让选型决策可追溯、可复盘。例如，若数据无需跨节点冗余且P99要求低于约1ms，则直接排除Ceph，转向本机NVMe或云块。这种先排除再选择的思路，有助于在架构决策记录中明确否证条件，避免口头惯性。
Crimson 在 Squid 的边界：技术预览，不可生产
文章明确Crimson OSD在Squid v19.2.5仅为技术预览，需显式实验旗标才能启动，不适合生产环境。其工作负载支持有限，EC、RGW、mClock等仍在WIP，且BlueStore路径需单独配置CPU集。读者应避免将Crimson的预览特性写入生产决策，并注意其排障坐标系与Classic不同，混用假设会导致误判。
Tentacle+ 标签：隔离未稳定特性，避免误用
对于Tentacle（20.x）版本中未进入Squid稳定承诺的特性，文章要求一律标注“Tentacle+”，并指向正式发布说明作为关闭条件。这包括Crimson/SeaStore、RGW active-active强一致、CephFS bal等。这种标签纪律防止将预览特性当作生产可用，确保决策记录中的版本边界清晰，避免因未标注版本而导致的误判。
开放问题：以可证伪实验驱动后续决策
文章提出四个可证伪的开放问题，如Classic与Crimson混跑时的peering一致性、OSD用户态轮询与recovery的CPU隔离等，并给出具体检验方法。这些问题的关闭条件必须是测量或正式文档变更，而非社区幻灯片。这种态度鼓励读者在实验室中验证假设，并将结果回写排除树，使选型决策持续演进。
Q&A
Ceph RADOS选型时，如何判断是否需要跨节点冗余？
如果数据必须跨节点冗余或被多节点并发权威访问，则需要分布式存储；否则可考虑本机NVMe或云块。
Crimson OSD在Squid v19.2.5中的定位是什么？
Crimson OSD在Squid v19.2.5中是首个技术预览（tech preview），不适合生产使用，需要显式实验旗标才能启动。
Tentacle+标签代表什么？
Tentacle+标签表示该特性属于Ceph Tentacle（20.x）版本或之后才可能跟踪，未进入Squid稳定承诺，需以正式发布说明为准。
Rook和CSI在Ceph生态中解决什么问题？
Rook和CSI解决编排问题，如StorageClass、PVC、快照类、升级钩子，但不涉及RADOS内核语义变化。
Ceph RADOS选型时，什么情况下应该选择MinIO而不是Ceph RGW？
当应用是纯S3接口，且无法接受bucket index OMAP和LIST归并税，规模中小，且没有已有RADOS部署时，倾向选择MinIO。
CephFS在什么情况下不适合使用？
如果应用频繁fsync或强同步写，则不适合使用CephFS，因为MDS journal会串在关键路径上，应选择本机文件系统或其他方案。
Ceph RADOS选型时，如何判断是否应该直接使用云块存储？
如果运行在公有云且底层已是云盘，应直接使用云块，避免在云盘之上再叠加Ceph造成双层延迟。
Ceph RADOS选型时，如何判断是否应该使用本机NVMe+SPDK？
如果应用P99延迟硬要求低于约1ms，且能付得起轮询核税，则倾向使用本机NVMe+SPDK；否则使用内核NVMe或云块。
Ceph RADOS选型时，如何判断是否应该使用Ceph RBD？
如果块接口P99延迟能容忍副本RTT+WAL后的开销，且不在公有云上叠加云盘，则适合使用Ceph RBD。
Ceph RADOS选型时，如何判断是否应该使用CephFS？
如果应用不频繁fsync或强同步写，且能接受caps/MDS税，则适合使用CephFS。
