Ceph OSD服务失效自动启动控制



前言

服务器上面的服务会因为各种各样的原因失败,磁盘故障,权限问题,或者是服务过载引起超时,这些都可能引起

这个在ceph里面systemctl unit 默认有个on-fail restart,默认的可能并不适合所有的场景,所以自动化的服务应该是尽量去适配你手动处理的过程,手动怎么处理的,就怎么去设置

osd磁盘空间足够无法写入数据的分析与解决



前言

这个问题的来源是ceph社区里面一个群友的环境出现在85%左右的时候,启动osd报错,然后在本地文件系统当中进行touch文件的时候也是报错,df -i查询inode也是没用多少,使用的也是inode64挂载的,开始的时候排除了配置原因引起的,在ceph的邮件列表里面有一个相同问题,也是没有得到解决

看到这个问题比较感兴趣,就花了点时间来解决来定位和解决这个问题,现在分享出来,如果有类似的生产环境,可以提前做好检查预防工作

现象描述

ceph版本

[root@lab8107 mnt]# ceph -v
ceph version 10.2.9 (2ee413f77150c0f375ff6f10edd6c8f9c7d060d0)
我复现的环境为这个版本

为什么关不掉所有的OSD

前言

碰到一个cepher问了一个问题:

为什么我的OSD关闭到最后有92个OSD无法关闭,总共的OSD有300个左右

想起来在很久以前帮人处理过一次问题,当时环境是遇上了一个BUG,需要升级到新版本进行解决,然后当时我来做操作,升级以后,发现osd无法启动,进程在,状态无法更新,当时又回滚回去,就可以了,当时好像是K版本升级到J版本,想起来之前看过这个版本里面有数据结构的变化,需要把osd全部停掉以后才能升级,然后就stop掉所有osd,当时发现有的osd还是无法stop,然后就手动去标记了,然后顺利升级

关于scrub的详细分析和建议


scrub

前言

关于scrub这块一直想写一篇文章的,这个在很久前,就做过一次测试,当时是看这个scrub到底有多大的影响,当时看到的是磁盘读占很高,启动deep-scrub后会有大量的读,前端可能会出现 slow request,这个是当时测试看到的现象,一个比较简单的处理办法就是直接给scrub关掉了,当然关掉了就无法检测底层到底有没有对象不一致的问题
关于这个scrub生产上是否开启,仁者见仁,智者见智,就是选择的问题了,这里不做讨论,个人觉得开和关都有各自的道理,本篇是讲述的如果想开启的情况下如何把scrub给控制住

如何测量Ceph OSD内存占用



前言

这个工具我第一次看到是在填坑群里面看到,是由研发-北京-蓝星同学分享的,看到比较有趣,就写一篇相关的记录下用法

火焰图里面也可以定位内存方面的问题,那个是通过一段时间的统计,以一个汇总的方式来查看内存在哪个地方可能出了问题

Ceph recover的速度控制



前言

磁盘损坏对于一个大集群来说,可以说是必然发生的事情,即使再小的概率,磁盘量上去,总会坏那么几块盘,这个时候就会触发内部的修复过程,修复就是让不满足副本要求的PG,恢复到满足的情况

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



前言

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