Ceph Monitor源码机制分析（一）—— 概述

0 前言

最近终于有点时间可以看看Ceph的代码了，接下来准备就Ceph monitor这个Ceph集群中最重要的组件进行深入的分析。

1 Monitor的作用

Monitor在Ceph集群中扮演着管理者的角色，维护了整个集群的状态（抽象成几张map，包括osdmap、monmap、mdsmap、auth、log等），保证集群的相关组件在同一时刻能够达成一致，相当于集群中的领导层。之所以说是相关而不是所有的主要是因为OSD map的更新采用了类似于灰度发布的机制，这会导致在一个时刻集群中所有OSD或者Client所持有的OSDmap的版本可能是不一致的。总结一句话就是monitor是负责收集集群信息、更新集群信息以及发布集群信息的。如果只有一个monitor那么，这件事情会轻松的多，集群信息的增、删、改、查都有这个monitor完成。但作为一个分布式存储解决方案，规避任何的单点故障都是一个必备条件，所以在使用Ceph的生产环境中也会部署多个Monitor。单点问题解决了，但Monitor多了之后相应的集群数据管理也就复杂了，引入了许多新的问题，比如：集群数据存在哪里？数据到底有谁更新？其他组件从哪里读取信息？多个monitor之间如何进行数据同步等？所以在一个标准的Ceph环境中，Monitor做的事情可以抽象成以下两点：

• 管好自己，其实也就解决多个monitor之间如何协同工作，比如谁负责更新数据，怎么更新？monitor之间怎么同步数据？谁负责发布数据？如何确保monitor的健康问题？
• 管好集群信息，其实也就解决存储哪些数据？数据怎么存储？存储在哪里？怎么保证存储数据的正确性？

如何抽象成以上两点呢？还得从代码入手，看一下monitor的代码目录结构：

当然，以上源码文件的划分也不是完全分开的，彼此之间仍然有一些关联关系存在，比如选举这个过程实际上还会涉及monitor之间的数据同步也就是数据管理中的更新。数据更新，需要通过数据存储模块完成持久化。Monitor管理的数据中OSDMap和MDSMap这两部分没有放在monitor目录下，而是分别放在osd和mds目录下的，所以这里用红色字体将他们标记了出来。

接下来的几篇文章主要围绕以上两个大面详解monitor中所涉及的相关技术。