2018年11月12日，Linux基金会在德国柏林的“Ceph Day”上正式宣布成立“Ceph基金会”来支持Ceph开源项目。Ceph基金会接受Linux基金会的管理，它的成立将为Ceph社区的合作和成长提供一个中立的机构。
理事会由所有高级成员，普通成员代表，准成员代表和Ceph领导团队代表组成，董事会的主要职责在于：
- 建立并批准用于支持Ceph项目的年度预算
- 建立特设委员会以满足项目的当前需求
- 协调外展或营销
- 定期开会讨论基金会活动，Ceph项目的现状以及整体项目战略
- 在董事会面前对任何决定或事项进行投票
Ceph基金会董事会不对Ceph的技术治理负责，也没有任何直接控制权。开发和工程活动通过传统的开源流程进行管理，并由Ceph领导团队监督。董事会主要成员如下：
创始顶级会员主要包括: Amihan，Canonical，中国移动，DigitalOcean，Intel，ProphetStor Data Services，OVH，Red Hat，SoftIron，SUSE，Western Digital，XSKY和ZTE。
普通会员和准会员包括ARM，平安科技，小桔科技(滴滴出行)， 中铁信弘远 ，Ambedded Technology，Croit GmbH，EasyStack，Intelligent Systems Services，Catalyst Cloud，QCT，欧洲粒子物理研究所，英国科学与技术设施委员会，莫纳什大学，希腊GRNET机构，南非射电天文观测台(SARAO)，加州大学圣克鲁兹分校开放源码软件研究中心(CROSS)等。
Ceph作为最流行的分布式软件定义存储系统，目前服务于各个行业的客户，包括金融机构(如Bloomberg，Fidelity)，云服务提供商(如Rackspace，Linode)，学术和政府机构(如Massachusetts Open Cloud)，电信基础设施提供商(如Deutsche Telekom)，汽车制造商(宝马)，软件解决方案提供商(如SAP，Salesforce)等等。
Ceph基金会的成立将对Ceph技术发展和社区壮大起着积极作用，目前有很多企业存储系统都是基于开源Ceph优化而来。只是国内，市场上就已经涌现大量Ceph系产品，如H3C的ONEstor块和对象、UniStor文件系统，中兴CloveStorage，衫岩SandStone，XYSK(星辰天合) X-CBS、X-EBS和X-EOS，浪潮AS13000系列等。
关于Ceph架构，数据分布和特性对比(参考“详解Ceph数据是如何布局”)，笔者在前期的文章中已经做了详细分享。今天就跟大家一起讨论下Ceph的可靠性恢复原理: Scrub机制。
Scrub默认策略是每天到每周(如果集群负荷大周期就是一周，如果集群负荷小周期就是一天)进行一次，时间区域默认为全天(0时-24时)，Deep-Scrub默认策略是每周一次。
Ceph进行数据读写时并不会增加校验数据来保证数据的正确性(类似ECC、CheckSum等)，只能通过内部的Scrub机制来校验数据。
Scrub流程是以PG为单位定期触发的，由该 PG 的Master 角色所在 OSD 启动；每次Scrub会扫描一个PG内的部分对象，校验期间对象的数据是不允许修改。
校验信息包括每个对象的元信息如大小、扩展属性的所有键和历史版本信息等，在Ceph 中被称为 ScrubMap。发起者会比较多个ScrubMap并发现不一致的对象，不一致对象会被收集最后发送给 Monitor，由用户手工发起修复。
Ceph允许通过Deep Scrub模式来全量比较对象信息来期望发现Ceph 本身或者文件系统问题，这通常会带来较大的 IO 负担，较少在生产环境使用。
当然，Ceph Scrub机制存在的问题。在发现不一致对象后，缺少策略来自动矫正错误，比如如果多数副本达成一致，那么少数副本对象会被同化。Scrub 机制并不能及时解决存储系统端到端正确的问题，很有可能上层应用早已经读到错误数据，下面一起来看看Scrub的工作流程：
① OSD 会以 PG 为粒度触发 Scrub流程，触发的频率可以通过选项指定，而一个PG的Scrub启动都是由该 PG 的 Master 角色所在OSD启动。
② 一个PG在普通的环境下会包含几千个到数十万个不等的对象，因为Scrub流程需要提取对象的校验信息然后跟其他副本的校验信息对比，这期间被校验对象的数据是不能被修改的。因此一个PG的Scrub流程每次会启动小部分的对象校验，Ceph 会以每个对象名的哈希值的部分作为提取因子，每次启动对象校验会找到符合本次哈希值的对象，然后进行比较。这也是 Ceph称其为Chunky Scrub的原因。
③ 在找到待校验对象集后，发起者需要发出请求来锁定其他副本的这部分对象集。因为每个对象的Master和Replicate节点在实际写入到底层存储引擎的时间会出现一定的差异。这时候，待校验对象集的发起者会附带一个版本发送给其他副本，直到这些副本节点与主节点同步到相同版本。
④ 在确定待校验对象集在不同节点都处于相同版本后，发起者会要求所有节点都开始计算这个对象集的校验信息并反馈给发起者。
⑤ 该校验信息包括每个对象的元信息如大小、扩展属性的所有键和历史版本信息等等，在Ceph 中被称为 ScrubMap。
⑥ 发起者会比较多个ScrubMap并发现不一致的对象，不一致对象会被收集最后发送给 Monitor，最后用户可以通过Monitor了解Scrub的结果信息。
另外，当用户在发现出现不一致的对象时，可以通过 “ceph pgrepair [pg_id]” 的方式来启动修复进程，目前的修复仅仅会将主节点的对象全量复制到副本节点，因此目前要求用户手工确认主节点的对象是“正确副本”。此外，Ceph允许Deep Scrub模式来全量比较对象信息来期望发现 Ceph 本身或者文件系统问题，这通常会带来较大的IO负担，因此在实际生产环境中很难达到预期效果。
通过上述Scrub流程，大家也会发现目前的 Scrub机制还存在以下2个问题：
① 在发现不一致对象后，缺少策略来自动矫正错误，比如如果多数副本达成一致，那么少数副本对象会被同化。
② Scrub 机制并不能及时解决存储系统端到端正确的问题，很有可能上层应用早已经读到错误数据。
对于第一个问题，目前Ceph已经有Blueprint来加强Scrub的修复能力，用户启动Repair时会启动多数副本一致的策略来替代目前的主副本同步策略。
对于第二个问题，传统端到端解决方案会更多采用固定数据块附加校验数据的“端到端校验”方案，但是 Ceph 因为并不是存储设备空间实际的管理和分配者，它依赖于文件系统来实现存储空间的管理，如果采用对象校验的方式会严重损耗性能。
因此在从文件系统到设备的校验需要依赖于文件系统，而Ceph包括客户端和服务器端的对象正确性校验只能更多的依赖于ReadVerify机制，在涉及数据迁移时需要同步的比较不同副本对象的信息来保证正确性。目前的异步方式会允许期间发生错误数据返回的可能性。
本文分享就到这里了，请通过原文链接获取电子书材料，或者请识别小程序查看更多内容。
推荐阅读：
温馨提示：
请搜索“ICT_Architect”或“扫一扫”二维码关注公众号，点击原文链接获取更多技术文章。
求知若渴 虚心若愚
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/225860.html原文链接：https://javaforall.net
