mds的cpu占用问题分析以及解决办法


ganesha

前言

mds是ceph里面处理文件接口的组件,一旦使用文件系统,不可避免的会出现一种场景就是目录很多,目录里面的文件很多,而mds是一个单进程的组件,现在虽然有了muti mds,但稳定的使用的大部分场景还是单acitve mds的

这就会出现一种情况,一旦一个目录里面有很多文件的时候,去查询这个目录里的文件就会在当前目录做一次遍历,这个需要一个比较长的时间,如果能比较好的缓存文件信息,也能避免一些过载情况,本篇讲述的是内核客户端正常,而export nfs后mds的负载长时间过高的情况

CentOS GRUB损坏修复方法


grub

前言

博客很久没有更新了,一个原因就是原来存放部署博客的环境坏了,硬盘使用的是SSD,只要读取到某个文件,整个磁盘就直接识别不到了,还好博客环境之前有做备份,最近一直没有把部署环境做下恢复,今天抽空把环境做下恢复并且记录一篇基础的GRUB的处理文档

这两天正好碰到GRUB损坏的事,很久前处理过,但是没留下文档,正好现在把流程梳理一下,来解决grub.cfg损坏的情况,或者无法启动的情况

推荐一本书《Ceph设计原理与实现》



前言

本篇不是一篇技术文,而是推荐的一本书,对于写书来说,在多年以前觉得是一件可望而不可及的事情,而看到几本经典书籍的作者在讲述自己写书的过程的时候,都是自己注入了大量的精力的,所以我自己目前也只能是一个个知识点的以博客的方式进行记录

对于买书来说,很多人会觉得很贵,其实一本书几百面,只要里面的书有两面是能够帮助到你的,书的价值其实已经回来了,所以对于技术书籍来说,基本不评价书的好坏,而是去看多少能提取的东西,多少未知的东西

ceph的书籍最初的起步也是国外的一个作者写的,社区进行翻译,社区自己也出了一本书,还有ZETTAKIT(泽塔云)的研发常涛也出了一本《Ceph源码分析》,这些都是很好的书籍,之前也都有推荐,这些书籍都是一线的研发在繁忙之中抽出空余的时间写下来的

本篇推荐的一篇是来自中兴的书籍,中兴也是国内ceph开发里面代码提交量很高的公司

目前没能拿到书籍,所以只能从目录来讲下本书会提供哪些相关的知识了

掉电后osdmap丢失无法启动osd的解决方案



前言

本篇讲述的是一个比较极端的故障的恢复场景,在整个集群全部服务器突然掉电的时候,osd里面的osdmap可能会出现没刷到磁盘上的情况,这个时候osdmap的最新版本为空或者为没有这个文件

还有一种情况就是机器宕机了,没有马上处理,等了一段时间以后,服务器机器启动了起来,而这个时候osdmap已经更新了,全局找不到需要的旧版本的osdmap和incmap,osd无法启动

一般情况下能找到的就直接从其他osd上面拷贝过来,然后就可以启动了,本篇讲述的是无法启动的情况

Luminous监控界面中文语言包



前言

之前有各种ceph的管理平台,在部署方面大部分都比较麻烦,现在在luminous版本当中有一个原生的dashboard,虽然目前这个只能看,但是从界面上面,从接口方面都是非常不错的一个版本

原生版本目前没有语言的选择,虽然IT方面都是推荐用英语去做,但是在数据展示方面因为毕竟是要人来看,所以这里做了一个中文的语言包,方便转换成中文的界面,这个语言包是跟着ceph版本走的,因为界面可能会调整,所以只能一一匹配,同时提供了原版语言包,可以方便的回退回去,如果版本有更新以最后一个链接为准

如果有翻译的建议,欢迎在下面留言,或者其他方式告知我

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给控制住