前言这个问题的来源是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 在做操作的时候就只会记录日志，前台不 ...

前言之前有个想法，是不是有办法找到rbd中的文件与对象的关系，想了很久但是一直觉得文件系统比较复杂，在fs 层的东西对ceph来说是透明的，并且对象大小是4M，而文件很小，可能在fs层进行了合并，应该很难找到对应关系，最近看到小胖有提出这个问题，那么就再次尝试了，现在就是把这个实现方法记录下来 这个提取的作用个人觉得最大的好处就是一个rbd设备，在文件系统层被破坏以后，还能够从rbd提取出文件，我们知道很多情况下设备的文件系统一旦破坏，无法挂载，数据也就无法读取，而如果能从rbd中提取出文件，这就是保证了即使文件系统损坏的情况下，数据至少不丢失 本篇是基于xfs文件系统情况下的提取，其他文件系统有时间再看看，因为目前使用的比较多的就是xfs文件系统 本篇也回答了一个可能会经常被问起的问题，能告诉我虚拟机里面的文件在后台存储在哪里么，看完本篇就知道存储在哪里了 XFS文件系统介绍1234567891011[root@lab8106 ~]# mkfs.xfs -f /dev/rbd0p1 warning: device is not properly aligned /dev/rbd0p ...

前言性能优化大神Brendan Gregg发明了火焰图来定位性能问题，通过图表就可以发现问题出在哪里，通过svg矢量图来查看性能卡在哪个点，哪个操作占用的资源最多 在查看了原始数据后，这个分析的原理是按层级来对调用进行一个计数，然后以层级去做比对，来看横向的占用的比例情况 基于这个原理，把osd tree的数据和pg数据可以做一个层级的组合，从而可以很方便的看出pg的分布情况，主机的分布情况，还可以进行搜索，在一个简单的图表内汇聚了大量的信息 实践获取需要的数据，这个获取数据是我用一个脚本解析的osd tree 和pg dump，然后按照需要的格式进行输出 default;lab8106;osd.2;0.0 6default;lab8106;osd.3;0.0 6default;rack1;lab8107;osd.0;0.0 6 需要的格式是这个样的，最后一个为权重，使用的是对象数，因为对象数可能为0，所以默认在每个数值进行了加一的操作，前面就是osd的分布的位置 脚本/sbin/stackcollapse-crush内容如下： 1234567891011121 ...