从ceph对象中提取RBD中的指定文件



前言

之前有个想法,是不是有办法找到rbd中的文件与对象的关系,想了很久但是一直觉得文件系统比较复杂,在fs 层的东西对ceph来说是透明的,并且对象大小是4M,而文件很小,可能在fs层进行了合并,应该很难找到对应关系,最近看到小胖有提出这个问题,那么就再次尝试了,现在就是把这个实现方法记录下来

Cephfs 操作输出到日志查询系统


log.png-116.6kB

前言

文件系统当中如果某些文件不见了,有什么办法判断是删除了还是自己不见了,这个就需要去日志里面定位了,通常情况下是去翻日志,而日志是会进行压缩的,并且查找起来非常的不方便,还有可能并没有开启

ceph luminous 新功能之磁盘智能分组



前言

本篇是luminous一个新功能介绍,关于磁盘智能分组的,这个在ceph里面叫crush class,这个我自己起名叫磁盘智能分组,因为这个实现的功能就是根据磁盘类型进行属性关联,然后进行分类,减少了很多的人为操作

以前我们需要对ssd和hdd进行分组的时候,需要大量的修改crush map,然后绑定不同的存储池到不同的 crush 树上面,现在这个逻辑简化了很多

ceph luminous 新功能之内置dashboard



前言

ceph luminous版本新增加了很多有意思的功能,这个也是一个长期支持版本,所以这些新功能的特性还是很值得期待的,从底层的存储改造,消息方式的改变,以及一些之前未实现的功能的完成,都让ceph变得更强,这里面有很多核心模块来自中国的开发者,在这里准备用一系列的文章对这些新功能进行一个简单的介绍,也是自己的一个学习的过程

调整PG分多次调整和一次到位的迁移差别分析


different

前言

这个问题来源于我们研发的一个问题,在进行pg调整的时候,是一次调整到位好,还是分多次调整比较好,分多次调整的时候会不会出现某个pg反复挪动的问题,造成整体迁移量大于一次调整的

最近自己的项目上也有pg调整的需求,这个需求一般来源于pg规划好了,后期出现节点扩容的情况,需要对pg进行增加的调整

本篇用具体的数据来分析两种方式的差别

因为本篇的篇幅较长,直接先把结论拿出来

使用日志系统graylog获取Ceph集群状态



前言

在看集群的配置文件的时候看到ceph里面有一个graylog的输出选择,目前看到的是可以收集mon日志和clog,osd单个的日志没有看到,Elasticsearch有整套的日志收集系统,可以很方便的将所有日志汇总到一起,这个graylog的收集采用的是自有的udp协议,从配置上来说可以很快的完成,这里只做一个最基本的实践

Ceph部署mon出现0.0.0.0地址


monitor

前言

最近在群里两次看到出现mon地址不对的问题,都是显示0.0.0.0:0地址,如下所示:

[root@lab8106 ceph]# ceph -s
cluster 3137d009-e41e-41f0-b8f8-5cb574502572
health HEALTH_ERR
1 mons down, quorum 0,1,2 lab8106,node8107,lab104
monmap e2: 4 mons at {lab104=192.168.10.4:6789/0,lab8106=192.168.8.106:6789/0,lab8107=0.0.0.0:0/2,node8107=192.168.8.107:6789/0}