前言之前在filestore里面，pg是直接暴露到文件系统的，也就是可以直接进去查看或者拷贝，在极端情况下，多个osd无法启动，pg无法导出的时候，那么对pg内部对象的操作处理，是可以作为最后恢复数据的一种方式的 这个在bluestore里面就没那么直接了，之前也碰到过一次，osd无法启动，内部死循环，pg无法export，osd就僵死在那里了，实际上，bluestore也提供了接口把对象能够直接显示出来 具体操作实践我们选择一个pg 1.7 123[root@lab101 ceph]# ceph pg dump|grep 1.7dumped all1.7 128 0 0 0 0 524353536 1583 1583 active+clean 2019-07-26 10:05:17.715749 14'3583 14:3670 [1] 1 [1] 1 0'0 2019-07-26 10:01:20.3 ...

前言ceph已经是一个比较成熟的开源的分布式存储了，从功能角度上来说，目前的功能基本能够覆盖大部分场景，而社区的工作基本上是在加入企业级的功能和易用性还有性能等方面在发力在，不管你是新手还是老手，都绕不开的一个问题就是crush，而crush是决定着数据的分布的，很多人并不理解为什么会有这个crush，这个算法到底是怎么去计算的，本篇是从更偏向用户层来对这个分布做一个解释，以及我们该怎么去动这个crush，本篇的内容不需要有代码开发能力，只需要稍加思考，都可以理解，剩下的就是你自己的选择了 所有的存储都离不开分布的问题，存储是不是做副本，副本是如何分布的都是有自己的一套逻辑的 这里拿gluster做例子，gluster的数据分布就是通过子卷来控制的，副本几，那么数据的子卷就是由几个组成，一个文件是默认落到一个子卷的，如果没做分片的话，然后所有的盘符的子卷组成了一整个的卷，数据是散列到子卷里面去的，这种子卷的组合是固定的，组合是通过命令的先后顺序来控制的，也就是数据的分布组合是固定的 而ceph的灵活之处在于把这种子卷的逻辑向下走了一层，通过一个pg的概念，以目录为结构做出很多这样的组 ...

前言本篇的内容实际上是另外一篇文章的字篇章，在另外一篇文章当中，将会对crush的分布的调整的做一次总结，用比较简单的方式来展示各种crush的区别 在做这个工作过程中，为了更好的能展示出效果，就有了下面的这个小工具的出现 工具来源假如我现在想查看一个存储池内的pg的分布，那么我们需要下面的几个步骤 1、随机获取一个pg的id1[root@lab101 ~]# ceph pg dump|grep ^0 后面的是存储池的编号从输出中拿到0.196开头的这个pg 10.196 0 0 0 0 0 0 0 0 active+clean 2019-03-07 18:03:28.262747 0'0 259:24 [2,30,21] 2 [2,30,21] 0'0 2019-03-06 17:30:29.598534 0'0 2019-03-06 17:30:29.598534 得到三个osd的id的值，2,30,21 2、获取ceph osd tree拿到osd的分布1[root@lab101 ~]# ceph osd tree 的到一个大概这样的图，拿到 o ...

前言前一段时间碰到一个系统，用rados bench 去跑都还比较正常，但是一跑数据库就非常慢，测试工具会抛出延时过大的提示，经过排查发现，云平台中有一台虚拟机还运行着备份数据库的服务，而这个备份软件是需要反复写一个标记文件的，因为这个标记文件只对应了一个对象，一个对象对应了一个pg，一个pg对应到固定的ssd上面，那个ssd的io几乎被这一个操作给打满了，然后全局的请求到了这个osd上面的时候，都会变得慢和卡顿 出现这种情况，在业务层面可能需要做好分离，我们在面对这种情况的时候该如何提前就做好测试，对自己的性能的剩余性能做一个更好的评估，什么时候需要分离，什么时候不需要分离，这个都是需要用数据来说话的 性能测试的时候，经常面临的这些问题，你告诉我这个环境能跑多少iops，带宽能多大，我的数据库能不能跑，这个我也没法回答，一般来说我都是说需要根据环境进行测试，这个测试也只能根据自己设计的模型进行测试，而越接近用户使用场景的业务模型，就越能反应真实的业务能力，最好的测试就是直接拿对接的软件进行测试，接什么业务就用什么业务压 我们可以自己先问自己几个问题 1、如果集群里面有一台虚拟机在跑 ...

前言最近已经见到几个环境出现过incompelete了，这个在很久以前Jewel正在合入mark-complete工具的时候就有做过类似的处理，但是随着处理的环境越来越多，这个地方还是有些需要注意的，本篇是写一些需要注意的点 一般来说是环境有多个机器同时坏盘或者掉电，或者掉主机引起的 处理流程拿到环境第一时间是对环境标记noout，这个操作是为了防止集群的环境反复震荡，标记noout没有osd标记为out的情况下，只是pg状态变化，实际数据并不进行迁移 把能够启动的osd都启动起来，直到没有能启动的osd了，如果有能力处理的话，尽量把osd拉起来，如果是硬盘损坏掉了，确定无法修复了，那么就当这个osd无法救回来了，这个步骤里面是要尽最大努力把osd拉起来 这里面还有一部分情况是osd启动不起来，但是数据目录是可以访问的，这个地方就把这种盘先保留好，一定不要推掉了，很多运维上去看盘坏了就重新创建osd，这种推掉osd的操作建议只在active+clean的时候才做，否则的话，pg状态不对，又把osd推掉了，数据有比较大的概率丢失 在以上操作做完以后，开始处理异常的pg，处理的时候，首先把 ...

前言如果用cephfs比较多，应该都知道，在cephfs的客户端进行mount以后，看到的容量显示的是集群的总的容量，也就是你的总的磁盘空间是多少这个地方显示的就是多少 这个一直都是这样显示的，我们之前在hammer版本的时候，阿茂和大黄一起在公司内部实现了这个功能，社区会慢慢的集成一些类似的面向面向商业用户的需求 社区已经开发了一个版本，接口都做的差不多了，那么稍微改改，就能实现想要的需求的 本篇内的改动是基于内核客户端代码的改动，改动很小，应该能够看的懂 改动过程首先找到这个补丁 Improve accuracy of statfs reporting for Ceph filesystems comprising exactly one data pool. In this case, the Ceph monitor can now report the space usage for the single data pool instead of the global data for the entire Ceph cluster. Include support for ...

前言ceph的可视化方案很多，本篇介绍的是比较简单的一种方式，并且对包都进行了二次封装，所以能够在极短的时间内构建出一个可视化的监控系统 本系统组件如下： ceph-jewel版本 ceph_exporter的jewel版本 prometheus的2.3.2版本 grafana的grafana-5.2.1版本 Ceph grafana的插件- Clusterby Cristian Calin 适配的系统为centos7 资源如下： http://static.zybuluo.com/zphj1987/jiwx305b8q1hwc5uulo0z7ft/ceph_exporter-2.0.0-1.x86_64.rpmhttp://static.zybuluo.com/zphj1987/1nu2k4cpcery94q2re3u6s1t/ceph-cluster_rev1.jsonhttp://static.zybuluo.com/zphj1987/7ro7up6r03kx52rkwy1qjuwm/prometheus-2.3.2-1.x86_64.rpmhttp://mysrc.cn- ...

前言ceph的rgw能够提供一个兼容性的s3的接口，既然是兼容性，当然不可能是所有接口都会兼容，那么我们需要有一个工具来进行接口的验证以及测试，这个在其他测试工具里面有类似的posix接口验证工具，这类的工具就是跑测试用例，来输出通过或者不通过的列表 用此类的工具有个好的地方就是，能够对接口进行验证，来避免版本的更新带来的接口破坏 安装直接对官方的分支进行clone下来，总文件数不多，下载很快 12[root@lab101 s3]# git clone https://github.com/ceph/s3-tests.git[root@lab101 s3]# cd s3-tests/ 这个地方注意下有版本之分，测试的时候需要用对应版本，这里我们测试的jewel版本就切换到jewel的分支(关键步骤) 123[root@lab101 s3-tests]# git branch -a[root@lab101 s3-tests]# git checkout -b jewel remotes/origin/ceph-jewel[root@lab101 s3-tests]# ./bootstra ...

引言最近接触了两个集群都使用到了erasure code,一个集群是hammer版本的，一个环境是luminous版本的，两个环境都出现了incomplete，触发的原因有类似的地方，都是有osd的离线的问题 准备在本地环境进行复验的时候，发现了一个跟之前接触的erasure不同的地方，这里做个记录，以防后面出现同样的问题 分析过程准备了一个luminous的集群，使用默认的erasure的profile进行了创建存储池的相关工作 12345[root@lab102 ~]# ceph osd erasure-code-profile get defaultk=2m=1plugin=jerasuretechnique=reed_sol_van 默认的是2+1的纠删码的配置，创建完了以后存储池的配置是这样的 12[root@lab102 ~]# ceph osd dump|grep poolpool 1 'rbd' erasure size 3 min_size 3 crush_rule 2 object_hash rjenkins pg_num 256 pgp_num ...