ceph分布式存储系统Monitor源码分析总结Word文档格式.docx

1、（5） PG：全称Placement Grouops，是一个逻辑的概念，一个PG包含多个OSD。引入PG这一层其实是为了更好的分配数据和定位数据。Ceph存储集群中主要的服务有Monitor，OSD，MDS。其通信框架如下图所示：图1.1 ceph通信框架图 Ceph Async模型里，一个Worker类对应一个工作线程和一个事件中心EventCenter。 每个socket对应的AsyncConnection在创建时根据负载均衡绑定到对应的Worker中，以后都由该Worker处理该AsyncConnection上的所有的读写事件。本文主要是在阅读Monitor源码中的一些总结，后续可供其他

2、新入职员工阅读参考。2. 类关系3. 启动顺序一般程序分为两种。一种是可执行程序，一种是对外提供接口服务的库程序。对于代码阅读中首先弄明白当前代码是可执行程序还是库程序。对于monitor，核心业务在libmaon.a中，以静态库的形式提供，通过icfs-mon可执行程序进行调用。icfs-mon则是monitor的可执行程序。对于可执行程序的源码阅读，首先要找到main函数，一般main函数的都不大，会在其中执行基本的初始化操作，icfs-mon的main函数就在icfs_mon.cc中。icfs_min.cc main函数中主要进行启动参数处理，配置文件加载，数据库加载，创建消息实例，创建

3、monitor实例，monitor初始化等，基本流程如下如图所示。对于库程序源码主要从对外提供的头文件入手，一般也会存在初始化，注册接口等。图3.2mon启动顺序4. 基础业务Monitor的主要任务就是维护集群视图（各种map）的一致性，在维护一致性的时候使用了Paxos协议，并将其实例化到数据库中，方便后续的访问和使用。维护视图一致性的过程中在monitor内部主要进行的流程大概有bootstrap，数据同据（sync），选举，数据收集，议案下发。正常流程的议案流程一般是在monitor处理完update请求后触发。在icfs-mon.cc的main函数中创建monitor后随即进行预初始

4、化（preinit）和初始化（init）操作。preinit阶段主要初始化了paxos和各个paxosservice以及health_monitor。Init阶段初始化timer定时器、将monitor添加到dispatcher列表中并进行bootstrap（）。从bootstrap（）开始也就进入了Monitor的选举流程。以下结合代码简单进行介绍。3.1 bootstrap 每次monitor启动时都会按照monmap中的服务器地址去连接其他monitor，并同步数据，bootstrap的第一个目的就是从其他服务拉缺失的paxos log或者全量复制数据库，其次是在必要时形成多数派建立一个

5、paxos集群或者加入到已有的多数派中。Bootstrap中具体要做的几件事情：（1） 开始时设置monitor的状态为STATA_PROBING；（2） 然后判断是否设置了mon_compact_on_bootstrap参数，如果设置了，就执行compact操作，对monitor的store进行压缩；（3） 如果集群只有一个monitor，则该monitor直接胜出；（4） 根据mon_probe_timeout重置probe_timeout事件的时间，如果在超时时间内没有取消该事件（handle_prope_reply后会取消，因为已经进行了响应），则进行超时事件处理；（5） 如果moni

6、tor在monmap中，则将其将如到outside_quorum集合中；（6） 根据monmap，向其他peer一一发送MMonProbe消息；对端的monitor收到probe的消息后进行handle_probe_probe处理：（1） 如果missing feature，发送OP_MISSING_FEATURES的信息，结束；（2） 若message的发送方的版本比自己新，无法通过paxos算法部分做数据修复，需要重新bootstrap（）从对方主动拉数据；（3） 正常流程，汇报目前的paxos状态，last_commit，first_commit信息，发送OP_REPLY消息给发送方；（

7、4） 如果发现了一个peer，那么extra_probe_peers.insert（m-get_source_addr（），想不出什么场景？发送探测包的monitor节点在最大超时时间内收到OP_REPLY，会调用handle_probe_reply函数进行下一步处理。如果未收到replay响应包执行超时处理。（1） 先判断当前monitor所处的状态如果是Probing或者Electing，则直接退出；（2） 比对对方的monmap和自己monmap的epoch版本，如果自己的monmap版本低，则更新自己的map，然后重新进入bootstrap（）阶段；（3） 如果当前Monitor处于s

8、ynchronizing阶段，则直接返回；（4） 比对彼此的paxos的版本，如果对方的paxos版本较低，否则判断是否需要进行data的sync。这里有两种情况，如果自己的paxos版本是比对方的paxos_first_version纪录的版本低，则会进行sync操作。如果自己paxos的版本和对方的版本相差太远超过了设置的参数paxos_max_join_drift的值，也会先进行数据的sync而不会触发重新的选举操作；（5） 如果从返回的消息中判断已经有一个quorum存在了，自己也在monmap中并且自己的ip地址不为空，说明自己已经是集群的一员了，则直接发起一个选举。否则，会请求加入

9、这个quorum；（6） 如果没有现成的quorum，并且自己在monmap中，则把peer添加到outside_quorum的集合中。如果此时outside_quorum中的成员大于等于monmap-size（） / 2 + 1时，开始选举，否则返回，等待条件满足。注意：sync_last_committed_floor和last_commited的区别，一般情况下两者是相等的，sync_last_committed_floor是在last_committed丢失或者获取异常等极端情况下的一种保护措施，防止从旧的数据进行同步。3.2 sync 对于sync（数据同步）操作前面已经进行了介绍，

10、数据同步分为两种场景：一种是在自己的paxos版本是比对方的paxos_first_version纪录的版本低，进行全量数据同步，一种是自己paxos的版本和对方的版本相差超过了设置的参数paxos_max_join_drift，也会进行数据的sync，此时进行的是部分数据同步。 如上图所示，消息OP_GET_COOKIE_FULL和OP_GET_COOKIE_RECENT分别代表全量同步和增量同步，如果是增量同步只需给对端携带last_committed。对端的handle_sync_get_cookie负责生成cookie信息，handle_sync_get_cookie函数对请求同步方来

11、讲只能触发一次，也就是说对于cookie对数据同步是唯一的，后续一步步数据同步都使用该cookie（数据提供方通过cookie来识别是mon）。通过OP_COOKIE消息将cookie应答给数据同步请求方。消息OP_GET_COOKIE_FULL/OP_GET_COOKIE_RECENT，OP_COOKIE进行的是数据同步的准备步骤，后续的OP_GET_CHUNK，OP_CHUNK，OP_LAST_CHUNK才是真正的数据同步。该步骤相对简单，通过与阅读源码能够理解其内部实现，简单描述下分块同步的逻辑，以下是数据分块的源码。int left = g_conf-mon_sync_max_payl

12、oad_size; while （sp.last_committed get_version（） & left 0） bufferlist bl; sp.last_committed+; int err = store-get（paxos-get_name（）, sp.last_committed, bl）; assert（err = 0）; tx-put（paxos- left -= bl.length（）; dout（20） _func_ including paxos state last_committed = sp.last_committed; if （sp.full & sp.s

13、ynchronizer-get_chunk_tx（tx, left）; sp.last_key = sp.synchronizer-get_last_key（）;last_key = sp.last_key; if （sp.full &has_next_chunk（） | sp.last_committed get_version（） dout（10） chunk, through version key sp.last_key mon_sync_provider_kill_at != 3）; / clean up our local state sync_providers.erase（sp

14、.cookie）;（1） int left = g_conf-获取每次进行数据同步的最大数据大小，在单次数据同步前获取；（2） while （sp.last_committed mon_sync_max_payload_size；（3） 在上述while循环中进行同步数据块的组装，每次循环中数据同步方的paxos版本号（sp.last_committed）进行递增，单次同步剩余数据的大小（left）进行递减，直到不能满足循环条件退出循环；（4） if （sp.full & 0） 说明是全量同步，且left大于0，代表是最后一块数据，进行数据组装；（5） if （sp.full &sp.last

15、_committed = （mon-monmap-size（）-mon-off_mon_rank.size（） & （acked_me.size（）-stop_acked_me.size（） （mon-size（）/2）off_mon_rank中记录的是因为网络原因连不上的mon，stop_acked_me记录的即将异常停止的mon。此时已经选举出了leader，leader进入Elector:victory（）：（1） 将acked_me中的成员加入到quorum中，并且将election epoch的值加一使其变成偶数，标志选举过程结束；（2） 向quorum中的所有成员发送MMonEle

16、ction:OP_VICTORY，消息通知大家选举结束，附带quorum；并告诉monitor自己选举成功。设置自己的状态为STATE_LEADER，清空outside_quorum中的成员，调用paxos-leader_init（）初始化paxos，以及所有的paxos_service服务。在paxos的初始化中会设置paxos的状态为STATE_RECOVERING，并且调用Paxos:collect（）函数，同步mon之间的数据，这个在后面数据同步章节介绍；（3） 向stop_mon中的成员发送选举成功的消息（应该是尝试发送）各个peon收到MMonElection:OP_VICTORY

17、消息之后进入Elector:handle_victory（），处理也比较简单：（1） lection epoch设置成消息中的epoch值；（2） 进入Monitor:lose_election（），设置自己的状态为STATE_PEON，调用peon_init初始化paxos以及相关的paxosservice，更新logger信息；下图是选举过程的中主要函数调用图。3.4数据收集此时可能有人会存在一个疑问，在选举之前不是已经进行了sync数据同步了吗？为什么在选举结束后还要进行数据同步呢？我们可以翻到同步数据的章节在回忆以下，上述所说的同步分为两种，一种是全量一种是增量，全量和增量的同步时需要

18、满足一定的条件才会触发，如果没有触发全量同步，各个paxos间的版本差又在paxos_max_join_drift之内，中间可能会存在小版本数据的差异，那就需要在选举结束后在进行一下同步来解决这种小版本差的同步问题。Leader触发paxos:collect（）：（1） 设置STATE_RECOVERING状态；（2） 初始化uncommitted_v，uncommitted_pn，uncommitted_value，accepted_pn等值；（3） 携带last_committed，last_committed，accepted_pn向peon发送OP_COLLECT消息；（4） 设置数据

19、收集超时事件。Peon收到OP_COLLECT,进入函数paxos:handle_collect（MonOpRequestRef op）开始处理：（2） 如果自己的last_commited+1小于leader的first_committed，说明自己的版本远远落后leader，需要通过bootstrap主动同步；（3） 生成OP_LAST消息实例，如果自己的accepted_pn小于leader的accepted_pn，则接受并DB入库；（4） 如果leader的last_committed小于自己的，说明leader由数据缺失，通过share_state将缺失的数据补全；如果存在未提交的数

20、据，也进行数据不全，向leader发送OP_LAST消息。leader调用paxos:handle_last（MonOpRequestRef op），进行数据的恢复主要流程有：（1） 检测是否有peon节点的数据比自己新（store_state），并用need_refresh记录是否需要更新内存数据；（2） 检测peon的数据是否比自己的旧，如果旧向该peon发送OP_COMMIT消息让其同步数据；（3） 按照collect更新后，检测自己的pn是否为集群中的最大值，如果不是，更新pn为所集群中的最大值，重新collect；（4） 如果peon已经接受了自己的pn，则进行接受peon的数目进行

21、自增：num_last+,如果peon存在更新（或者跟自己相同）的未提交议案，则将peon的未提交信息同步更新自己（更新uncommitted_v，uncommitted_pn，uncmmitted_value）;（5） 如果接受自己pn的peon等于quorum成员个数，在存在未提交议案的情况下进进行议案下发（下节描述）；（6） 如果没有未提交的议案，直接进入extend_lease（）,然后刷新数据，开启新的议案周期。 数据同步的流程图和代码调用图如下所示。3.5议案下发 议案的propose主要在PaxosService的各种服务更新map，collect后有未提交的数据，Paxos以及

22、PaxosService对数据做trim时进行触发。 Map更新后进行议案propose的流程图如下： leader接收到修改请求的流程代码调用流程如下: leader调用paxos:begin（）:（1） 申请DB事务，存储pending_v，pending_pn，uncommitted_value等相关值，并进行DB存储，如果是单节点直接走commmit流程；（2） 向quorum成员发送OP_BEGIN消息，消息体中包含未提交的新值，last_committed以及accepted_pn;（3） 设置OP_BEGIN应答超时事件； peon调用Paxos:handle_begin（Mon

23、OpRequestRef op）响应提案：（1） 设置当前状态为STATE_UPDATING，存储数据，并进行事务提交；（2） 发送OP_ACCEPT给leader；Leader调用Paxos: handle_accept（MonOpRequestRef op）处理accept应答：（1） 对accept-pn 与accepted_pn以及accept-last_committed和last_committed进行检测；（2） 如果所有的monitor全部accept，执行commit_start（）;Paxos: commit_start中主要完成last_committed的本地存储，后端

24、DB存储完成后设置回调commit_finish，并取消accept的接受超时事件。commit_finish中主要完成以下几步操作：（1） 更新内存中的内存中的last_committed（last_committed+），刷新first_committed（从DB中读出）；（2） 通知quorum中其他peon成员提交完成，发送OP_COMMIT，包括议案提交的内容，accepted_pn和last_committed;（3） 设置状态为STATE_REFRESH，调用paxos:do_refresh（）进行所有map的内存更新（增量数据的同步）；（4） commit_propose函数触发等待commit完成的