慢话crush-各种crush组合
前言ceph已经是一个比较成熟的开源的分布式存储了，从功能角度上来说，目前的功能基本能够覆盖大部分场景，而社区的工作基本上是在加入企业级的功能和易用性还有性能等方面在发力在，不管你是新手还是老手，都绕不开的一个问题就是crush，而crush是决定着数据的分布的，很多人并不理解为什么会有这个crush，这个算法到底是怎么去计算的，本篇是从更偏向用户层来对这个分布做一个解释，以及我们该怎么去动这个c
ceph的pg的分布的快速查看
前言本篇的内容实际上是另外一篇文章的字篇章，在另外一篇文章当中，将会对crush的分布的调整的做一次总结，用比较简单的方式来展示各种crush的区别 在做这个工作过程中，为了更好的能展示出效果，就有了下面的这个小工具的出现 工具来源假如我现在想查看一个存储池内的pg的分布，那么我们需要下面的几个步骤 1、随机获取一个pg的id1[root@lab101 ~]# ceph pg dump|grep
vdbench测试实时可视化显示
前言前一段时间碰到一个系统，用rados bench 去跑都还比较正常，但是一跑数据库就非常慢，测试工具会抛出延时过大的提示，经过排查发现，云平台中有一台虚拟机还运行着备份数据库的服务，而这个备份软件是需要反复写一个标记文件的，因为这个标记文件只对应了一个对象，一个对象对应了一个pg，一个pg对应到固定的ssd上面，那个ssd的io几乎被这一个操作给打满了，然后全局的请求到了这个osd上面的时候，
处理ceph incompelete的经验
前言最近已经见到几个环境出现过incompelete了，这个在很久以前Jewel正在合入mark-complete工具的时候就有做过类似的处理，但是随着处理的环境越来越多，这个地方还是有些需要注意的，本篇是写一些需要注意的点 一般来说是环境有多个机器同时坏盘或者掉电，或者掉主机引起的 处理流程拿到环境第一时间是对环境标记noout，这个操作是为了防止集群的环境反复震荡，标记noout没有osd标记
cephfs根据存储池显示df容量
前言如果用cephfs比较多，应该都知道，在cephfs的客户端进行mount以后，看到的容量显示的是集群的总的容量，也就是你的总的磁盘空间是多少这个地方显示的就是多少 这个一直都是这样显示的，我们之前在hammer版本的时候，阿茂和大黄一起在公司内部实现了这个功能，社区会慢慢的集成一些类似的面向面向商业用户的需求 社区已经开发了一个版本，接口都做的差不多了，那么稍微改改，就能实现想要的需求的 本
快速构建ceph可视化监控系统
前言ceph的可视化方案很多，本篇介绍的是比较简单的一种方式，并且对包都进行了二次封装，所以能够在极短的时间内构建出一个可视化的监控系统 本系统组件如下： ceph-jewel版本 ceph_exporter的jewel版本 prometheus的2.3.2版本 grafana的grafana-5.2.1版本 Ceph grafana的插件- Clusterby Cristian Calin
利用s3-test进行ceph的接口兼容性测试
前言ceph的rgw能够提供一个兼容性的s3的接口，既然是兼容性，当然不可能是所有接口都会兼容，那么我们需要有一个工具来进行接口的验证以及测试，这个在其他测试工具里面有类似的posix接口验证工具，这类的工具就是跑测试用例，来输出通过或者不通过的列表 用此类的工具有个好的地方就是，能够对接口进行验证，来避免版本的更新带来的接口破坏 安装直接对官方的分支进行clone下来，总文件数不多，下载很快 1
ceph erasure默认的min_size分析
引言最近接触了两个集群都使用到了erasure code,一个集群是hammer版本的，一个环境是luminous版本的，两个环境都出现了incomplete，触发的原因有类似的地方，都是有osd的离线的问题 准备在本地环境进行复验的时候，发现了一个跟之前接触的erasure不同的地方，这里做个记录，以防后面出现同样的问题 分析过程准备了一个luminous的集群，使用默认的erasure的pro