深入理解 ceph mgr

云计算

背景

监控是管理的第一步,所以 ceph-mgr 目前的主要功能是把集群的一些指标暴露给外界使用。监控是什么东西呢?举个例子,例如用户访问网站 5xx 了,那么监控就是这么一个系统:采集网站 5xx 的个数,存起来,然后在 5xx 多的时候通过报警短信报给开发,然后为开发解决该问题提供其他信息(例如日志,指标图表)。所以监控系统是一个数据系统,包含采集,存储,分析(包含报警),可视化,这几个部分。

关于监控,在此之前,ceph 以及社区有不少尝试。

calamari

calamari。calamari 是 ceph 背后的公司 Inktank 为 ceph 企业版开发的监控管理程序,在 Red Hat 收购该公司后开源,目前基本处于停滞状态。其基本原理是利用 salt 远程执行 python 脚本,该脚本通过 ceph 每个守护进程暴露在本地的 admin socket 采集到数据或者执行命令。其主要包含几部分:

采集:

ceph 数据。salt python 脚本
主机数据。
Diamond

存储:自带了一个 graphite
分析:没有
可视化:专门定制了一个
前端

评价:

涉及技术多,杂合在一起,认知和维护负担大。其涉及的技术包括但不限于:vagrant, salt, django, graphite ,node, diamond。就安装过程来说,我花了两天左右,然后成功发现其所有涉及仓库的 master 版本无法一起跑起来。首先,Github Release 只有 Ubuntu 的包,还是 15 年 10 月上传的,我们系统是CentOS 7.2,因此我只能照着
这个教程 从源码编译打包安装。安装过程中 salt 安装包时包文件冲突,rpm build 时找不到文件。它的前端
romana 从 Release 下载后放到对应目录,发现有些前端文件找不到,必须去改它 Django 的 view,Django 没学过,改时不太有底,终于让前端页面显示之后,发现前端请求的一个 API 后端没有实现。
项目已停滞,开发资源转向 ceph-mgr。从
该项目 Github Insights 可以看出 2017 年后 commit 较少,commit 较多的人有两个,排第一的 [jcsp] 目前主要在开发 ceph-mgr。

cephmetrics

cephmetrics。基本原理是基于 collectd 插件,从 admin socket 中采数据发往 graphite,用 grafana 做图。

评价:

项目划分比 calamari 清晰,各组件都用了业界主流解法。collectd (采集) graphite(存储和计算) grafana(可视化)。比较看好这种解法。
collectd 插件是部署到每台机器上的,解决了采集的负载均衡问题,但插件的部署、升级、管理相对麻烦,并且可能影响目标主机,问题不是太大,可以采纳。
Dashboard 不大好,冗余代码多。其提供的 Dashboard 中选择的数据,以及数据的摆放,Dashboard 之间的关联考虑的不是太好,例如没有把相关数据放到一起,没有根据一个目的在做图表,有堆砌数据的感觉。冗余代码是指包含了 ansible 部署代码,collectd 关于 cpu 等系统数据的采集的配置等与 Ceph 本身无关的代码,增加了认知负担。

ceph_exporter

ceph_exporter。基本原理是利用 librados,从 ceph monitor 中取数据,通过 http 协议把指标以 prometheus 规定的格式暴露出来。

评价:

是个纯采集组件,只需部署一处,和 ceph monitor 通信,模式简单易理解,非常看好。
一个缺点是 prometheus 系统本身具有的。其插件是通过 exporter 的形式分散到各个仓库里,分别部署,那么多 exporter,每个都是独立的进程,怎么管理它们是个大问题。管理就包括部署,监控,升级,配置管理,启动和停止,每一个都是问题。相比之下,collectd 做为一个采集框架,为所有插件的实现提供了共有基础功能,使得插件的实现变得非常简单:

为插件提供了运行环境。插件只需提供 read (input 插件),write(output 插件),无需启动进程,无需处理信号。
为插件提供了配置系统。插件无需担心如何如何配置自己,用户只要在 collectd 配置文件中按统一格式传入,插件就可以以统一的方式拿到。
为插件提供了 Log 机制。插件可以使用 collectd 的日志机制,从而无需担心如何支持 level,输出到不同地方等。
为插件提供了数据通道。插件之间的数据是打通的,插件无需关心输出到哪,是 graphite,influxdb,还是 opentsdb。只需实现 read 回调来采集数据,然后配置不同的 output 插件,就能实现输出到不同地方。

ceph-mgr

在以上背景下,ceph 官方开发了 ceph-mgr,主要目标实现 ceph 集群的管理,为外界提供统一的入口。要深入了解 ceph-mgr,就得了解 ceph-mgr 是如何跑起来的。


官方文档 可知,ceph-mgr 是通过可执行文件
ceph-mgr 跑起来的,在源码
src/CMakeLists.txt 搜索
ceph-mgr 可以搜到
add_executable(ceph-mgr ${mgr_srcs}...,从中可以看出 ceph-mgr 主要由
src/mgr 里的文件编译出来(猜也猜的出来),main 函数在
src/ceph_mgr.cc。以上就是相关文件,有需要深入的人可以去读,这里介绍整理之后的 ceph-mgr 工作原理。

ceph-mgr 工作的模式是事件驱动型的,意思就是等待事件,事件来了则处理事件返回结果,又继续等待。其主要运行的线程包括:

messenger 线程。这是事件驱动主线程,监听某一端口,由外界给输入事件,messenger 收到事件后分派给各个处理者。通过向 monitor 订阅某一个 topic 的消息,例如
mgrmap,
osdmap,monitor 会在这些数据发生变化时把事件通知到 messenger 监听的端口。事件处理器包括:

MgrStandby。Mgr 通过 standby 实现高可用,每一个运行的 ceph-mgr 都包含一个 MgrStandby,MgrStandby 并没有运行的线程,它存在于 messenger 收到消息时的回调,以及通过定时器线程运行的定时任务,并且管理着其他实体。其处理的唯一消息是
mgrmap,就是当主挂掉时要顶上来,当自己不是主时要退回去。什么时候切主由 monitor 管理,所以 MgrStandby 里切主逻辑比较简单,有一个
Mgr 实例,当收到 mgrmap 时生成该实例,存到 MgrStandby 属性里,就完了。因为在收到消息时,MgrStandby 如果看到有
Mgr 实例,就会把消息发到它那处理,在定时函数里,也会调用 mgr 的定时函数,这样,实际上,MgrStandby 就担起了主的任务。
Mgr。如上段所述,Mgr 依附于 MgrStandby 存在,也没有单独线程。它通过处理
mon_map
fs_map
osd_map等事件,在内存中维护了集群成员信息,它管理 ceph-mgr 插件,为插件提供了所有数据的来源,也在特定事件发生时通知给 ceph-mgr 的插件,例如插件的
notify 函数,就是被 Mgr 回调的。
DaemonServer。独立线程,和主 messenger 监听同一端口(待确认)。是 cluster 指标数据的主要维护者,并且负载执行对集群的操作,例如吩咐 OSD 进行
pg scrub等。

plugin 线程。plugin 是 Python 写的,每个 plugin 都跑在单独线程里,线程调用的函数是 python 类的
serve。plugin 可以在 serve 里跑个 http server 来提供对外服务,ceph-mgr 为 plugin 提供了
get
get_server 等函数,这些函数返回关于集群的指标等数据。例如 prometheus 插件,就把 ceph 内部指标通过 http 协议以 prometheus 格式暴露出来,使得监控 ceph 集群变得较为简单。ceph 是 c 写的,ceph 会调用 python plugin 定义的方法(例如 serve),python plugin 可以调用 c 定义的函数(例如
get),python/c 的互调是 python 提供的机制,其基本原理是:

c 调 python。python 的实体在 c 里类型都是
PyObject,模块,函数、类、数据都是。cpython 提供了
PyImport_Import 用于通过名字得到 m模块对象对应的 PyObject,类可以通过
PyObject_GetAttrString 取模块的属性得到,以此类推,cpython 还提供了由 c 类型的值生成对应 python 类型的值的PyObject 的方法,例如
PyObject* PyString_FromString(char *)。有函数对象,有参数对象,就可以通过
PyObject * PyObject_CallObject() 调用函数,将得到的 PyObject* 再转回 c 类型就 OK 了。
python 调用 c 。在 c 里定义
PyObject* ceph_state_get(PyObject *self, PyObject *args),在函数里里面通过
PyArg_ParseTuple(args, ss:ceph_state_get, &handle, &what) 把参数解析为 c 类型,就实现了一个 Python 函数。通过
PyMethodDef CephStateMethods[] = {{get, ceph_state_get, METH_VARARGS,Get a cluster object}} 把 Python 函数加入到一个注册表里。通过
Py_InitModule(ceph_state, CephStateMethods),将注册表里的函数定义为
ceph_state 模块的属性,并把该模块注入到 python sys.path 里,python 就可以通过
ceph_state.ceph_state_get 调用该函数了。

作者:李逸超【资深软件开发工程师】

为研发提效,全是技术干货的滴滴云技术沙龙报名中!

马上关注滴滴云公众号:

回复「上课」获取免费报名资格

回复「服务器」免费获得云服务器入门1个月体验

更多关于云服务器,域名注册虚拟主机的问题,请访问西部数码官网:www.west.cn

赞(0)
声明:本网站发布的内容(图片、视频和文字)以原创、转载和分享网络内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-62778877-8306;邮箱:fanjiao@west.cn。本站原创内容未经允许不得转载,或转载时需注明出处:西部数码知识库 » 深入理解 ceph mgr

登录

找回密码

注册