分布式存储深度：Ceph、Longhorn 与 OpenEBS 的选型

三种方案，三条完全不同的技术路线

Ceph、Longhorn 和 OpenEBS 虽然都解决 Kubernetes 的存储供给问题，但最开始的设计出发点完全不同。理解这一点，再去看参数和优劣，才不会人云亦云。

Ceph：从底层分布式系统出发的全能型方案

Ceph 的核心是 RADOS 对象存储层，所有块、文件、对象接口最终都映射到 RADOS 上。它通过 CRUSH 算法把数据分布到集群的 OSD 上，不依赖客户端查元数据表，因此扩展性极强。对 Kubernetes 来说，块存储通过 RBD 和 Ceph CSI 接入，功能成熟，支持快照、克隆、扩容，甚至可以通过 RGW 对外提供对象存储。但 Ceph 的复杂度也是一等一：需要 mon、mgr、osd 至少三类角色，网络分区、时钟漂移、OSD 故障恢复都会成为问题。硬件建议也很苛刻，一般情况下 10GbE 起步，磁盘和内存要求高，生产环境没有专项存储运维，很难驾驭。

Longhorn：把软件定义存储搬进 Kubernetes

Longhorn 是 Rancher 团队开源的全 Kubernetes 原生方案。它在每个节点上部署存储控制器和卷副本，卷数据以块设备形式落盘，通过 iSCSI 让 Pod 访问。默认副本数 3，副本分布在多个节点上，保证跨节点容忍失败。相比 Ceph，Longhorn 的架构要直接得多——控制面是 Kubernetes Deployment，数据面靠每个节点上的 Longhorn Engine 和本地磁盘。安装用 Helm 即可，UI 面板可以管理卷、快照、备份。运维逻辑很贴近 Kubernetes 使用者的直觉。代价是性能上限取决于单节点磁盘能力，副本写入有三份，网络开销不小，支持跨节点故障转移，但换不来 Ceph 那种大规模统一存储能力。

OpenEBS：一篮子引擎，需要对号入座

OpenEBS 严格来说不是一个存储系统，而是一组存储引擎的集合。LocalPV 是节点本地盘，没有任何数据冗余；Jiva 和 cStor 是用户态数据卷，用容器做控制器和副本；Mayastor 则是基于 NVMe/TCP 的高性能引擎，设计目标是低时延和高吞吐。这种设计让 OpenEBS 可以覆盖很多场景，但也意味着你得先评估每个引擎的成熟度。例如 cStor 在新版本中已经标记为维护模式，Mayastor 又对硬件有要求。很多团队把 OpenEBS 当做一个“稳定的单一产品”，结果发现不同引擎的部署和运维方式大相径庭，这个理解偏差是后面踩坑的根源。

选型之前，先搞清楚这几个关键维度

在对比具体参数之前，有几个维度必须在项目组内达成一致：数据可靠性机制、数据路径性能、运维可操作性、生态集成，以及长期演进成本。很多选型最后出问题，是因为团队对这几个维度没有共同理解。

数据可靠性机制解决的是“数据放在哪、坏了几块盘怎么办”的问题。Ceph 用全局副本或纠删码，Longhorn 默认三副本跨节点，OpenEBS 则要看具体引擎。副本数不是越多越好，每个副本都会带来写放大和网络消耗。

数据路径性能直接关系业务响应时间。Ceph 的客户端通过存储网络访问 OSD，需要经过较复杂的协议栈；Longhorn 用 iSCSI 把远端块设备挂到节点上，再暴露给容器；Mayastor 则走 NVMe/TCP，目标是为了减少协议开销。存储软件自身的开销，在不同负载下的差别会被放大。

运维可操作性是最容易被低估的。Ceph 的监控和恢复机制强大，但那是建立在团队愿意花时间投入的前提下。Longhorn 的界面和操作更友好，适合小型团队。OpenEBS 的分引擎模式让运维需要理解多条体系，对团队的知识储备要求也不低。

生产环境里最常见的误判

选择困难往往不是因为方案太少，而是大家很容易把“网上说得最多的方案”当成“最适合自己的方案”。我见过几个很有代表性的误判，值得单独提出来聊。

• 第一个误判：Ceph 一定性能最好。Ceph 在节点和网络规模到位时，确实能做到高并发。但如果只有三五台普通服务器，数据要跨节点复制、CRUSH 计算、网络传输全部成为瓶颈，Ceph 的并发性能可能远不如本地盘方案。有些团队用很弱的硬件跑 Ceph，最后稳定性比 Longhorn 还差。
• 第二个误判：Longhorn 简单，所以可以当万能存储。Longhorn 适合为 Kubernetes 提供块存储，但它的对象存储和文件共享能力并不是重点。如果业务需要大规模文件共享或对象桶，硬把 Longhorn 卷当共享文件系统用，会很快撞到单点和性能问题。
• 第三个误判：OpenEBS 引擎多，选一个“看起来最好”的就行。Mayastor 看起来先进，但要求 NVMe 设备和大内存，社区迭代仍在进行中。如果你已经有大量 cStor 老卷，升级路径并不平滑。安全做法是在低风险业务下长期 PoC，而不是集群上线时临时决定。

该选哪一个？按团队现状做判断

没有一个方案能在所有环境里都是最优解。判断标准不是功能列表有多长，而是团队有多少人、集群多大、业务对风险和性能的要求多高。给出几个比较典型的判断路径。

• 如果你的 Kubernetes 集群在 50 个节点以内，团队没有专人维护存储，优先考虑 Longhorn。它和 Kubernetes 的结合最自然，升级和排障相对可控。
• 如果已经有 Ceph 环境，或者团队里有 Ceph 运维经验，并且需要块、文件、对象多种接口，Ceph 依然是大规模统一存储里最稳的选择。
• 如果业务对单卷时延敏感，基础设施有条件上 NVMe，Mayastor 值得做小范围 PoC，但不要一开始就全面接管生产。
• 如果你的团队只想聚焦业务，不想背上存储运维的负担，那么云上托管存储或商业存储可能比任何一个自建方案都更合理。

这里说一个很常见的场景：一个不到二十人的研发团队，运维只有两三个人，他们用了 Ceph，原因是看中它的功能全。但每一次硬件抖动，他们要花大量时间查 OSD 状态、处理恢复流程，团队精力被存储消耗得很严重。如果当时选 Longhorn，也许那些卷早就稳定跑起来了。技术选择不是证明谁更厉害，而是不让基础设施成为业务前进的阻碍。

落地时先做好这几件事

不管最终选了哪一种，在正式接入生产前，都要把下面几个环节走完，否则存储层的故障会让你付出数倍代价。

先明确故障域。比如 Longhorn 三个副本，节点却都在同一个机柜，那供电或网络故障可能把所有副本一锅端。副本数不等于高可用，需要把副本分布到独立的故障域里。

以 Longhorn 为例，接入 Kubernetes 其实就是创建一个 StorageClass，参数里可以控制副本数、数据本地化策略等：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn
provisioner: driver.longhorn.io
parameters:
  numberOfReplicas: '3'
  staleReplicaTimeout: '30'
  replicaSoftAntiAffinity: 'true'
volumeBindingMode: WaitForFirstConsumer

这个配置里，replicaSoftAntiAffinity 如果设置为 true，会把副本尽量分散到不同节点，而不是挤在一起。WaitForFirstConsumer 则让卷首次被 Pod 使用时再绑定，配合数据局部性会更好。一个简单的 YAML 背后，真正要关注的是故障域设计。

• 做长稳测试：持续运行 7 到 14 天，覆盖节点下电、磁盘替换、网络分区等场景，观察存储层的自愈行为。
• 监控存储指标：OSD 状态、Longhorn 卷副本状态、Mayastor 控制器延迟等，监控要早于告警，告警要早于故障。
• 备份和恢复演练：不要只依赖存储卷自带快照，快照不等于备份。定期把数据备份到对象存储或远端，并演练从零恢复一套服务。

写在最后：选型是约束条件的匹配

回到最开始的问题。Ceph、Longhorn 和 OpenEBS 没有谁是绝对更好的，它们对应的是不同团队的资源边界。Ceph 适合愿意投入时间和人力的基础设施团队，Longhorn 适合希望快速获得可靠块存储的 Kubernetes 用户，OpenEBS 适合有明确性能或本地化需求、且愿意做引擎评估的团队。真正的工程能力，不是把某个系统调好，而是知道在什么约束下选择什么样的代价。希望这篇文章能帮你把存储选型问题想得更清楚。