摘要

  • Weil 在 UC Santa Cruz 的集体研究项目中开发了 Ceph 项目，并在 2006 年发表 Ceph 和 CRUSH 基础论文后，于 2007 年完成博士学位。
  • CRUSH 根据映射、权重、拓扑和规则计算数据位置；RADOS 在 monitors 和 OSDs 之间分配对象、副本、故障检测和恢复。
  • Ceph 通过 RBD 提供块存储，通过 RGW 提供对象存储，并通过 CephFS 在同一基础之上提供 POSIX 风格的文件系统，但运行路径不同。
  • Weil 于 2012 年参与创立 Inktank，Red Hat 于 2014 年 4 月 30 日宣布以约 1.75 亿美元收购该公司。
  • Weil 已离开 Ceph 的日常工作，现领导 Civic Media。当前权力在 maintainers 和当代治理结构中，而非历史创始人。

从存储阵列到算法

Ceph 从常规数据路径中移除了集中式位置表。CRUSH 根据映射和规则计算设备位置，OSDs 在 RADOS 中存储数据、交换状态、复制并在 monitors 维护的可信映射下恢复。工作被分散，但权力并未消失。

结果取决于权重、层次结构和真实的故障域。过时的映射会精确地再现糟糕的布局。该算法减少了查找和不必要的移动，但运维人员必须正确表示物理世界。

研究团队，而非单打独斗的发明者

Ceph 诞生于加州大学圣克鲁斯分校的存储系统研究中心。Weil 是核心的设计者和构建者，但导师、合著者、学生、资金和测试环境共同塑造了这个项目。2006 年的论文署有多位作者，包括 Scott Brandt、Ethan Miller、Carlos Maltzahn 和 Darrell Long（视论文而定）。

集体署名并不会削弱 Weil 的作用；它解释了博士论文如何成为基础设施。其他人必须理解、批评和维护这个系统，它才能在其创造者之后继续存在。

CRUSH：计算数据所属的位置

CRUSH 使用层次化 buckets、权重和规则来选择有序的设备列表。规则可以强制副本分布在不同的机架，或选择特定介质类别。当集群发生变化时，会重新映射部分对象，而不是为每个对象维护集中式表。

规则是可执行的策略。错误的权重或未正确表示的机架会扭曲分布和恢复。在变更之前，应模拟数据移动、检查剩余容量并了解网络负载。

RADOS 与分布式修复决策

RADOS 将大量 OSDs 整合为一个统一基础。monitors 维护法定人数和映射，OSDs 存储对象、比较状态、复制并修复。恢复发生在了解数据的组件附近，而不是由单一控制器指挥每次迁移。

大规模故障可能引发重建风暴，与客户争抢网络和磁盘资源。可用性取决于余量、限流（throttling）、设备健康状况和 OSD 退出时间。分布式并不意味着免费或自动。

一个对象存储，三种存储接口

RBD 提供块存储卷，RGW 提供对象 API，CephFS 通过 metadata servers 构建 POSIX 风格的文件系统。这些接口共享 RADOS 以及位置和恢复机制。

但瓶颈各不相同。RGW 增加了身份和网关，CephFS 增加了一个 metadata 层，RBD 依赖客户端和缓存。一种模式的成功并不能证明另一种模式的适用性。

placement groups、恢复与故障的代价

placement groups 将对象分组，使位置、peering 和恢复变得可管理。它们的分布决定了均衡性和故障后的工作量。当 OSD 丢失时，集群会根据策略重新映射和重建。

可用空间不足或拓扑错误会延长降级状态。必须监控 unclean 实体、backfill、延迟、带宽和恢复时间。复制不能替代备份以防范逻辑删除或损坏。

从博士代码到 Linux 基础设施

从博士论文到 Linux 和 OpenStack 的过渡需要多年的打包、兼容性、文档、升级测试和故障修复。内核和发行版集成将 Ceph 带入了云和产品中。这些不起眼的运维工作与学术论文同样重要。

开放性允许选择硬件并催生了多种产品，但也成倍增加了网络、设备、内核和版本的组合。upstream 发布一个分支，集成商和运维人员承担实际组合的责任。

Inktank、Red Hat 与商业责任

Inktank 成立于 2012 年，销售支持并组建工程团队。Red Hat 于 2014 年 4 月 30 日宣布以约 1.75 亿美元收购该公司，使 Ceph 进入一家大型开源公司和云业务。

资金帮助了维护和扩展，但也集中了招聘。许可证和社区限制了独家控制。客户需要区分公共项目、Red Hat 产品和具体发行版；它们各有各的路线图和支持边界。

项目学会在创始人缺席后继续前行

Weil 后来离开了 Ceph 的全职工作，创立了 Civic Media。他的经历解释了起源，但并不能决定当前的发布决策。将所有成功或当前事故都归因于创始人，会抹杀当前 maintainers、打包人员和运维人员的贡献。

没有他的延续本身就是成功的一部分。继任需要能够解决冲突、发布补丁并维护子系统的结构。历史权威值得尊重，但不是永久的领导权。