这篇文章将为大家详细讲解有关ceph monitor的示例分析,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。
Ceph monitor分析
一、monitor简介
monitor作为ceph集群核心服务,负责自维护ceph集群健康状态,rados集群元数据mdsmap、monmap、osdmap、log、auth、health等,基于改进paxos算法,保证集群节点间的数据状态在同一时刻一致性。总的来说Monitor负责收集集群信息,更新集群信息,发布集群信息。

图 1 monito架构图
可以看出monitor的内部其实是一个分布式kv数据库。从下往上分别是MonitorDBStore、Paxos和PaxosService。PaxosService负责保证每次都只会有一个提案进入paxos流程。Paxos模块具体实现了multi-Paxos算法。MonitorDBStore是对底层DB的抽象封装,将DB的基本操作事务封装成统一接口,当前DB默认使用rocksdb。
二、monitor启动过程
monitor服务启动过程主要包括:加载基本配置、检查和加载db、初始化网络模块、mon注册网络监听、monitor bootstrap启动。

图 3 prepare阶段a

图 5 accept阶段a

图 7 learn阶段
2)Multi paxos:
原始的Paxos算法(Basic Paxos)只能对一个值形成决议,决议的形成至少需要两次网络来回,在高并发情况下可能需要更多的网络来回,极端情况下甚至可能形成活锁。如果想连续确定多个值,Basic Paxos搞不定了。因此Basic Paxos几乎只是用来做理论研究,并不直接应用在实际工程中。 实际应用中几乎都需要连续确定多个值,而且希望能有更高的效率。Multi-Paxos正是为解决此问题而提出。Multi-Paxos基于Basic Paxos做了两点改进:
1、针对每一个要确定的值,运行一次Paxos算法实例(Instance),形成决议。
2、在所有Proposers中选举一个Leader,由Leader唯一地提交Proposal给Acceptors进行表决。这样没有Proposer竞争,解决了活锁问题。在系统中仅有一个Leader进行Value提交的情况下,Prepare阶段就可以跳过,从而将两阶段变为一阶段,提高效率。
Ceph monitor采用的是Multi paxos算法。
monitor选举过程
monitor::bootstrap()是选举入口,整个过程也由一系列状态变化而成。每个Monitor启动后,根据配置文件中的主机ip列表,发现其他monitor并且获取其他节点最新日志版本号,根据版本号大小判断是否需要从其他节点拉取db数据做同步,然后选出leader和peon,再做recovery,最后根据收到的信号shutdown。

图 9 probe过程

图11 recovery流程
![]()
图 12 提案提交过程
可以看到,monitor启动经历了probe、sync数据、选举、recovery过程,其中recovery涉及到了提案的提交动作,后续所有的monitor的提案提交都是通过begin()完成的。这里来看,paxos的第一阶段就是在bootstrap()里完成,后续提案提交直接可以通过leader发给peon来完成,符合multi-paxos的描述
关于“ceph monitor的示例分析”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,使各位可以学到更多知识,如果觉得文章不错,请把它分享出去让更多的人看到。