ceph 数据重构原理

本文分享自天翼云开发者社区《ceph数据重构原理》，作者:x****n

在分布式存储系统 Ceph 中，硬盘故障是一种常见问题。为了保证数据安全，当发生硬盘故障后，分布式存储系统会依据算法对故障硬盘上的数据进行数据重构及转储。和一般分布式系统一样的是，Ceph 同样使用多副本机制来保证数据的高可靠性（注：EC 在实现层面可以理解为副本机制的一种），给定一份数据，Ceph 在后台自动存储多份副本（一般使用 3 个副本），从而使得在硬盘损毁、服务器故障、机柜停电等故障情况下，不会出现数据丢失，甚至数据仍能保持在线。不过在故障发生后，Ceph 需要及时做故障恢复，将丢失的数据副本补全，以维系持续的数据高可靠性。

一.PG 和 PGLog

Ceph 中对象数据的维护由 PG（Placement Group）负责，PG 作为 Ceph 中最小的数据管理单元，直接管理对象数据，每个 OSD 都会管理一定数量的 PG。客户端对于对象数据的 IO 请求，会根据对象 ID 的 Hash 值均衡分布在各个 PG 中。PG 中维护了一份 PGLog，用来记录该 PG 的数据变化，这些记录会被持久化记录到后端存储中。PGLog 中记录了每次操作的数据和 PG 的版本，每次数据变更操作都会使 PG 的版本自增，PGLog 中默认保存 3000 条记录，PG 会定期触发 Trim 操作清理多余的 PGLog。通常情况下，在同一个 PG 的不同副本中的 PGLog 应该是一致的，故障发生后，不同副本的 PGLog 可能会处于不一致的状态。

二.OSD 的故障种类

故障 A：一个正常的 OSD 因为所在的设备发生异常，导致 OSD 不能正常工作，OSD 被标记为 down，某个 OSD 被设置为 Down 状态只是简单触发其承载的 PG 通过 Peering 进行 Primary 转换（如果需要），以尽快恢复对外业务（此时 PG 工作在降级状态），后续 OSD 在设定的时间内，它又可以正常的工作，这时会添加会集群中；

故障 B：当某个 OSD 处于 Down 状态足够长时间（例如超过 600s），才有理由认为对应的 OSD 已经无法完全恢复，此时出于数据安全性考虑，Monitor 会将其进一步设置为 Out。

三.OSD 的故障处理

故障 A：OSD 又重新回到 PG 当中去，这时需要判断一下，如果 OSD 能够进行增量恢复则进行增量恢复，否则进行全量恢复。（增量恢复：是指恢复 OSD 出现异常的期间，PG 内发生变化的 object。全量恢复：是指将 PG 内的全部 object 进行恢复）。需要全量恢复的操作叫做 backfill 操作。需要增量恢复的操作叫做 recovery 操作。Peering 完成后，PG 进入 Active 状态，并根据 PG 的副本状态将自己标记为 Degraded/Undersized 状态，在 Degraded 状态下，PGLog 存储的日志数量默认会扩展到 10000 条记录，提供更多的数据记录便于副本节点上线后的数据恢复。进入 Active 状态后，PG 可用并开始接受数据 IO 的请求，并根据 Peering 的信息决定是否进行 Recovery 和 Backfill 操作。Primary PG 将根据对象的缺失列表进行具体对象的数据拷贝，对于 Replica PG 缺失的数据 Primary 会通过 Push 操作推送缺失数据，对于 Primary PG 缺失的数据会通过 Pull 操作从副本获取缺失数据。在恢复操作过程中，PG 会传输完整 4M 大小的对象。对于无法依靠 PGLog 进行 Recovery 的，PG 将进行 Backfill 操作，进行数据的全量拷贝。待各个副本的数据完全同步后，PG 被标记为 Clean 状态，副本数据保持一致，数据恢复完成。下图为 PG 状态机。

故障 B：这些 PG 会重新分配副本到其他 OSD 上。上面的流程的前提故障 OSD 在 PGLog 保存的最大条目数以内加入集群都会利用 PGLog 恢复，那么如果在 N 天之后或者发生了永久故障需要新盘加入集群时，PGLog 就无法起到恢复数据的作用，这时候就需要 Backfill(全量拷贝) 流程介入。Backfill 会将所有数据复制到新上线的 PG，这里的流程跟上述过程基本一致，唯一的差异就是在 Primary PG 发现 PGLog 已经不足以恢复数据时，这时候同样分为两种情况：

（1）故障 OSD 拥有 Primary PG，该 PG 在对比 PGLog 后发现需要全量拷贝数据，那么毫无疑问 Primary PG 在复制期间已经无法处理请求，它会发送一个特殊请求给 Monitor 告知自己需要全量复制，需要将 Replicate PG 临时性提升为 Primary，等到自己完成了复制过程才会重新接管 Primary 角色

（2）故障 OSD 拥有 Replicate PG，该 PG 的 Primary 角色会发起 backfill 流程向该 PG 复制数据，由于故障 OSD 是 Replicate 角色，因此不影响正常 IO 的处理。

一个 PG 中包含的 object 数量是不限制的，这时会将 PG 中所有的 object 进行复制，可能会产生很大的数据复制，因此为了避免产生数据迁移风暴，Monitor 通过 一个名为 mon_osd_down_out_subtree_limit 的配置项来限制自动数据迁移的粒度，例如设置为主机，则当某个主机上的 OSD 全部宕掉时，这些 OSD 不再会被自动标记为 Out，也就无法自动进行数据迁移，从而避免数据迁移风暴。

.扩容时的数据再均衡

当 Ceph OSD 添加到 Ceph 存储集群时，集群映射会使用新的 OSD 进行更新。因为在 CRUSH 算法计算 PG 到 OSD 的映时，OSD_ID 是参数之一，新加入的 OSD 改变了计算的输入，因此会有一部分 PG 根据 CRUSH 算法的计算原则进行迁移。下图粗略的展现了数据再均衡过程，假设之前某个 PG 计算出来 straw 值（CRUSH 算法结果，PG 选择 OSD 中最大的结果进行映射）分别为：straw1，straw2，straw3，增加 OSD4 之后计算，只有当 straw4 > max(straw1, straw2, straw3)，这种情况需要将 PG 数据迁移到 OSD4 上，会有 w4/(w1+w2+w3+w4)的 PG 移动到 osd4 上（w 为 ODS 权重），随着 PG 数量增多，理论上 OSD 上的 PG 分布比例为 w1:w2:w3:w4。