Ceph Monitor and Paxos

Ceph Monitor集群作为Ceph中的元信息管理组件,基于改进的Paxos算法,对外提供一致性的元信息访问和更新服务。本文首先介绍Monitor在整个系统中的意义以及其反映出来的设计思路;之后更进一步介绍Monitor的任务及所维护数据;最后介绍其基于Paxos的实现细节和改进点。

定位

RADOS毋庸置疑是Ceph架构中的重中之重,Ceph所提供的对象存储,块存储及文件存储都无一例外的以RADOS为基石和最终的存储方案。论文中将RADOS描述为:”A Scalable, Reliable Storage Service for Petabyte-scaleStorage Clusters“,可见其对扩展性的重视。而与扩展性息息相关的首先就是分布式存储设计中必须要面对的元信息管理问题,即通过key找到数据所在的节点。

元信息管理的实现无外乎有以下两种方式,各自的优缺点也显而易见:

可以看出,无论哪种方式,都不可避免的限制了集群的可扩展性。针对这种情况,CEPH做出了自己的选择:有中心节点Monitor, 但其在以下几个方面不同于上面提到的有中心方式:

任务及数据

通过上面的描述可知,Montor负责维护整个集群的元信息及其更新,这里的元信息包括记录数据分布的OSDMap,记录Monitor状态的MonitorMap,以及Ceph集群所需要的其他信息。Ceph的设计思路是尽可能由更“智能”的OSD及Cilent来降低Monitor作为中心节点的负担,所以Monitor需要介入的场景并不太多,主要集中在以下几点:

实现简介

Ceph Monitor Architecture

Ceph Monitor的结构如上图所示,总体上分为PaxosService、Paxos、Leveldb三层,其中PaxosService层将不同的元信息封装成单条kv,Leveldb层则作为最终的数据和log存储。本文的关注重点在Paxos层,Paxos层对上层提供一致性的数据访问逻辑,在其看来所有的数据都是kv,上层的不同的元信息在这里共用同一个Paxos实例。基于Paxos算法,通过一系列的节点间通信来实现集群间一致性的读写以及故障检测和恢复。Paxos将整个过程分解为多个阶段,每个阶段达成一定的目的进而进入不同的状态。通过分层的思路使得整个实现相对简单清晰。

Boostrap阶段:

节点启动或者之后的多数故障情况发生时都会首先进入Boostrap过程,Boostrap过程会向其他节点发送探测消息,感知彼此的数据新旧,并对差距较大的节点进行全同步。经过这个过程可以有如下保证:

选主阶段:

Recovery阶段:

在这一过程中,刚选出的Leader收集Quorum当前的Commit位置,并更新整个集群。

读写阶段:

一致性与Paxos

为了使集群能够对外提供一致性的元信息管理服务,Monitor内部基于Paxos实现了自己的一致性算法。我们知道,Paxos论文中只着重介绍了集群如何对某一项提案达成一致,而距离真正的工程实现还有比较大的距离,众多的细节和方案需要实现中考虑和选择。通过上述对实现的简述,可以看出Ceph Monitor的Paxos实现版本中有许多自己的选择和权衡,总结如下:

本文重点介绍了Ceph Monitor的Paxos实现选择,并简要介绍了其实现阶段和目的。更详细的实现过程请见下一篇博文:Ceph Monitor实现

参考:

RADOS: A Scalable, Reliable Storage Service for Petabyte-scale Storage Clusters

CEPH: RELIABLE, SCALABLE, AND HIGH-PERFORMANCE DISTRIBUTED STORAGE

SOURCE CODE

分布式存储系统之元数据管理的思考

CEPH ARCHITECTURE

Table of Contents