Ceph：通往 1 TiB/s 之旅
工程师们拆解了一个 Ceph 存储集群：它使用 68 台以 NVMe 为主的服务器，读吞吐量超过 1 TiB/s，重点分析真正的瓶颈在哪里（网络 vs. PCIe vs. CPU），以及这套架构距离理论极限还有多近。许多人权衡 Ceph 的优势——韧性、横向扩展增长和功能集——与它的复杂性和延迟，尤其是在家庭实验室和数据库工作负载中的表现，并将其与 MinIO、SeaweedFS、Longhorn、GlusterFS、ZFS、btrfs 和 EOS 等替代方案进行比较。讨论还涉及实际硬件选择，从 100 GbE+ 交换机和 NIC 一直到 Raspberry Pi 集群，以及 Ceph 的历史和在 OpenStack、Kubernetes、CERN 和自定义 AWS 部署等环境中的真实使用情况。
1 TiB/s 的硬件与网络
- 讨论指出，800 Gbps 交换机已经存在，但 800 G NIC 目前还无法实际获得；PCIe 通道数量和代际是一个限制，不过如果使用 32 条通道，这并不是一个硬性障碍。
- 大多数参与者都假定现代 100 GbE 交换机（pizza-box / leaf-spine / Clos fabric）能够在所有端口上跑满线速；任何做不到这一点的交换机都被视为“玩具”设备。
- 二手 40/56/100 GbE 交换机现在相对便宜；有人提到一些“捡漏”的 MikroTik 和二手数据中心交换机，适合家庭实验室。
- 对基准测试集群的分析得出结论：瓶颈是网络，而不是 NVMe 硬盘；测得的 1 TiB/s 约为跨节点理论网络容量的 65%。
Ceph 的性能特征
- Ceph 提供很强的可扩展性和韧性，但 CPU 开销明显，而且延迟相对较弱，尤其是与本地 NVMe 相比。
- 基准测试细节强调，编译器优化标志以及 OSD 线程/IOMMU 争用，都是出人意料地重要的性能因素；开发者也承认线程模型需要重新设计。
- 对于事务型数据库，几位参与者提醒 Ceph 的延迟通常过高，不过也有人报告在硬件条件良好时，块存储（RBD）延迟是可以接受的。
Ceph 在家庭实验室中的使用
- 很多人建议除非目的是学习，否则不要在家里上 Ceph；硬件门槛（多节点、高速网络、非 SMR 磁盘）和复杂度都是真实存在的。
- 也有人成功在 Proxmox 集群、迷你 PC、NUC，甚至 Raspberry Pi / ODROID 板子上运行 Ceph，并接受较低性能和更高延迟。
- 一个反复出现的主题是：Ceph 非常适合韧性和弹性，不适合追求原始速度或简单性。
替代方案与相关系统
- 家庭实验室里常见的替代方案包括：SeaweedFS、Longhorn、MinIO、Garage、GlusterFS（尽管 Red Hat 支持即将结束）、EOS、ZFS（尤其是 mirror vdev）、Btrfs、LVM+mdadm 和 SnapRAID。
- 讨论到的权衡包括：
- MinIO：优秀的 S3 对象存储，但对集群规模变化比较敏感，并且要求快速磁盘。
- Garage：简单，只做复制；适合家庭实验室，不适合大数据集。
- ZFS mirrors：易于增量扩展，重建速度快，但空间效率只有 50%。
- CERN 的 EOS：为物理学工作负载做过调优，是对 Ceph 的补充，而不是替代。
运维复杂度与采用理由
- Ceph 被看作“除非你真打算用，否则别部署”：复杂，但在廉价商品硬件上，能以线性扩展方式提供大规模、高可用存储，这一点独一无二。
- 它支撑着 OpenStack/Kubernetes 部署、自建类似 EBS 的系统，以及高 IOPS 缓存；用户报告称，相比云块存储，它在成本和性能上都有显著收益。