转载

Ceph 生态系统

Ceph 是一个致力于构建下一代存储的项目，由 Sage Weil 从 04 年开始进行，在 08 年开始建立开源社区并接纳外部的开发者加入项目。从 10 年开始，来自 Yahoo，Suse，Canonical，Intel 等第一批开发者开始进入 Ceph 社区协作开发，在 12 年进入 OpenStack Cinder 成为重要的存储驱动，13 年开始在 OpenStack 用户间逐渐试用，在 14 年 Ceph 逐渐吸引越来越多来自不同厂商的开发者加入，在 14 年中，Ceph 的实际控制者 Inktank 被 Redhat 收购，被注入强心剂和得到更广泛的支持。至今 Ceph 已经成为最广泛的全球开源软件定义存储项目，拥有一个得到众多 IT 厂商支持的协同开发模式。

对于用户来说，Ceph 是一个拥有丰富特性，连接众多其他开源项目的成熟生态系统，在完善的测试基础设施和较为稳定的开发周期和模式运行下，Ceph 正被越来越多企业用户的部署和使用。

Contents

平台生态系统
技术平台
- - 项目开发迭代周期
  - Ceph Developer Summit
  - 贡献者
持续创新环境
广泛的用户基础
- - CERN
  - DreamHost
  - Yahoo Flick

平台生态系统

不管是商业系统还是开源项目，任何一个强壮的开发生态体系都依赖于三个重要的支持：技术平台，持续创新环境和广泛的用户基础。比如 IOS 这个开放的开发平台通过超百万的 APP 和来自全球数亿用户的使用构成了循环的生态体系，Facebook 通过其开发者平台得到来自数十万个在线应用和亿万用户(80% 以上来自非美加用户)的支持，OpenStack 项目通过其不断演进的工具，服务和新项目，加上全球私有云，公有云用户的运行支持，构建了现在最流行的开源云平台。

后面我们关注 Ceph 的技术平台，持续创新环境和广泛的用户基础这三个方面。

Ceph 生态系统

技术平台

Ceph 项目致力于成为未来存储的核心，其设计原则有以下几点:

所有组件必须能够横向扩展，没有单点故障并运行在普通商用硬件上
尽可能自我管理
开源，以 LGPL 授权
使用 client/cluster 而不是 client/server 的访问方式

Ceph 通过实现类 POSIX 接口的对象存储接口来构建底层通用的存储系统，上层通过堆叠不同存储标准(如 POSIX，块接口和 S3/Swift)来实现不同存储场景的应用。这个方式也是 Ceph 统一存储目标的技术基础。

Ceph 生态系统

项目开发迭代周期

目前 Ceph 社区采用每半年一个版本发布的方式来进行特性和功能的开发，每个版本发布需要经历设计，开发，新功能冻结，持续若干个版本的 Bug 修复周期后正式发布下一个稳定版本。

Ceph 会维护了多个稳定版本来保证持续的 Bug 修复来保证用户的存储安全，社区会有一支稳定版本发布团队来维护已发布版本，每个涉及到之前版本的 Bug 都会被该团队移植回稳定版本，并且经过完整 QA 测试后发布下一个稳定版本。

每个 commit 都需要经过单元测试，模块维护者 review，并通过 QA 测试子集后才能合并到主线。社区维护了一个较大规模的测试集群来保证代码质量，丰富的测试案例和错误注入机制保证了项目的稳定可靠。

Ceph Developer Summit

Ceph 会在上一个版本特性冻结之前开始下一个版本的特性设计，主要依赖于 Ceph Developer Summit(CDS) 的机制来进行讨论。CDS 主要在线上进行，通过多人视频方式进行沟通，参与者通过 ppt，pad 和在线演说来进行，特性的讨论和结论主要由发起者和模块技术领导人来完成，可以通过这个页面来了解过去 CDS 的历史记录。

一个 Blueprint 需要提交者经过严密的考虑，然后交给 CDS 的 Chairman (通常是 Sage 和 Patrick) 去调度相应的时间去讨论，通常会根据时区进行安排。每个 Blueprint 必须有清晰的提交者和所有人，不仅仅是讨论这个想法的目的和实现结果，还需要考虑具体的实现方式和结果是不是能在目前的 Ceph 中得到满足。

贡献者

目前 Ceph 社区由来自超过 40 个公司的上百名开发者持续贡献代码，平均每星期的代码 Commits 超过 150 个，每个版本通常在 2000 个 commits 左右，代码增减行数在 10w 行以上。在过去的几个版本发布中，贡献者的数量和参与公司明显增加。

由于 Ceph 社区并没有良好的社区贡献排行网站，上图来自 OpenStack stackalytics 提供的最近一次 Release，Liberty 期间 Ceph 的 Line of Code(LoC) 代码贡献排行。其中 Redhat 贡献了四分之三的代码，Intel 和来自国内的 SDS 初创公司 XSky 分别排名第二和第三。

非常有意思的是 Ceph 的使用用户占据了相当的贡献排名，一定程度上反映了 Ceph 目前的现状，要能够真正掌控 Ceph 必须得深入社区并随之成长。因此，对于一个并不是像 Linux 一样成熟的开源项目，特别还是一个存储系统来说，代码贡献程度基本决定了对于 Ceph 的理解，风险控制和使用程度。社区内部的形成的开发，使用问题，迭代，修复，升级，测试流程闭环产生的效应能够大大提高参与公司对于 Ceph 的理解。大部分真正大规模使用或者基于 Ceph 的产品的公司都参与或间接参与到了社区其中，这非常类似于早期的 Linux 和 OpenStack 情况。

Ceph 生态系统

持续创新环境

从传统IT基础架构的生态链看，各个层级的行业领导者纷纷为Ceph投入人力，物力来持续推动不断创新的运行，开发和生产环境。

如上图所示，Redhat，Suse 和 Canonical 构成了 Ceph 软件发行包的厂商，Intel，Mellanox，AMD 和 Cisco 分别在不同的硬件组件层面推动自身融入 Ceph 体系，SanDisk，HDS 和 Fujitsu 都在自身的存储系统上采用 Ceph 整合，CERN 和德国电信分别是 Ceph 社区参与和回馈最多的企业用户。

Ceph 通过其开放的社区和插件化的代码架构来包容越来越多的底层厂商参与其中，不管是 Mellanox 推动 Infiniband/RDMA，还是希捷的 Kinetic API，或是 Intel x86 架构，ARM 都在积极的参与其中，利用自身的优势来持续对 Ceph 软件体系进行创新发展。

比如在网络层面，通过插件方式的网络 IO 栈选择，相对于默认情况下的 TCP/IP Kernel 栈，Mellanox 联合 Redhat 提供了基于 RDMA 的网络方案，Solarflare 正在准备支持基于 OpenOnLoad 的 Kernel TCP Offload 方案。在底层存储上，默认方案是基于 Linux 通用本地文件系统构建的存储引擎，

但同时通过其多元化的存储引擎设计，可以通过 KeyValueStore 支持硬件直接暴露 KV 接口的设备比如希捷的 Kinetic API，而且因为 SSD 本身在底层是一个类 KV 的页访问方式，类似 Samsung 和 SanDisk 为了避免块接口语义转换，在推出的 Flash 一体机都采用私有的 KV 库对接 Ceph 存储引擎。同时通过 MemStore 封装的内存管理 API 通过 libpmem可以实现对 NVDIMM 或者 NVRAM 的管理。

广泛的用户基础

Ceph 项目的 vision 是突破长久以来存储厂商封闭垄断的现状，将存储系统架构于普通商用硬件之上，并且为统一存储和异构管理这一目标发展。

从 OpenStack 后端存储流行起步，Ceph 目前广泛使用在传统企业，互联网之中。

CERN

CERN IT 部门在 13 年中开始就运行了一个单一集群超过 10000 个 VM 和 100000 个 cpu cores 的云平台，主要用来做物理数据分析。这个集群后端 Ceph 包括了 3PB 的原始容量，在云平台中作为一千多个 Cinder 卷和一千五百多个 Glance 景象的存储池。在 15 年开始测试单一 30 PB 的块存储 RBD 集群。

DreamHost

DreamHost 从 12 年开始运行基于 Ceph RadosGW 的大规模对象存储集群，单一集群在 3PB 以下，大约由不到十个机房集群组成，直接为客户提供给对象存储服务。

Yahoo Flick

Yahoo Flick 自 13 年开始逐渐试用 Ceph 对象存储替换原有的商业存储，目前大约由十个机房构成，每个机房在 1-2 PB 之间，存储了大约 2500 亿个对象。

原文 http://www.wzxue.com/ceph-ecosystem/

正文到此结束