ceph Monitor原理和代码流程介绍

Monitor介绍

Monitor在Ceph集群中扮演管理者的角色，维护了整个集群的状态，集群的状态被抽象成几个Map对象，包括monmap、osdmap、mdsmap、authmap、logmap等，保证集群的相关组件在同一时刻能够达成一致，相当于领导层。其中osdmap的更新采用了类似于灰度发布的机制，这会造成在某一时刻集群中所有OSD或Client持有的osdmap的版本可能不一致。

一句话总结Monitor的作用就是：负责收集集群信息、更新集群信息以及发布集群信息。

如果Monitor只有一个，那么事情就会容易很多，集群信息的增删改查都由这一个Monitor完成，但是这样会导致单点故障或性能热点问题，作为分布式解决方案Ceph会部署多个Monitor来规避单点故障。这样就引入了新的问题，例如：如何管理多个Monitor节点？数据谁来更新？多个Monitor之间如何同步数据？如何保持数据的一致性？等等。这样在Ceph集群中，Monitor做的事情就可以概况成两点：1）管理好自己：怎么更新数据？怎么同步数据？等。2）管理好集群：哪些数据，存在哪里？数据一致性等。

Monitor的基本架构

Ceph的Monitor维护了一份集群Map的主拷贝，Ceph通常包含一系列的Monitors，映射给Client。一个Monitor包含K/V store、Paxos、PaxosService。K/V store用于持久化存储Monitor数据，Paxos提供了对PaxosService的数据访问逻辑的一致性，每个PaxosService代表了集群的一种状态信息，以key-value的形式写入PaxosService层。

Monitor初始化主要流程：

Monitor会在启动或重启时，Connect连接monmap中的其他Monitor。如果第一次启动，Monitor会根据配置文件构建monmap，并存储到MonitorDBStore数据库中。如果不是第一次启动，Monitor会从MonitorDBStore数据库中读取monmap。Messenger是网络线程模块，Monitor会初始化它，并注册请求的回调处理函数。bootstrap处理会多次调用，在Monitor整个生命周期中非常重要。bootstrap之后，Monitor处于STATE_PROBING状态，Monitor会与其他Monitors通信并同步信息，然后集群开始选举，决定Monitor的角色。

Monitor状态转换：

STATE_PROBING：boostrap过程中节点间相互探测，发现数据差距；

STATE_SYNCHRONIZING：当数据差距较大无法通过后续机制补齐时，进行全同步；
STATE_ELECTING：Monitor在进行选主；
STATE_LEADER：当前Monitor成为Leader；
STATE_PEON：非Leader节点；

分布式系统的数据一致性

对分布式系统来说，数据的一致性尤为重要，在monitor节点中，有Leader和Peon两种角色，客户端的读操作Leader和Peon都能处理，而写操作都发送给Leader节点，由Leader节点分发给Peon节点。Paxos算法保证了一次修改操作只能批准一个值，从而保证分布式系统的数据一致性。

节点之间的通信模型

通常有两种：共享内存和消息传递，Paxos是基于消息传递的通信模型。

Paxos的转换时机：

#1. 在monitor启动时，完成Paxos的初始化操作；

#2. 在monitor进入bootstrap时，Paxos进行restart操作；

#3. monitor根据选举结果，Paxos初始化为对应的Leader或Peon；

#4. monitor异常后，Paxos进入recovery阶段；

#5. monitor运行过程中，进行Paxos决议；

概念解释

Epoch值

每次选举产生新的Leader，也会产生新的Epoch，不选举则不会改变Epoch。Leader发送的所有消息，都会带有这个Epoch，如果网络分区等现象，有新的选举发生，则根据Epoch就发现Leader已经变了。没有Leader则不需要Epoch。

Rank值

Rank值可以理解为ID值，代表主机节点在monmap中的位置，跟IP地址有关，如果主机还不在monmap中，此时rank=-1。rank值在选举中会用到，Leader的选择是根据rank值来定的，规则是rank值小的为Leader。

PN(Proposal Number)

Leader当选后，首先执行一次Phase 1过程，以确定PN。在其为Leader期间，所有的Phase 2操作都使用这个PN，这样就省略了大量的Phase 1操作，这也是Paxos能够减小网络开销的原因。PN是必须的，无论是否有Leader，都必须有PN。

Version

可以理解成Paxos的instance ID。

"uncommitted"开头的值，所有的提案都正常commit，就不会存在，如：正常关机，只有在异常情况下，才会存储尚未提交的提案。

Paxos的几个状态：

1）Recovery状态：Leader选举结束后进入该状态，目的是同步Quorum成员间的状态。

2）Active状态：空闲状态，没有审批提案，等待。

3）Updating状态：正在执行审批提案。

4）Updating Previous状态：正在审批上次的提案，即：Leader选举之前旧Leader提出但尚未批准的提案。

5）Writing状态：提交本次提案数据。

6）Writing Previous状态：提交上次尚未批准的提案数据。

7）Refresh状态：提案已完成提交。

Monitor的消息分发

Monitor进程只创建了一个Messenger，也就意味着它只有一个dispatch_queue队列和一个dispatcher线程，所有的请求都会排队。Monitor还会初始化一个timer，其会创建一个线程来处理所有的消息超时事件，包括probe、propose、lease等消息，所以这些消息的处理也是串行的。

Monitor如何处理Client请求的？

当Client发送请求给Monitor时，Monitor首先分发请求给相应的PaxosService，PaxosService会根据读操作或写操作调用方法，PaxosService决定是否触发propose处理流程。