cephmonitor的示例分析

这篇文章将为大家详细讲解有关ceph monitor的示例分析,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。

创新互联专注于济水街道网站建设服务及定制,我们拥有丰富的企业做网站经验。 热诚为您提供济水街道营销型网站建设,济水街道网站制作、济水街道网页设计、济水街道网站官网定制、小程序定制开发服务,打造济水街道网络公司原创品牌,更为您提供济水街道网站排名全网营销落地服务。

Ceph monitor分析

一、monitor简介

monitor作为ceph集群核心服务,负责自维护ceph集群健康状态,rados集群元数据mdsmap、monmap、osdmap、log、auth、health等,基于改进paxos算法,保证集群节点间的数据状态在同一时刻一致性。总的来说Monitor负责收集集群信息,更新集群信息,发布集群信息。

ceph monitor的示例分析

图 1 monito架构图

可以看出monitor的内部其实是一个分布式kv数据库。从下往上分别是MonitorDBStore、Paxos和PaxosService。PaxosService负责保证每次都只会有一个提案进入paxos流程。Paxos模块具体实现了multi-Paxos算法。MonitorDBStore是对底层DB的抽象封装,将DB的基本操作事务封装成统一接口,当前DB默认使用rocksdb。

二、monitor启动过程

monitor服务启动过程主要包括:加载基本配置、检查和加载db、初始化网络模块、mon注册网络监听、monitor bootstrap启动。

ceph monitor的示例分析

图 3 prepare阶段a

ceph monitor的示例分析

图 5 accept阶段a

ceph monitor的示例分析

图 7 learn阶段

2)Multi paxos:

原始的Paxos算法(Basic Paxos)只能对一个值形成决议,决议的形成至少需要两次网络来回,在高并发情况下可能需要更多的网络来回,极端情况下甚至可能形成活锁。如果想连续确定多个值,Basic Paxos搞不定了。因此Basic Paxos几乎只是用来做理论研究,并不直接应用在实际工程中。 实际应用中几乎都需要连续确定多个值,而且希望能有更高的效率。Multi-Paxos正是为解决此问题而提出。Multi-Paxos基于Basic Paxos做了两点改进:

1、针对每一个要确定的值,运行一次Paxos算法实例(Instance),形成决议。

2、在所有Proposers中选举一个Leader,由Leader唯一地提交Proposal给Acceptors进行表决。这样没有Proposer竞争,解决了活锁问题。在系统中仅有一个Leader进行Value提交的情况下,Prepare阶段就可以跳过,从而将两阶段变为一阶段,提高效率。

Ceph monitor采用的是Multi paxos算法。

  1. monitor选举过程

    monitor::bootstrap()是选举入口,整个过程也由一系列状态变化而成。每个Monitor启动后,根据配置文件中的主机ip列表,发现其他monitor并且获取其他节点最新日志版本号,根据版本号大小判断是否需要从其他节点拉取db数据做同步,然后选出leader和peon,再做recovery,最后根据收到的信号shutdown。

    ceph monitor的示例分析

    图 9 probe过程

    • 完成同步后,如果回复数超过节点数一半就开始选举,节点进入STATE_ELECTING状态。先广播OP_PROPOSE消息,对端接收到消息,如果发现自身rank大于发送端rank值,则回复OP_ACK消息。这样的话rank最小的节点会收到最多的ack消息,如果收到的ack消息数与当前活动节点数相同则本端节点成为leader,然后再通知各个节点本端胜出,其他节点将成为peon。

    ceph monitor的示例分析

    图11 recovery流程

    • Monitor中实现paxos的提交过程是由begin()来完成。Leader首先更新自己的pending_v和pending_pn,然后发送OP_BEGIN消息到所有的peon节点,如果peon的accepted_pn小于leader发送的,则接受这个提案,将数据保存到本地,并且回复OP_ACCEPT消息。Leader收到的accept的个数等于集群的quorum,则将提案提交到leader本地,并且通知各个peon去完成commit操作。同时更新租约extend_lease(),更新租约后leader和peon之间会有个定时任务,leader会默认每3秒更新一次租约,超时10s则会重新选举,peon同样没有收到lease消息,超过10s也会重新选举。

    图 12 提案提交过程

    可以看到,monitor启动经历了probe、sync数据、选举、recovery过程,其中recovery涉及到了提案的提交动作,后续所有的monitor的提案提交都是通过begin()完成的。这里来看,paxos的第一阶段就是在bootstrap()里完成,后续提案提交直接可以通过leader发给peon来完成,符合multi-paxos的描述

    关于“ceph monitor的示例分析”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,使各位可以学到更多知识,如果觉得文章不错,请把它分享出去让更多的人看到。


    网页题目:cephmonitor的示例分析
    本文路径:http://cdiso.cn/article/gdcicj.html

其他资讯