前言ceph里面的数据是以对象的形式存储在OSD当中的，有的时候因为磁盘的损坏或者其它的一些特殊情况，会引起集群当中的某一个对象的异常，那么我们需要对这个对象进行处理 在对象损坏的情况下，启动OSD有的时候都会有问题，那么通过rados rm的方式是没法发送到这个无法启动的OSD的，也就无法删除，所以需要用其他的办法来处理这个情况 处理步骤查找对象的路径12[root@lab8106 ~]# ce

前言我们在使用集群的时候，一般来说比较关注的是后台的集群的状态，但是在做一些更人性化的管理功能的时候，就需要考虑到更多的细节 本篇就是其中的一个点，查询ceph被哪些客户端连接了 实践从接口上来说，ceph提供了文件，块，和对象的接口，所以不同的接口需要不同的查询方式，因为我接触文件和块比较多，并且文件和块存储属于长连接类型，对象属于请求类型，所以主要关注文件和块存储的连接信息查询 我的集群状态如

前言在跟一个朋友聊天的时候，聊到一个技术问题，他们的一个环境上面小文件巨多，是我目前知道的集群里面规模算非常大的了，但是目前有个问题，一方面会进行一倍的硬件的扩容，而文件的数量也在剧烈的增长着，所以有没有什么办法来 缓解这个增长的压力 当时也没想到太多的办法,只是觉得这么用下去风险太大 后来在思考了一段时间后，大概有了一个想法，这个就要看是否能把方案做下去，如果是我自己在用的集群，而非客户，我会这

前言在看一个Linux Vault 2017的资料的时候，看到红帽分享的一个测试的过程，里面关于小文件元数据性能测试的，环境准备的还比较好,可以作为一种测试模型 测试用例测试用例一： 使用find -name 测试 find -size 测试 测试用例二： 使用find -name 测试 find -size 测试 测试用例三： 使用rmdir进行测试 总结本篇就是记录一个测试模型 变更记录

前言在ceph的研发群里看到一个cepher提出一个问题，编译的ceph的二进制文件过大，因为我一直用的打包好的rpm包，没有关注这个问题，重新编译了一遍发现确实有这个问题 本篇就是记录如何解决这个问题的 打rpm包的方式用我自己的环境编译的时候发现一个问题，编译出来的rpm包还是很大，开始怀疑是机器的原因，换了一台发现二进制包就很小了，然后查询了很多资料以后，找到了问题所在 在打rpm包的时候可

前言之前看过一个朋友一篇文章，讲述的是Vsan为什么使用的是两副本，而ceph则大多数情况下需要三副本，当时个人观点是这个并不是关键点，但是在仔细考虑了问题的出发点以后，这个也可以说是其中的一个点 一个集群数据丢失可以从多方面去看 发生丢失数据的事件，这个来说，出现这个事件的概率是一致的，同等硬件情况下没有谁的系统能够说在两副本情况下把这个出现坏盘概率做的比其他系统更低 发生坏盘事件以后，数据丢

前言前一篇介绍了docker在命令行下面进行的ceph部署，本篇用docker的UI进行ceph的部署，目前来说市面上还没有一款能够比较简单就能直接在OS上面去部署Ceph的管理平台，这是因为OS的环境差异化太大，并且包的版本，以及各种软件的适配都可能造成失败，而docker比较固化环境，因此即使一个通用的UI也能很方便的部署出一个Cpeh集群 本篇就是对Docker UI部署集群做一个实践，对c

前言容器和ceph的结合已经在一些生产环境当中做了尝试，容器的好处就是对运行环境的一个封装，传统的方式是集成为ISO，这个需要一定的维护量，而容器的相关操作会简单很多，也就有了一些尝试，个人觉得如果玩的转容器可以考虑，当然得懂ceph，不然两套系统在一起，问题都不知道是哪个的，就比较麻烦了 本篇是基于之前我的填坑群里面的牛鹏举的一个问题，他的环境出现了创建osd的时候权限问题，我这边没遇到，现在实

前言系统中有些地方会进行资源的限制，其中的一个就是open file的限制，操作系统默认限制的是1024,这个值可以通过各种方式修改，本篇主要讲的是如何在线修改，生产上是不可能随便重启进程的 实践查看系统默认的限制12[root@lab8106 ~]# ulimit -a|grep openopen files (-n) 1024 默认的打开文件是1024

前言我们以前的管理平台在python平台下面做的，内部做的一些操作采用的是命令执行，然后解析的方式去做的，ceph自身有python的rados接口，可以直接调用原生接口，然后直接解析json的方式，这样更靠近底层 在看ceph-dash内部的实现的时候，发现里面的获取集群信息的代码可以留存备用 代码实例123456789101112131415161718192021222324#!/usr/b