ceph是目前开源分布式存储里面最好的一个，但是在高负载下会有很多异常的情况会发生，有些问题无法完全避免，但是可以进行一定的控制，比如：在虚拟化场景下，重启osd会让虚拟机挂起的情况 重新启动osd会给这个osd进程所在的磁盘带来额外的负载，随着前面业务的需求的增长，会增加对存储的I/O的需求，虽然这个对于整个业务系统来说是好事，但是在某些情况下，会越来越接近存储吞吐量的极限，通常情况下没有异常发生的时候，都是正常的，一旦发生异常，集群超过了临界值，性能会变得剧烈的抖动 对于这种情况，一般会升级硬件来避免集群从一个高负载的集群变成一个过载的集群。本章节的重点在重启osd进程这个问题 问题分析OSD重启是需要重视的，这个地方是ceph的一个设计的弱点。ceph集群有很多的OSD进程，OSD管理对磁盘上的对象的访问，磁盘的对象被分布到PG组当中，对象有相同的分布，副本会在相同的PG当中存在，如果不理解可以看看（ceph概览） 当集群OSD进程出现down的情况，会被mon认为 “OUT” 了，这个 “OUT” 不是触发迁移的那个 “OUT”，是不服务的 “OUT” ,这个OSD上 ...

前情介绍SPDKSPDK的全称为Storage Performance Development Kit ，是Intel发起的一个开源驱动项目，这个是一个开发套件，可以让应用程序在用户态去访问存储资源，具体做能做什么可以去官网看一下 SPDK官网 NVMENVMe其实与AHCI一样都是逻辑设备接口标准，NVMe全称Non-Volatile Memory Express，非易失性存储器标准，是使用PCI-E通道的SSD一种规范，NVMe的设计之初就有充分利用到PCI-E SSD的低延时以及并行性，还有当代处理器、平台与应用的并行性。SSD的并行性可以充分被主机的硬件与软件充分利用，相比与现在的AHCI标准，NVMe标准可以带来多方面的性能提升。 BluestoreBlueStore 是用来存储ceph的数据的地方，提供了一种在块设备上直接写入方式的存储。这个是因为之前ceph社区尝试做了一个kvstore，但是性能达不到想要的效果，然后基于rocksdb的原型，重新开发了一套存储系统，BlueStore直接消耗原始分区。还有一个分区是存储元数据的，实际上就是一个RocksDB键/ ...

如果是在做ceph的配置，我们会经常遇到这几个问题 问：ceph需要配置几个mon答：配置一个可以，但是坏了一个就不行了，需要配置只是三个mon，并且需要是奇数个 问：ceph的mon能跟osd放在一起么，需要配置很好么？答：能跟放在一起，但是建议在环境允许的情况下一定独立机器，并且mon的配置能好尽量好，能上ssd就上ssd 这两个问题的答案不能说是错的，但是为什么这么说，这么说有没有问题，这篇文章将根据实际的数据来告诉你，到底mon的极限在哪里，为什么都说要奇数，偶数难道就不行么 前言本篇将从真实的实践中，让你更能够理解mon的故障极限，本次测试的场景数据样本足够大，最大的一个测试使用了10个mon，我想目前就算PB基本的ceph集群里也没有人会超过10个mon，所以足够覆盖大部分的场景，先来一个数据图看下10个mon的集群长什么样 123456789cluster ace3c18f-b4a5-4342-a598-8104a770d4a8 health HEALTH_OK monmap e10: 10 mons at {10=192.168.8.107 ...

jewel版本新增加了一个驱动NBD，允许librbd实现一个内核级别的rbd NBD相比较于kernel rbd： rbd-ko是根据内核主线走的，升级kernel rbd需要升级到相应的内核，改动太大 rbd-ko的开发要慢于librbd，需要很多的时间才能追赶上librbd rbd-nbd是通过librbd这个用户空间通过nbd的内核模块实现了内核级别的驱动，稳定性和性能都有保障 怎么理解用户态和内核态？ librbd就是用户态，一般的kvm对接的就是librbd的 kernel rbd就是内核态，这个是一个内核模块，是内核直接与osd交互的，一般来说内核态的性能会优于用户态 下面来做下基本的操作：创建一个image1[root@lab8106 ~]# rbd create testnbdrbd -s 10G 映射这个image12[root@lab8106 ~]# rbd-nbd map rbd/testnbdrbd/dev/nbd0 查询已经映射的nbd12[root@lab8106 ~]# rbd-nbd list-mapped/dev/nbd0 上面说了这么多， ...

之前测试了下，发现calamari不支持jewel版本的，是因为接口了有了一些变化，在提出这个问题后，作者给出了回答，说肯定会支持的，并且做了一点小的改动，就可以支持了，这个作者merge了到了github的一些分支当中，但是还没有merge到最新的1.4的分支合master分支当中，这个可能是因为1.4还在做一些功能的开发 我使用作者的修改好的分支打好了包，直接可以使用，测试了ubuntu14.04 和centos 7的版本都可以使用，下面是百度云的链接，欢迎使用和测试 ubuntu版本下载地址：ubuntu-jewel-calamari密码：h61u centos7版本下载地址centos-jewel-calamari密码：gbmr 变更记录 Why Who When 创建 武汉-运维-磨渣 2016-05-16 修改资源，解决无法获取iops和容量的bug 武汉-运维-磨渣 2016-07-12 更新网盘失效链接 武汉-运维-磨渣 2017-06-01

最近看到了有人的环境出现了出现了卡在active+remapped状态，并且卡住不动的状态，从pg的状态去看，这个pg值分配了主的pg，没有分配到副本的osd，集群的其他设置一切正常 这个从网上搜寻到的资料来看，大多数都是由于不均衡的主机osd引起的，所谓不平衡的osd 一台机器上面的磁盘的容量不一样，有的3T，有的1T 两台主机上面的OSD个数不一样，有的5个，有的2个 这样会造成主机的crush 的weight的差别很大的问题，以及分布算法上的不平衡问题，建议对于一个存储池来说，它所映射的osd至少需要是磁盘大小一致和个数一致的 这个问题我在我的环境下做了复现，确实有卡在remapped的问题 出现这个情况一般是什么操作引起的？做osd的reweight的操作引起的，这个因为一般在做reweight的操作的时候，根据算法，这个上面的pg是会尽量分布在这个主机上的，而crush reweight不变的情况下，去修改osd 的reweight的时候，可能算法上会出现无法映射的问题 怎么解决这个问题？直接做osd crush reweigh的调整即可避免这个问题，这个straw算法里 ...

在工作当中，很多时候我们在去分析一个性能的时候，会产生大量的数据，面对数据的时候我们一般应该会有以下几个处理过程 直接肉眼看这个属于第一个级别，比如监控系统负载的时候去用top观察，这个方法是我最开始经常使用的一种方法，这个适合异常的时候使用，但是实际上获取的数据是有偏差的 有监控系统使用数据监控系统对需要监控的数据进行监控，这个前提是有一个监控系统，并且方便的去增加数据，可以根据需求去设定数据，这个监控系统有很多，能可视化的也很多，这篇文章就不做介绍 使用监控脚本采集数据，采用excel进行可视化使用脚本收集大量的数据，然后将数据导入到excel当中，然后显示出来，这个是我们公司测试人员采用的方法，也是比较容易实现的一个方式 也可能还有其他的方法，总之一图胜千言，通过图形来展示数据，会获取到更多的信息，我也一直在寻找一些方案来方便的展示数据，从目前的监控系统来看，一般的实现方法都是 数据采集到数据库 使用图形展示数据库中间的问题 我现在需要的一个功能就是，使用一个采集工具将数据收集起来，然后直接将数据输出为图片，这个图片的渲染是可以根据我的需要进行定制的，最近在研究web自动 ...

MON的稳定性问题： mon的选举风暴影响客户端IO LevelDB的暴涨 频繁的客户端请求的DDOS mon选举风暴：monmap会因为mon之间或者mon与客户端之间网络的影响或者消息传递的异常发生变化,从而触发选举会造成客户端的请求变慢或者锁住 LevelDB的暴涨：LevelDB的大小会涨到几十GB然后影响了osd的请求会造成客户端的请求变慢或者锁住 频繁的客户端请求的DDOS：mon的响应因为levelDB变慢或者选举风暴，都会造成客户端发出大量的消息流让客户端操作失效，包括卷创建，rbd的连接 解决办法：LevelDB的暴涨的问题解决办法升级ceph的版本，这个在0.94.6版本解决了这个问题 选举风暴问题解决办法 [mon]mon_lease = 20 (default = 5)mon_lease_renew_interval = 12 (default 3)mon_lease_ack_timeout = 40 (default 10)mon_accept_timeout = 40 (default 10)[clien ...

ceph在增加osd的时候会触发backfill，让数据得到平均，触发数据的迁移ceph在移除osd的时候需要在节点上进行数据的恢复，也有数据的迁移和生成 只要是集群里面有数据的变动就会有网卡流量，cpu，内存等资源的占用，并且最重要的是还有磁盘的占用，这个客户端也是需要对磁盘进行访问的，当请求出现碰撞的时候，肯定会比正常的情况下要慢很多，而且还有可能因为资源方面的原因而引起机器down机等异常状况的出现 主要引起的问题可能： 在peering的时候 block 了IO请求 在backfill的引起了slow requests 上面的两个情况会引起客户端的降速和出现soft lockup 这个在一般情况下会出现不同的需求： 慢点可以一定不能出问题，不能中断业务 越快迁移完越好，早点结束维护服务 需要又快又不能影响业务 这个需要根据自己可以掌控的程度来进行控制，首先环境的不同，影响不同，迁移数据量，网卡的带宽都是重要的影响因素，从整体上可以根据自己的环境按照上面的三个要求中的一个进行控制 上面的三种情况：第一个慢点迁移不能出问题，这个处理方式比较简单，直接将相关参数控制到最低的值 ...