jewel版本新增加了一个驱动NBD，允许librbd实现一个内核级别的rbd NBD相比较于kernel rbd： rbd-ko是根据内核主线走的，升级kernel rbd需要升级到相应的内核，改动太大 rbd-ko的开发要慢于librbd，需要很多的时间才能追赶上librbd rbd-nbd是通过librbd这个用户空间通过nbd的内核模块实现了内核级别的驱动，稳定性和性能都有保障 怎么理

之前测试了下，发现calamari不支持jewel版本的，是因为接口了有了一些变化，在提出这个问题后，作者给出了回答，说肯定会支持的，并且做了一点小的改动，就可以支持了，这个作者merge了到了github的一些分支当中，但是还没有merge到最新的1.4的分支合master分支当中，这个可能是因为1.4还在做一些功能的开发 我使用作者的修改好的分支打好了包，直接可以使用，测试了ubuntu14.

最近看到了有人的环境出现了出现了卡在active+remapped状态，并且卡住不动的状态，从pg的状态去看，这个pg值分配了主的pg，没有分配到副本的osd，集群的其他设置一切正常 这个从网上搜寻到的资料来看，大多数都是由于不均衡的主机osd引起的，所谓不平衡的osd 一台机器上面的磁盘的容量不一样，有的3T，有的1T 两台主机上面的OSD个数不一样，有的5个，有的2个 这样会造成主机的cr

在工作当中，很多时候我们在去分析一个性能的时候，会产生大量的数据，面对数据的时候我们一般应该会有以下几个处理过程 直接肉眼看这个属于第一个级别，比如监控系统负载的时候去用top观察，这个方法是我最开始经常使用的一种方法，这个适合异常的时候使用，但是实际上获取的数据是有偏差的 有监控系统使用数据监控系统对需要监控的数据进行监控，这个前提是有一个监控系统，并且方便的去增加数据，可以根据需求去设定数据

MON的稳定性问题： mon的选举风暴影响客户端IO LevelDB的暴涨 频繁的客户端请求的DDOS mon选举风暴：monmap会因为mon之间或者mon与客户端之间网络的影响或者消息传递的异常发生变化,从而触发选举会造成客户端的请求变慢或者锁住 LevelDB的暴涨：LevelDB的大小会涨到几十GB然后影响了osd的请求会造成客户端的请求变慢或者锁住 频繁的客户端请求的DDOS：mon的

ceph在增加osd的时候会触发backfill，让数据得到平均，触发数据的迁移ceph在移除osd的时候需要在节点上进行数据的恢复，也有数据的迁移和生成 只要是集群里面有数据的变动就会有网卡流量，cpu，内存等资源的占用，并且最重要的是还有磁盘的占用，这个客户端也是需要对磁盘进行访问的，当请求出现碰撞的时候，肯定会比正常的情况下要慢很多，而且还有可能因为资源方面的原因而引起机器down机等异常状

准备centos7基础系统首先安装基础系统centos7 在安装选项那里选择base web server ，选择其他的也可以，选择mini安装会缺很多常用的软件包，后续需要一个个安装比较麻烦 关闭防火墙相关1234[root@inkscope ~]# setenforce 0[root@inkscope ~]# sed -i 's/SELINUX=enforcing/SELINUX=d

更新在经历了好几天后，失效的环境最终变成了可用状态，只能说有的时候不放弃还真是有点用的 在不久前处理了一个故障恢复以后，又碰上一个群友的集群出现了严重故障，本篇将记录这个中间大致处理的过程，一些细节在以后会补充 首先看到给出的截图显示的是大量的pg处于异常的状态，从经验上判断，环境要么处于down机的边缘，或者是刚经历了一次大量的重启，这个时候集群可以说是前端的访问肯定全断的，这个故障的时候资源一

ceph的在正常运行的时候基本不会出现故障，出现故障一般在变动的时候，具体有下面几种可能出现的情形 软件升级 增加存储节点 减少存储节点 调整副本数目 调整pg数目 磁盘出现损坏 节点网络出现异常 以上这些操作过程中是最可能出现异常的情形，并不是一定会出问题，以上问题除了网络和磁盘问题出现的异常是基本无法避免外，其他出现的时候，一般是非正常操作引起的，也就是我通常认为的人为事故，这个一般出现在

在centos6以及以前的osd版本，在启动osd的时候，回去根据ceph.conf的配置文件进行挂载osd，然后进行进程的启动，这个格式是这样的 123[osd.0]host = hostnamedevs=/dev/sdb1 启动的时候就会把sdb1盘符挂载到0的目录里面去了 然后在centos7的版本的时候，发现居然不写配置文件也能够自动挂载启动，这个地方是什么地方发生了变化，在做了一些日志的