Ceph Monitor基础架构与模块详解
转自：https://www.ustack.com/blog/ceph-monitor/
Ceph rados cluster离不开Monitor，如果没有Monitor，则Ceph将无法执行一条简单的命令。Monitor由于其特殊性，了解它，对于我们深入理解Ceph，保证Ceph的稳定性，有很大帮助。
Monitor 基本架构介绍
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的信息，为了后续处理请求能达成一致。
