前言本篇讲述的是一个比较极端的故障的恢复场景，在整个集群全部服务器突然掉电的时候，osd里面的osdmap可能会出现没刷到磁盘上的情况，这个时候osdmap的最新版本为空或者为没有这个文件
还有一种情况就是机器宕机了，没有马上处理，等了一段时间以后，服务器机器启动了起来，而这个时候osdmap已经更新了，全局找不到需要的旧版本的osdmap和incmap，osd无法启动
一般情况下能找到的就直接从其他osd上面拷贝过来，然后就可以启动了，本篇讲述的是无法启动的情况
解决方案获取运行的ceph集群当前版本12[root@lab8107 ~]# ceph -vceph version 10.2.9 (2ee413f77150c0f375ff6f10edd6c8f9c7d060d0)
获取最新的osdmap
12[root@lab8107 ~]# ceph osd getmap -o /tmp/productosdmapgot osdmap epoch 142
通过osdmap可以得到crushmap，fsid，osd，存储池，pg等信息
提取crushmap
123[root@lab810 ...
前言本篇来源于群里一个人的问题，有没有办法让ceph的磁盘不自动挂载，一般人的问题都是怎样让ceph能够自动挂载，在centos 7 平台下 ceph jewel版本以后都是有自动挂载的处理的，这个我之前也写过两篇文章《ceph在centos7下一个不容易发现的改变》和《Ceph数据盘怎样实现自动挂载》，来讲述这个自动挂载的
这里讲下流程：
开机后 udev 匹配 95-ceph-osd.rules 规则，触发 ceph-disk trigger，遍历磁盘，匹配到磁盘的标记后就触发了自动挂载
为什么要取消挂载？也许一般都会想：不就是停掉osd，然后umount掉，检查磁盘吗这个想法如果放在一般情况下都没有问题，但是为什么有这个需求就是有不一般的情况，这个我在很久前遇到过，所以对这个需求的场景比较清楚
在很久以前碰到过一次，机器启动都是正常的，但是只要某个磁盘一挂载，机器就直接挂掉了，所以这个是不能让它重启机器自动挂载的，也许还有其他的情况，这里总结成一个简单的需求就是不想它自动挂载
解决方法从上面的自启动后的自动挂载流程里面，我们可以知道这里可以有两个方案去解决这个问题，第一种是 ...
前言服务器上面的服务会因为各种各样的原因失败，磁盘故障，权限问题，或者是服务过载引起超时，这些都可能引起
这个在ceph里面systemctl unit 默认有个on-fail restart,默认的可能并不适合所有的场景，所以自动化的服务应该是尽量去适配你手动处理的过程，手动怎么处理的，就怎么去设置
启动分析如果有osd失败了，一般上去会先启动一次，尽快让服务启动，然后去检查是否有故障，如果失败了，就开启调试日志，再次重启，在问题解决之前，是不会再启动了，所以这里我们的自动启动设置也这么设置
参数配置ceph的osd的启动配置在这个配置文件
/usr/lib/systemd/system/[email protected]
默认参数：
1234Restart=on-failureStartLimitInterval=30minStartLimitBurst=30RestartSec=20s
默认的参数意思是在30min的周期内，如果没启动成功，那么在失败后20s进行启动，这样的启动尝试30次
这个在启动机器的时候，是尽量在osd启 ...
前言这个问题的来源是ceph社区里面一个群友的环境出现在85%左右的时候，启动osd报错，然后在本地文件系统当中进行touch文件的时候也是报错，df -i查询inode也是没用多少，使用的也是inode64挂载的，开始的时候排除了配置原因引起的，在ceph的邮件列表里面有一个相同问题，也是没有得到解决
看到这个问题比较感兴趣，就花了点时间来解决来定位和解决这个问题，现在分享出来，如果有类似的生产环境，可以提前做好检查预防工作
##现象描述ceph版本
[root@lab8107 mnt]# ceph -vceph version 10.2.9 (2ee413f77150c0f375ff6f10edd6c8f9c7d060d0)我复现的环境为这个版本
查询使用空间
可以看到空间才使用了54%可以看到，inode剩余比例很多，而文件确实无法创建
这个时候把一个文件mv出来，然后又可以创建了，并且可以写入比mv出来的文件更大的文件，写完一个无法再写入更多文件了
这里有个初步判断，不是容量写完了，而是文件的个数限制住了
那么来查询下文件系统的inode还剩余多少，xfs文件系统的inod ...
暂未分类
未读前言碰到一个cepher问了一个问题：
为什么我的OSD关闭到最后有92个OSD无法关闭,总共的OSD有300个左右
想起来在很久以前帮人处理过一次问题，当时环境是遇上了一个BUG，需要升级到新版本进行解决，然后当时我来做操作，升级以后，发现osd无法启动，进程在，状态无法更新，当时又回滚回去，就可以了，当时好像是K版本升级到J版本，想起来之前看过这个版本里面有数据结构的变化，需要把osd全部停掉以后才能升级，然后就stop掉所有osd，当时发现有的osd还是无法stop，然后就手动去标记了，然后顺利升级
今天这个现象应该跟当时是一个问题，然后搜索了一番参数以后，最后定位在确实是参数进行了控制
实践我的一个8个osd的单机环境，对所有OSD进行stop以后就是这个状态，还有2个状态无法改变
123456789101112131415[root@lab8106 ~]# ceph -s cluster 49ee8a7f-fb7c-4239-a4b7-acf0bc37430d health HEALTH_ERR 295 pgs are stuck in ...
前言关于scrub这块一直想写一篇文章的，这个在很久前，就做过一次测试，当时是看这个scrub到底有多大的影响，当时看到的是磁盘读占很高，启动deep-scrub后会有大量的读,前端可能会出现 slow request,这个是当时测试看到的现象，一个比较简单的处理办法就是直接给scrub关掉了，当然关掉了就无法检测底层到底有没有对象不一致的问题关于这个scrub生产上是否开启，仁者见仁，智者见智，就是选择的问题了，这里不做讨论，个人觉得开和关都有各自的道理，本篇是讲述的如果想开启的情况下如何把scrub给控制住
最近在ceph群里看到一段大致这样的讨论：
scrub是个坑
小文件多的场景一定要把scrub关掉单pg的文件量达到一定规模，scrub一开就会有slow request这个问题解决不了
上面的说法有没有问题呢？在一般情况下来看，确实如此，但是我们是否能尝试去解决下这个问题，或者缓解下呢？那么我们就来尝试下
scrub的一些追踪下面的一些追踪并不涉及代码，仅仅从配置和日志的观测来看看scrub到底干了什么
环境准备我的环境为了便于观测，配置的是一个pg的存储池，然后往这个p ...
前言这个工具我第一次看到是在填坑群里面看到，是由研发-北京-蓝星同学分享的，看到比较有趣，就写一篇相关的记录下用法
火焰图里面也可以定位内存方面的问题，那个是通过一段时间的统计，以一个汇总的方式来查看内存在哪个地方可能出了问题
本篇是另外一个工具，这个工具的好处是有很清晰的图表操作，以及基于时间线的统计，下面来看下这个工具怎么使用的
本篇对具体的内存函数的调用占用不会做更具体的分析，这里是提供一个工具的使用方法供感兴趣的研发同学来使用
环境准备目前大多数的ceph运行在centos7系列上面，笔者的环境也是在centos7上面，所以以这个举例，其他平台同样可以
需要用到的工具
valgrind
massif-visualizer
安装valgrind
1yum install valgrind
massif-visualizer是数据可视化的工具，由于并没有centos的发行版本，但是有fedora的版本，从网上看到资料说这个可以直接安装忽略掉需要的依赖即可，我自己跑了下，确实可行
下载massif-visualizer
1wget ftp://ftp.pbone.net/mir ...
前言磁盘损坏对于一个大集群来说，可以说是必然发生的事情，即使再小的概率，磁盘量上去，总会坏那么几块盘，这个时候就会触发内部的修复过程，修复就是让不满足副本要求的PG，恢复到满足的情况
一般是踢掉坏盘和增加新盘会触发这个修复过程，或者对磁盘的权重做了修改，也会触发这个迁移的过程，本篇是用剔除OSD的方式来对这个修复的控制做一个探索
大部分场景下要求的是不能影响前端的业务，而加速迁移，忽略迁移影响不在本篇的讨论范围内，本篇将用数据来说明迁移的控制
本次测试在无读写情况下进程的
几个需要用到脚本和命令磁盘本身的大概速度123456[root@lab8106 ~]# ceph tell osd.0 bench{ "bytes_written": 1073741824, "blocksize": 4194304, "bytes_per_sec": 102781897}
得到的结果为102MB/s
获取osd上pg迁移的对象的脚本OSD的日志需要开启到10，这里采取动态开启的方式
1ceph ...
前言ceph的s3数据的同步可以通过radosgw-agent进行同步，同region可以同步data和metadata，不同region只能同步metadata，这个地方可以参考下秦牧羊梳理的 ceph radosgw 多集群同步部署流程，本篇讲述的方案与radosgw-agent的复制方案不同在于,这个属于前端复制，后端相当于透明的两个相同集群，在入口层面就将数据进行了复制分流
在某些场景下，需求可能比较简单：
需要数据能同时存储在两个集群当中
数据写一次，读多次
两个集群都能写
一方面两个集群可以增加数据的可靠性，另一方面可以提高读带宽，两个集群同时可以提供读的服务
radosgw-agent是从底层做的同步，正好看到秦牧羊有提到nginx新加入了ngx_http_mirror_module 这个模块，那么本篇就尝试用这个模块来做几个简单的配置来实现上面的需求，这里纯架构的尝试，真正上生产还需要做大量的验证和修改的测试的
结构设想
当数据传到nginx的server的时候，nginx本地进行负载均衡到两个本地端口上面，本地的两个端口对应到两个集群上面,一个主写集群1，一个主写 ...
前言这个问题在很久以前就有一篇文章进行过讨论 remove-big-rbd,这个文章写的比较清楚了，并且对不同的方法做了分析，这里先把结论说下
rbd类型
rbd rm 方法
rados -p rm方法
未填充很多
慢
快
已填充很多
快
慢
在rbd进行删除的时候，即使内部没有对象数据，也一样需要一个个对象去发请求，即使对象不存在，这个可以开日志看到
实验过程开启日志的方法在/etc/ceph/ceph.conf中添加
123[client]debug_ms=1log_file=/var/log/ceph/rados.log
这个默认也会在执行命令的时候打印到前台，所以处理下比较好，最简单的办法就是做alias添加下面内容到 /etc/bashrc
12alias ceph='ceph --debug-ms=0'alias rados='rados --debug-ms=0'
然后命令行执行
1source /etc/bashrc
在做操作的时候就只会记录日志，前台不 ...
