标签：tran ldb 使用 ceph 解析 自己 展现 改变 大致
转自：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决议流程
到这里需要讲一下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有更深刻的理解，以便大家开发出更好的产品，以及对客户更优质的服务。
标签：tran ldb 使用 ceph 解析 自己 展现 改变 大致
原文地址：http://www.cnblogs.com/goldd/p/6610611.html
