作为一个面向大规模的分布式存储系统,故障处理是作为一个常态异常处理。Ceph 为了细化和保证故障发生和故障恢复的集群高可用性和一致性,在设计上将故障分为两类:
Ceph 将所有数据域划分成若干个 PG(Placement Group)管理,每个 PG 都存活在一个 OSD 节点上,因此 PG 是管理、恢复数据的主体。而 Monitor 节点不参与用户数据的任何操作,只提供了 PG 选举的协调作用。PG 所属数据的处理和恢复都由 PG 本身进行协调。
首先这里考虑临时性故障的处理,Ceph 引入了 PGLog 的概念,顾名思义,PGLog 由 PG 维护并且记录了该 PG 所有的操作,其非常类似于关系型数据库领域的 undo log,同时需要将 PGLog 与 Journal 概念划分清楚,Journal 是底层单机存储模块用来维护事务一致性的,它是数据库领域的 redo log。undo log 和 redo log 在数据库的作用与 Ceph 的 PGLog 和 Journal 作用是一致的。PGLog 通常只保存 PG 最近几千条的操作记录,但是在 PG 处于 Degraded 状态时,PGLog 会保存更多的日志条目期望能在故障 PG 重新上线后用来恢复数据。下面来简单描述故障发生导致 OSD 下线的流程:
故障发生后,如果一定时间后重新上线故障 OSD,那么 PG 会进行以下流程:
第三步是 PG 唯一不处理请求的阶段,它通常会在 1s 内完成来减少不可用时间。但是这里仍然有其他问题,比如在恢复期间故障 OSD 会维护 missing 列表,如果 IO 正好是处于 missing 列表的数据,那么 PG 会进行恢复数据的“插队”操作,主动将该 IO 涉及的数据从 Replicate PG 拉过来,提前恢复该部分数据。这个情况造成的延迟大概在几十毫米,通常来说是可接受的。
上面的流程的前提故障 OSD 在 PGLog 保存的最大条目数以内加入集群都会利用 PGLog 恢复,那么如果在 N 天之后或者发生了永久故障需要新盘加入集群时,PGLog 就无法起到恢复数据的作用,这时候就需要 backfill(全量拷贝) 流程介入。backfill 会将所有数据复制到新上线的 PG,这里的流程跟上述过程基本一致,唯一的差异就是在第三步 Primary PG 发现 PGLog 已经不足以恢复数据时,这时候同样分为两种情况:
除此之外,恢复数据还需要涉及到恢复数据的带宽控制、优先级等细节问题,这里就不一一赘述了。
小结
总的来说,Ceph 的恢复模块设计原则是在保证数据强一致性的前提下,尽量细化恢复过程来提高数据可用性(请求能得到及时处理),这个细化过程势必带来了极大的复杂性,因此恢复模块实际上也是 Ceph 最复杂的设计之一,值得存储系统领域的开发者借鉴。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞1
添加新评论0 条评论