标签：map objects corrupt 信息 write 计算 form 存储引擎 UI
转自：https://www.ustack.com/blog/ceph-internal-scrub/
Ceph 的主要一大特点是强一致性，这里主要指端到端的一致性。众所周知，传统存储路径上从应用层到内核的文件系统、通用块层、SCSI层到最后的HBA和磁盘控制器，每层都有发生错误的可能性，因此传统的端到端解决方案会以数据块校验为主来解决(这方面的讨论可以参考SCSI中端到端校验能解决数据完整性问题吗)。而在 Ceph 方面，更是加入了 Ceph 自己的客户端和网络、存储逻辑、数据迁移，势必导致更高的错误概率。
来自How to Prevent Silent Data Corruption
因为 Ceph 作为一个应用层的路径，它利用了 POSIX 接口进行存储并支持 Parity Read/Write，这时候如果封装固定数据块并且加入校验数据会导致较严重的性能问题，因此 Ceph 在这方面只是引入 Scrub 机制(Read Verify)来保证数据的正确性。
简单来说，Ceph 的 OSD 会定时启动 Scrub 线程来扫描部分对象，通过与其他副本进行对比来发现是否一致，如果存在不一致的情况，Ceph 会抛出这个异常交给用户去解决。
/* * Chunky scrub scrubs objects one chunk at a time with writes blocked for that * chunk. * * The object store is partitioned into chunks which end on hash boundaries. For * each chunk, the following logic is performed: * * (1) Block writes on the chunk * (2) Request maps from replicas * (3) Wait for pushes to be applied (after recovery) * (4) Wait for writes to flush on the chunk * (5) Wait for maps from replicas * (6) Compare / repair all scrub maps * * This logic is encoded in the very linear state machine: * * +------------------+ * _________v__________ | * | | | * | INACTIVE | | * |____________________| | * | | * | +----------+ | * _________v___v______ | | * | | | | * | NEW_CHUNK | | | * |____________________| | | * | | | * _________v__________ | | * | | | | * | WAIT_PUSHES | | | * |____________________| | | * | | | * _________v__________ | | * | | | | * | WAIT_LAST_UPDATE | | | * |____________________| | | * | | | * _________v__________ | | * | | | | * | BUILD_MAP | | | * |____________________| | | * | | | * _________v__________ | | * | | | | * | WAIT_REPLICAS | | | * |____________________| | | * | | | * _________v__________ | | * | | | | * | COMPARE_MAPS | | | * |____________________| | | * | | | | * | +----------+ | * _________v__________ | * | | | * | FINISH | | * |____________________| | * | | * +------------------+ * * The primary determines the last update from the subset by walking the log. If * it sees a log entry pertaining to a file in the chunk, it tells the replicas * to wait until that update is applied before building a scrub map. Both the * primary and replicas will wait for any active pushes to be applied. * * In contrast to classic_scrub, chunky_scrub is entirely handled by scrub_wq. * * scrubber.state encodes the current state of the scrub (refer to state diagram * for details). */
Ceph 的 PG.cc 源文件中的 ASCII 流程描述已经非常形象了，这里只简述内容和补充部分信息。
用户在发现出现不一致的对象后，可以通过 “ceph pg repair [pg_id]” 的方式来启动修复进程，目前的修复仅仅会将主节点的对象全量复制到副本节点，因此目前要求用户手工确认主节点的对象是”正确副本”。另外，Ceph 允许 Deep Scrub 模式来全量比较对象信息来期望发现 Ceph 本身或者文件系统问题，这通常会带来较大的 IO 负担，因此在实际生产环境中很难达到预期效果。
正如流程所述，目前的 Scrub 有以下问题:
对于第一个问题，目前 Ceph 已经有 Blueprint 来加强 Scrub 的修复能力，用户启动 Repair 时会启动多数副本一致的策略来替代目前的主副本同步策略。
对于第二个问题，传统端到端解决方案会更多采用固定数据块附加校验数据的“端到端校验”方案，但是 Ceph 因为并不是存储设备空间实际的管理和分配者，它依赖于文件系统来实现存储空间的管理，如果采用对象校验的方式会严重损耗性能。因此在从文件系统到设备的校验需要依赖于文件系统，而 Ceph 包括客户端和服务器端的对象正确性校验只能更多的依赖于 Read Verify 机制，在涉及数据迁移时需要同步的比较不同副本对象的信息来保证正确性。目前的异步方式会允许期间发生错误数据返回的可能性。
标签：map objects corrupt 信息 write 计算 form 存储引擎 UI
原文地址：http://www.cnblogs.com/goldd/p/6610531.html
