前言：
Ceph将cluster map与placement rule合并为一张表称为crush map，作为集群表的一部分。由Monitor对集群表的副本进行维护和传播。Monitor是Paxos算法构建的具有分布式强一致性的小型集群(Paxos算法参考https://www.cnblogs.com/linbingdong/p/6253479.html)
因为Monitor采用负荷分担的方式工作和基于Paxos的分布式一致性算法，所以任何客户端和OSD都可以向集群中的任何Monitor索取或者请求更新集群表。Paxos机制决定了集群中超过半数Monitor处于活跃状态才可以正常工作。
工作方式
与Paxos选取主proposer类似，同时为了防止短时间内因网络或OSD故障导致大量的集群表更新请求而使得集群动荡。选出一个主Monitor后（同一时间只能由主Monitor发起集群表更新请求），对一段时间更新操作进行合并后发起单独的请求。
当前集群中活跃的Monitor包含Leader和Peon，通过选举出来的主Monitor称为Leader，其余为Peon。Leader“任职”的一段时间为租期，到期后Leader需要申请续租，否则任意一个Peon都可认为Leader异常，集群重新发起选举。如果Leader故障或有新的Monitor加入，则会重新开始Leader的选举（选举期间Monitor无法提供服务）。如果Leader发出续租请求后，某个Peon超时未回复，则认为该Peon异常，触发重新选举。
选出Leader后，它首先会向Peon获取当前集群中最新的集群表，Peon收到请求后进行应答并返回本地的集群表，如果2秒内集群中超过半数的Peon回复，那么Leader就会将集群表更新为最新。前面说过，任何客户端和OSD都可以向集群中任何Monitor请求更新集群表。但是如果Peon收到更新请求已经在当前最新的集群表中，则忽略该请求并返回最新的集群表。所有请求都被透传至Leader，由Leader合并后在整个集群发起同步。
Monitor除了维护集群表，还有健康状态，告警等信息的监控Monitor内部职责划分如下：
集群表
集群表由crush map和所有OSD的身份和状态信息组成，两者都是围绕OSD展开，所以集群表称为osdmap通过ceph osd dump获得集群表信息：
第一部分（集群表配置信息）
epoch 105
fsid cb309017-7bde-4799-861c-9b8e30f97a26
created 2020-04-03 11:50:19.091945
modified 2020-04-08 16:24:42.959505
flags sortbitwise,recovery_deletes,purged_snapdirs
crush_version 29
full_ratio 0.95
backfillfull_ratio 0.9
nearfull_ratio 0.85
require_min_compat_client jewel
min_compat_client jewel
require_osd_release luminous
各项含义如下：
-
epoch：本osdmap对应的版本号，单调递增
-
fsid：集群的唯一标识符
-
created：集群创建时间
-
modified：本osdmap（最新osdmap）创建时间
-
flags：集群级别的标志位
- sortbitwise：内部对象排序
- recovery_deletes 和 purged_snapdirs：从Luminous之前的版本升级，需要等待所有PG被scrub（可以强制或等待自动进行），如果没有这两个标志位会出现mon拒绝加入quorum的现象
- nearfull：集群中有osd快要达到85%（默认）使用量
- full：集群中有osd达到95%（默认）使用量，此时整个集群无法写入数据
- pauserd和pausewr：暂停对集群的读和写
- noup：不允许osd启动
- nodown：osd故障不报告，monitor不把osd标记为down
- noin：之前被标记为out的osd，重新启动后不允许他自动加入到集群
- noout：故障osd不被自动标记为out，与noin同理，避免集群被标记后立马进行数据均衡
- nobackfill,norecover：禁止集群数据恢复
- norebalance：进制集群自动进行数据平衡
-
full_ratio 0.95：osd用量为95%标记为满，数据无法写入
-
backfillfull_ratio 0.9：osd用量为90%时，拒绝backfill请求
-
nearfull_ratio 0.85：osd用量85%，发出nearfull告警
第二部分（osd详细信息）
osd.0 up in weight 1 recovery_weight 1 up_from 66978 up_thru 67011 down_at 66969 last_clean_interval [66666,66968) 10.10.10.125:6800/5123 10.10.10.125:6801/5123 10.10.10.125:6802/5123 10.10.10.125:6803/5123 exists,up a9c37496-142e-41b3-bd43-71902fae0f64
大意是说osd.0状态为up，权重为1；最近一次被标记为up(up_from)的epoch为66978，从up_from开始osd一直保持up的状态到up_thru对应的epoch为67011，也就是说在[66978,67011]期间osd一直是up状态；最近一次被标记为down(down_at)的epoch为66969；osd所在主机ip地址为10.10.10.125；osd唯一标识符为
a9c37496-142e-41b3-bd43-71902fae0f64
第三部分（存储池信息）
pool 8 'metadata' replicated size 2 min_size 1 crush_rule 1 object_hash rjenkins pg_num 1024 pgp_num 1024 last_change 73 flags hashpspool stripe_width 0 application cephfs
大意是说id为8的存储池，名称为metadata;采用两副本模式(replicated size 2)，最小要求单副本（即只存1份数据）；对象哈希算法使用rjenkins（object_hash rjenkins）；此存储池的pg数量为1024（pg_num 1024）；该存储池应用于cephfs（application cephfs，还有rbd，rgw等应用）
monmap
通过ceph mon dump获取monmap如下：
dumped monmap epoch 3
epoch 3
fsid cb309017-7bde-4799-861c-9b8e30f97a26 # 集群唯一标识符，与上面osdmap相同
last_changed 2020-04-03 11:51:32.819569
created 2020-04-03 11:50:17.737819
0: 10.0.0.114:6789/0 mon.ykrzf # mon.ykrzf 随机字符，作为mon的标识符
1: 10.0.0.115:6789/0 mon.ezhyx
2: 10.0.0.116:6789/0 mon.cuzwm
总结
- monitor提供权限、osd、主机、日志、告警等一系列集群管理服务，以上配置均可基于CLI命令实现，相关命令可参考ceph官方文档
- monitor采用基于Paxos实现的分布式一致性算法，实现自身消息传播的一致性
- monitor是一个采用多活策略的小型集群，保证自身高可靠性的同时也避免了集群规模较大时产生性能瓶
学习自：
《Ceph之RADOS设计原理与实现》 谢型果 严军
https://docs.ceph.com/docs/master/