最近看到了有人的环境出现了出现了卡在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 这个在一般情况下会出现不同的需求： 慢点可以一定不能出问题，不能中断业务 越快迁移完越好，早点结束维护服务 需要又快又不能影响业务 这个需要根据自己可以掌控的程度来进行控制，首先环境的不同，影响不同，迁移数据量，网卡的带宽都是重要的影响因素，从整体上可以根据自己的环境按照上面的三个要求中的一个进行控制 上面的三种情况：第一个慢点迁移不能出问题，这个处理方式比较简单，直接将相关参数控制到最低的值 ...

准备centos7基础系统首先安装基础系统centos7 在安装选项那里选择base web server ，选择其他的也可以，选择mini安装会缺很多常用的软件包，后续需要一个个安装比较麻烦 关闭防火墙相关1234[root@inkscope ~]# setenforce 0[root@inkscope ~]# sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config[root@inkscope ~]# systemctl stop firewalld[root@inkscope ~]# systemctl disable firewalld 更新源相关的123[root@inkscope ~]# rm -rf /etc/yum.repos.d/*.repo[root@inkscope ~]# wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo[root@inksco ...

更新在经历了好几天后，失效的环境最终变成了可用状态，只能说有的时候不放弃还真是有点用的 在不久前处理了一个故障恢复以后，又碰上一个群友的集群出现了严重故障，本篇将记录这个中间大致处理的过程，一些细节在以后会补充 首先看到给出的截图显示的是大量的pg处于异常的状态，从经验上判断，环境要么处于down机的边缘，或者是刚经历了一次大量的重启，这个时候集群可以说是前端的访问肯定全断的，这个故障的时候资源一般会比较紧张，所以在启动的过程中也要注意不要触发更大面积的down机，对于集群来说是会有连带效应的 在启动了部分osd后，集群还是有大量的pg出现的是down+peering的状态，而发现down的osd实际全部在一台服务器上的，这个从ceph的架构来说是不应该出现这个状态的，这个可能是在down机过程中，频繁的pg的状态变化造成了pg的状态停留在之前的down的状态上，而pg出现锁死的状况，这个在之前的那位群友的环境中出现过一次，那个是多机有osd出现异常的情况，这次是单机出现的情况 尝试加大日志级别，从几个osd里面看日志出现两类的异常，从后面的处理的情况来看，实际这个是触发了两个bug， ...

ceph的在正常运行的时候基本不会出现故障，出现故障一般在变动的时候，具体有下面几种可能出现的情形 软件升级 增加存储节点 减少存储节点 调整副本数目 调整pg数目 磁盘出现损坏 节点网络出现异常 以上这些操作过程中是最可能出现异常的情形，并不是一定会出问题，以上问题除了网络和磁盘问题出现的异常是基本无法避免外，其他出现的时候，一般是非正常操作引起的，也就是我通常认为的人为事故，这个一般出现在操作的不谨慎上 本篇记录了一次故障的修复过程，这个故障不是出现在我们公司的产品上，是看到一个ceph社区群里有一个成员在里面问到一个异常是否能解决，这个不同于普通的问题，从他贴出的信息来看，集群已经是非常严重的状态了 正好看到是周五，周六还可以休息下，所以即使快到了晚上12点了，我还是联系了一下那哥们，从简短的几句交流后，基本可以判断对方对于ceph基本处于刚接触的阶段，在询问是否有其他人能协助他做一些比较有难度的操作的时候，他说没有，就他一个人，我想在目前中国很多公司，都是让一个并不太熟悉ceph的运维人员，或者完全就是开发人员维护着存储着非常宝贵的数据的云存储环境，上面运行的应该都是客户的 ...

在centos6以及以前的osd版本，在启动osd的时候，回去根据ceph.conf的配置文件进行挂载osd，然后进行进程的启动，这个格式是这样的 123[osd.0]host = hostnamedevs=/dev/sdb1 启动的时候就会把sdb1盘符挂载到0的目录里面去了 然后在centos7的版本的时候，发现居然不写配置文件也能够自动挂载启动，这个地方是什么地方发生了变化，在做了一些日志的查询以后，发现centos7下居然做了一个改变 12[root@lab8106 ~]# systemctl list-unit-files |grep ceph-diskceph-disk@.service static 可以看到有这个服务 我们来验证下这个服务先停止服务1systemctl stop ceph-osd@1 umount挂载点1umount /var/lib/ceph/osd/ceph-1 现在已经没有挂载点了 现在执行下面的服务（我的sdc1是刚刚的osd.1）12345678910111213141516[root@la ...

RBD 的 mirroring 功能将会在下一个稳定版本Jewel中实现，这个Jewel版本已经发布了第一个版本10.1.0,这个功能已经在这个发布的版本中实现了 一、基本原理我们试图解决的或者至少需要克服的问题是，ceph在内部是强一致性的，这个对于跨区域的情况数据同步是无法接受的，一个请求需要异地返回再确认完成，这个在性能上肯定是无法接受的，这就是为什么基本上无法部署跨区域的ceph集群 因此我们需要有一种机制能够让我们在不同区域的集群之间复制块设备。这个能够帮助我们实现两个功能： 灾难恢复 全球块设备分布（跨地理位置） 二、内部的实现 从上图所示是进行的主备模式的备份，其实这个只是看怎么应用了，在里面是自动实现的主主的模式，双向同步的，只是在应用中需要注意不要去同时操作同一个image，这个功能是作为主备去使用的，以备真正有问题的时候去实现故障恢复，这个同步是异步的 二、一个新的进程一个新的守护程序：rbd-mirror 将会负责将一个镜像从一个集群同步到另一个，rbd-mirror需要在两个集群上都配置，它会同时连接本地和远程的集群。在jewel版本中还是一对一的方式，在 ...