近年来，大型企业以及开源社区不断的推动中国开源技术的发展，今天的中国已然成为OpenStack & Ceph等开源技术大放光彩的乐土。
图为 Ceph中国行各地沙龙
Ceph国内用户生态
Ceph作为全球最火热的开源分布式存储项目，同样在中国的发展也是非常火热，不断开始在不同领域不同行业及客户系统相融合。典型应用在国内一线互联网公司以及运营商、政府、金融、广电、能源、游戏、直播等行业。
当前中国Ceph形势对比前几年已经发生了决定性的变化，随着国内越来越多的各行业用户的使用，足以见证它的稳定性可靠性。Ceph中国用户生态已然形成，可以看到国内如：中国移动、腾讯、阿里、网易、乐视、携程、今日头条、中国电信、中兴、恒丰银行、平安科技、YY、B站、360等。正是由于众多用户的使用验证了它的稳定性和可靠性的同时也促进了Ceph的进步，使其出现了很多新东西，如 SPDK、BlueStore、RDMA等等这些高性能底层技术。
Ceph国内贡献
豪迈在之前的文章也谈到过Ceph社区的贡献者，非常有意思的是 Ceph 的使用用户占据了相当的贡献排名，一定程度上反映了 Ceph 目前的现状，要能够真正掌控Ceph 必须得深入社区并随之成长。因此，对于一个并不是像 Linux 一样成熟的开源项目，特别还是一个存储系统来说，代码贡献程度基本决定了对于Ceph 的理解，风险控制和使用程度。社区内部的形成的开发，使用问题，迭代，修复，升级，测试流程闭环产生的效应能够大大提高参与公司对于Ceph 的理解。大部分真正大规模使用或者基于 Ceph 的产品的公司都参与或间接参与到了社区其中，这非常类似于早期的Linux 和 OpenStack 情况。
那么国内都有哪些公司参与社区的贡献呢?我来说下，如：中国移动、XSKY、中兴、浪潮、H3C、阿里、网易、乐视、360、United Stack、99cloud等等，我这里就不展开说了（以上公司不分排名），详情可以查看社区mail list。
大家可能会说国内企业对Ceph社区贡献的参与度远远低于OpenStack社区贡献，我觉得这样反而没什么不好，因为存储是一个很严肃的事情，控制层面的东西远远不能和数据层面的东西相比较，另外存储的门槛很高，不是随随便便就可以玩的。社区要求高质量的代码，拒绝刷榜污染开源技术文化环境。例如乐视小伙伴提交的Ceph RGW:Lifecycle还有XSKY小伙伴提交的DPDK、SPDK、RDMA、AsyncMessenger等等。
Ceph社区：持续的创新环境
从传统IT基础架构的生态链看，各个层级的行业领导者纷纷为Ceph投入人力，物力来持续推动不断创新的运行，开发和生产环境。
如图所示RedHat、SUSE、Canonical、FreeBSD等构成了Ceph 软件发行包的厂商，Intel，Mellanox，AMD 和 Cisco 分别在不同的硬件组件层面推动自身融入Ceph 体系，SanDisk，HDS 和 Fujitsu 都在自身的存储系统上采用 Ceph 整合，CERN 和德国电信分别是 Ceph 社区参与和回馈最多的企业用户。同时近年来国内运营商级别用户中国移动也在参与Ceph社区的贡献。
Ceph 通过其开放的社区和插件化的代码架构来包容越来越多的底层厂商参与其中，不管是 Mellanox 推动 Infiniband/RDMA，还是希捷的 Kinetic API，或是 Intel x86 架构，ARM 都在积极的参与其中，利用自身的优势来持续对 Ceph 软件体系进行创新发展。
比如在网络层面，Mellanox 联合 XSKY提供了基于 RDMA 的网络方案，Chelsio 跟 XSKY 合作实现基于 iWARP 的 RDMA 存储网络等。
Ceph存储引擎
Ceph在存储后端支持多种不同的存储引擎，有点类似MySQL支持InnoDB，MyISAM等等一样。之前有FileStore，KeyValueStore、NewStore和MemStore，但在这些存储引擎中真正被用来做在线系统只有FileStore。但是FileStore由于历史问题，存在先天的过多依赖本地文件系统的问题，在高利用率下存在较为严重的性能瓶颈问题。
因此，从Infernails版本开始，Sage开始NewStore的开发，通过结合键值数据库的高效管理和本地文件系统对于数据的空间管理来实现高效的后端存储。但是由于RocksDB和XFS的完美结合困难，在遭受若干次打击后，Sage Weil决定一捅到底，直接替换XFS使用一个简易的用户态文件系统进行管理。这个项目命名为BlueStore。
BlueStore架构图
在这个崭新的 BlueStore设计和实现中，RocksDB被寄予厚望去管理起整个元数据系统，同时整个数据空间会采用一些为Ceph优化的空间分配器进行工作。目前Ceph已经支持离线 FileStore 到 BlueStore 的转换。
Ceph备份容灾
作为一个分布式存储系统，Ceph 很少会提及整集群全量备份，毕竟作为一个庞大的多副本存储池，很难再投入更大规模的备份系统作为支撑，更多的是由Ceph 自身通过副本和后台校验加上并行恢复来达到传统存储加备份机的可靠性。
但是 Ceph 仍然在不同的接口系统中提供了多种方式，在块存储中，用户往往需要备份几个重要的卷即使Ceph 集群在最差情况完全无法启动也能保证重要数据不至于丢失。
Ceph RBD异地灾备叫做Ceph RBD Mirroring，在Ceph Jewel版本中宣布可用。在此之前Ceph块存储解决方案（俗称RBD）还不能很好的跨地域复制（灾备）。这里需要提醒一下，由于Ceph是强一致性，所以只有在所有副本都写完的时候才认为一个写操作完成。这就是为什么建立一个跨很长距离地域的集群通常都不是一个好主意，因为这种情况延时一般都很高。集群必须等到所有的写操作都完成，所以客户端可能需要大量的时间来进行确认。
因此，需要一种机制来允许在不同地域的集群之间复制块设备。在当前Jewel版本中，主要是实现两个守护进程之间一对一的关系，而在未来将会扩展到1对N。这样，在Jewel以后的版本中，你将能够配置一个集群备份到多个目标备份集群中。
RBD Mirror功能的启用和禁用可以作用在整个Pool或者一个p_w_picpath上。如果在资源池级别启用了RBD Mirror功能，这样资源池中的每一个启用了日志特性的镜像将会被Mirroragent复制。
目前Ceph在多集群方案聚焦于接口层的方案，而不是在 RADOS 层面实现。比如 RADOS Object Storage在集群间通过Agent的方式进行数据同步，当然，在Jewel 版本中RADOS Object Storage V2种已经支持多读多写的机制，由于对象存储的弱语意，RADOS Object Storage的跨站仍然是最终一致性。其定义了 Zone，ZoneGroup 和联合集群概念，每个 Zone 可以理解为一个传统 Ceph 集群的部分，ZoneGroup 是多个Zone的集合，通常由不同地的Ceph集群中的Zone构成，而整个联合集群中只允许一个Master ZoneGroup 来进行写操作。因此从逻辑上来部署的话，Master ZoneGroup可以由多个Ceph集群构成，而Slave ZoneGroup也可以将这些Ceph集群的其他池作为Zone。这样就完成了多地多活的集群方案。
新版 Multi-Site 沿用记日志再同步的架构，代码基本重写，引入了boost 的协程框架，配置更清晰。同一个域下多 Zone之间的数据为多主模式，可以同时写；元数据为主从模式，由主Zone写入并同步到从Zone，保证元数据一致性。并且即将支持桶级同步。最近主线合并了同步模型的插件框架，用户可以自定义插件来对接 elasticsearch 实现元数据索引，或者自定义的向云端备份等操作。
Ceph未来展望
1.Ceph与Elasticsearch
前段时间看到Ceph支持了Elasticsearch，RGW+Elasticsearch是今年Ceph对象存储的一个热点功能，相信Ceph在大数据时代下对数据搜索分析方面也将会更加的完善。
2.CephFS
CephFS在社区Jewel版本宣称生产环境就绪， 目前 Active/Standby 模式比较稳定，Multi Active模式不太稳定，另外大规模使用的时候还是有一些问题，希望社区尽快完善CephFS相关功能，从用户角度还是有很多人期待使用CephFS的。
Ebay之前测试过J版本的CephFS，感兴趣的可以看看他们的测试报告在Slideshare上(http://www.slideshare.net/XiaoxiChen3/cephfs-jewel-mds-performance-benchmark)
3.Ceph与新型硬件
同时在硬件高速发展的今天，也希望Ceph能够在Intel的最新硬件3D Xpoint能跑出更好更高的性能，能够使Ceph更加适应高性能的场景。
4.Ceph人才培养
最后说下对于Ceph人才的培养看法，国家工信部的三年计划里面也公示了，”要建立创新人才培养模式，鼓励高校加强云计算相关学科建设，支持企业与高校联合开展在职人员培训，简历一批人才实训基地。” 随着Ceph在中国的运营商、政府、金融、广电、能源、游戏、直播等行业纷纷落地，导致出现了大量职位空缺。
所以现在需要建立起一套标准的Ceph培训体系来缓解目前对Ceph人才的稀缺问题，同时进行Ceph校园行以京津冀地区高校为试点辐射全国，所谓开源、Ceph宣传推广从校园开始，响应国家号召促进大学生就业和积极参与开源社区贡献。
来源：oschina
链接：https://my.oschina.net/u/4325154/blog/4341485