Ceph Monitor的数据管理

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

Monitor管理了Ceph的状态信息，维护着Ceph中各个成员的关系，这些信息都是存放在leveldb中的，但是这些数据是如何生成的？又是如何消亡的。本文旨在展现Ceph monitor中数据的生老病死，带领读者走入Monitor的世界。

数据概览

首先我们分析的版本是0.94.7的版本，也就是目前Hammer最新的版本。对于leveldb中的数据，我们需要来一个感性的认识，请看下面数据，由于数据太多这里仅仅列出了key：

可以看到这里有paxos，有monmap，osdmap，mdsmap，auth，logm，和上一篇（Ceph Monitor基础架构与模块详解）中的Monitor的架构图很像。paxos记录了每次propose的value，具体可以这么来看：

以paxos:1869为例，paxos为prefix，1869为key。可以将不同的prefix当做不同的表，里面的key是主键，其存储的值是value，这里paxos:1869存储的就是Monitor一致同意的1869次决议。所有的状态的变化都是从这个决议里产生的。
那我们有什么方式可以查看决议的内容呢？我们可以通过如下命令先将数据从leveldb中导出来：

然后使用ceph-dencoder工具来查看：

从上面的数据输出我们可以得出一下几点：

• paxos:1869存储的是MonitorDBStore::Transaction序列化后的数据
• Monitor的Transaction和Osd的Transaction类似，都封装了多个op的操作
• log通过paxos来保持一致性，所以这里有，同理osdmap，monmap，pgmap等都应该Transaction里
• 这里仅仅是paxos决议的值，但是上面有osdmap的key，那么osdmap:num的val应该也是和paxos里相应的内容一样
• Paxos应该有Trim机制，因为如果数据一致这么存下去，不是办法

Paxos决议流程

到这里需要讲一下Paxos算法，因为Monitor里面数据的更新操作都是通过Paxos决议来完成的，也就是说Paxos掌管着Monitor数据的“生”。

Paxos解决了什么问题？
Paxos算法解决了分布式环境中一个不变量的值的一致性问题。

解决了一个值的问题有用吗？
我们的决议号就是这个变量。里面存放了决议的内容。决议内容通过之后，就把其写入数据库。我们可以将无数内容放到这个变量的值里面。有什么放不进去的吗？没有！当我们能够在分布式环境中确定一个变量的值的时候，已经足够我们使用了。

为什么是一个不变量的值？
这个不变量可以理解为C语言中的常量，一旦确定之后就不能改变，这里的不变就是一旦决议通过之后，无论发生什么情况，决议n的值还是当初通过的那个值。
但是我们怎么用呢？都不变了，我们用它干嘛？其实从上面的解释就已经可以看出来，我们说了是一个不变量的值，并不是一直就是一个变量，决议n的值确定了之后，我们可以再决议n+1的值。Ceph也正是这么用的，从上面的list出来的内容就可以大致了解。

Monitor更新一个值的流程：

1、Leader

1）设置new_value =v，v中值就是我们上面看到的paxos:1869中的值，都是kv。
2）将自己加入到同意者集合。
3）生成MonitorDBStore::Transaction， 以paxos为前缀，last_commited+1 的key来将v写入到leveldb中，同时更新pending_v，和pending_pn。
4）将new_value, last_commited和accepted_pn发送给quorum中的所有成员。

2、Peon

1）判断自己的accepted_pn和Leader发送过来的accepted_pn是否相等，如果小于就忽略，认为是旧一轮的决议。
2）判断自己last_commited是否和leader发送过来的相关，如果不相关，就是出现了不一致，直接assert。
3）同Leader中的3）。
4）将accpted_pn 和 last_commited发送给Leader。

3、Leader

1）判断Peon发送过来的pn是不是和自己的accepted_pn一致，如果不等可能有则返回。
2）判断last_commited，如果Peon发送过来的last_commited比last_commted -1 小，则认为是旧一轮的消息，丢弃。
3）判断Peon是否在同意者结合，如果不在就加入，如果在，说明一个Peon发送了两次accept消息，Leader直接assert。
4）当接受者结合和quorum结合一样的时候，也就是大多数人都同意了，Leader提交决议。
5）更新leveldb中的last_commited为last_commited + 1。
6）将new_value中的数据都展开封装成transaction，然后写入，插入回调。
7）当Leader完成本地的提交之后，调用回调向quorum中的所有成员发送commit消息 。

4、Peon

1）在接收到commit消息之后，进行内部提交。

这里有几点需要说明的是：
在决议的过程中其实提交了Leader提交了两次，一次是直接将决议当做bl写入paxos的prefix中，另一次是将bl解析出来（bl里的内容都是封装的小的op操作）在写入bl里封装的prefix的库中。
所有的update操作的请求都会路由到Leader，也就是说无论你有3个，或者5个，在处理update请求的时候只会是1个。

OSDMap的管理

这里我们以OSDMap为例，来看看它是如何从生成到进库的。
当有osd up或者down的时候，monitor会感知到。当消息走到prepare_update的时候，会在各自的prepare函数经过各种处理，最终会将更新纪录到pending_inc中。因为OSDMap的更新全纪录在pending_inc这个变量里。然后在dispatch中，会判断是不是要走决议流程，如果走了决议流程之后会首先将pending_inc中的内容encode进transaction，这里调用了一个很重要的函数encode_pending。在这个函数里将pending_inc中该有的内容都塞进了transaction。当有了这个transaction之后，就是会走我们上面讲的Paxos决议流程了。最终这些决议会持久化到leveldb中。

从上面我们可以看到Monitor的架构，这里虽然讲的是OSDMonitor怎么处理消息的，但是MDSMonitor，MonMapMonitor都是一样的。Update操作改变自己的pending_inc，然后在encode_pending的时候生成transaction，然后就是走决议流程。

同样可以通过以下命令将osdmap拿出来看看：

总结
本文首先通过工具从leveldb中将monitor的数据拿出来，大概了解了Monitor的数据内容，然后分析了生成数据的流程–Paxos决议，最后使用一个简单的例子OSDMap来讲述了OSDMap数据是如何生成和存储的。希望本文能够帮助读者了解Mon，从而对Ceph有更深刻的理解，以便大家开发出更好的产品，以及对客户更优质的服务。