vdbench测试实时可视化显示


bench

前言

前一段时间碰到一个系统,用rados bench 去跑都还比较正常,但是一跑数据库就非常慢,测试工具会抛出延时过大的提示,经过排查发现,云平台中有一台虚拟机还运行着备份数据库的服务,而这个备份软件是需要反复写一个标记文件的,因为这个标记文件只对应了一个对象,一个对象对应了一个pg,一个pg对应到固定的ssd上面,那个ssd的io几乎被这一个操作给打满了,然后全局的请求到了这个osd上面的时候,都会变得慢和卡顿

出现这种情况,在业务层面可能需要做好分离,我们在面对这种情况的时候该如何提前就做好测试,对自己的性能的剩余性能做一个更好的评估,什么时候需要分离,什么时候不需要分离,这个都是需要用数据来说话的

性能测试的时候,经常面临的这些问题,你告诉我这个环境能跑多少iops,带宽能多大,我的数据库能不能跑,这个我也没法回答,一般来说我都是说需要根据环境进行测试,这个测试也只能根据自己设计的模型进行测试,而越接近用户使用场景的业务模型,就越能反应真实的业务能力,最好的测试就是直接拿对接的软件进行测试,接什么业务就用什么业务压

处理ceph incompelete的经验


fix.png-40kB

前言

最近已经见到几个环境出现过incompelete了,这个在很久以前Jewel正在合入mark-complete工具的时候就有做过类似的处理,但是随着处理的环境越来越多,这个地方还是有些需要注意的,本篇是写一些需要注意的点

一般来说是环境有多个机器同时坏盘或者掉电,或者掉主机引起的

cephfs根据存储池显示df容量


pool.png-115.2kB

前言

如果用cephfs比较多,应该都知道,在cephfs的客户端进行mount以后,看到的容量显示的是集群的总的容量,也就是你的总的磁盘空间是多少这个地方显示的就是多少

这个一直都是这样显示的,我们之前在hammer版本的时候,阿茂和大黄一起在公司内部实现了这个功能,社区会慢慢的集成一些类似的面向面向商业用户的需求

社区已经开发了一个版本,接口都做的差不多了,那么稍微改改,就能实现想要的需求的

本篇内的改动是基于内核客户端代码的改动,改动很小,应该能够看的懂

快速构建ceph可视化监控系统


granfa

前言

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.rpm
http://static.zybuluo.com/zphj1987/1nu2k4cpcery94q2re3u6s1t/ceph-cluster_rev1.json
http://static.zybuluo.com/zphj1987/7ro7up6r03kx52rkwy1qjuwm/prometheus-2.3.2-1.x86_64.rpm
http://mysrc.cn-bj.ufileos.com/grafana-5.2.1-1.x86_64.rpm

以上资源均可以直接用wget进行下载,然后直接安装

利用s3-test进行ceph的接口兼容性测试


s3

前言

ceph的rgw能够提供一个兼容性的s3的接口,既然是兼容性,当然不可能是所有接口都会兼容,那么我们需要有一个工具来进行接口的验证以及测试,这个在其他测试工具里面有类似的posix接口验证工具,这类的工具就是跑测试用例,来输出通过或者不通过的列表

用此类的工具有个好的地方就是,能够对接口进行验证,来避免版本的更新带来的接口破坏

ceph erasure默认的min_size分析


desk.jpg-47.1kB

引言

最近接触了两个集群都使用到了erasure code,一个集群是hammer版本的,一个环境是luminous版本的,两个环境都出现了incomplete,触发的原因有类似的地方,都是有osd的离线的问题

准备在本地环境进行复验的时候,发现了一个跟之前接触的erasure不同的地方,这里做个记录,以防后面出现同样的问题

cephfs元数据池故障的恢复

前言

cephfs 在L版本已经比较稳定了,这个稳定的意义个人觉得是在其故障恢复方面的成熟,一个文件系统可恢复是其稳定必须具备的属性,本篇就是根据官网的文档来实践下这个恢复的过程

实践过程

部署一个ceph Luminous集群

[root@lab102 ~]# ceph -v
ceph version 12.2.5 (cad919881333ac92274171586c827e01f554a70a) luminous (stable)

创建filestore

ceph-deploy osd create  lab102  --filestore  --data /dev/sdb1  --journal /dev/sdb2

这里想用filestore进行测试就按上面的方法去创建osd即可

ceph的ISCSI GATEWAY



gateway

前言

最开始接触这个是在L版本的监控平台里面看到的,有个iscsi网关,但是没看到有类似的介绍,然后通过接口查询到了一些资料,当时由于有比较多的东西需要新内核,新版本的支持,所以并没有配置出来,由于内核已经更新迭代了几个小版本了,经过测试验证可以跑起来了,这里只是把东西跑起来,性能相关的对比需要根据去做