Ceph Monitor基础架构与模块详解

转自:https://www.ustack.com/blog/ceph-monitor/

Ceph rados cluster离不开Monitor,如果没有Monitor,则Ceph将无法执行一条简单的命令。Monitor由于其特殊性,了解它,对于我们深入理解Ceph,保证Ceph的稳定性,有很大帮助。

Monitor 基本架构介绍

Monitor的基本架构图:

ceph monitor
Monitor的主要任务就是维护集群视图的一致性,在维护一致性的时候使用了Paxos协议,并将其实例化到数据库中,方便后续的访问。所以Monitor基本上是由三类结构支撑起来的,第一类是管理各种map和相关内容的PaxosService实例,第二类是Paxos实例,第三类是对k/v store的封装,即MonitorDBStore实例。

这样看起来,分工是很明确的,PaxosService handle client过来的请求,Paxos用来处理Paxos协议相关的东西,一般在选主和处理update请求的时候才会涉及,而在处理读请求的时候一般不会涉及。 MonitorDBStore是处理数据存储相关的封装,用来将update的数据进行持久化。

模块详解

1、AuthMonitor

用来提供对auth的一致性,比如keyring,这些keyring的生成都是要走Paxos流程的。

2、LogMonitor
将log的东西写入到monitor,且是一致的,就是所有的mon都有这个日志。比如我们经常看到的wrongly marked me down就是由clog利用monitor的log机制发送到monitor的,这样你在osd上能看到,monitor里也可以查看到。可以将一些重要信息保存下来。

3、MdsMonitor
用来维护Mds的状态,然后通过Mdsmap来进行更新。目前Mds默认有一个Active,其它的是Standby。

4、OsdMonitor
用来维护Osd的状态,当osd有up,down等状态变化的时候,会改变osdmap,然后将osdmap通过随机选择一个osd 的方式将osdmap扩散出去。其中有些细微差别,比如up的时候,除了随机选择的osd外,还会将osdmap直接发送给向mon报启动的osd。

5、PGMonitor
用来维护PG的state,这些信息是由Primary osd来通过tick发送给Mon的。

6、K/V Store
对K/V Store(这里使用的是LevelDB)的封装是主要是在MonitorDBStore这个类中,其中封装的Op主要有三类:

  • PUT操作
  • ERASE操作
  • COMPACT操作
    目前Monitor可以通过重启(mon_compact_on_start)或者命令(ceph compact)来进行Compact,所以Monitor的空间是不会用的那么多。

7、Paxos
Paxos实例主要是实现Paxos协议,然后应用于选主和处理update请求。
选主(三个mon同时启动):
1) mon 启动进入prboing
2) 当一个mon probing到超半数的mon的时候,就会发起选举
3) 发起选举的mon会向所有的mon发起propose
4) mon处理propose消息的时候会根据自己的rank来决定是重新发起选举还是defer
5) 如果所有的mon 都ack,或者过半数mon回复ack(超时后检查),则选举成功,自己进行leader init,向其它mon发victory消息
6) 其它mon则lose_election,进入peon_init。
7) 在此之后,leader会发collect消息去收集peon的信息,为了后续处理请求能达成一致。

posted @ 2017-03-24 11:30  gold叠  阅读(6258)  评论(0编辑  收藏  举报