更新在经历了好几天后，失效的环境最终变成了可用状态，只能说有的时候不放弃还真是有点用的 在不久前处理了一个故障恢复以后，又碰上一个群友的集群出现了严重故障，本篇将记录这个中间大致处理的过程，一些细节在以后会补充 首先看到给出的截图显示的是大量的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版本中还是一对一的方式，在 ...

ceph在Infernalis加入了一个功能是查询rbd的块设备的使用的大小，默认是可以查询的，但是无法快速查询，那么我们来看看这个功能是怎么开启的 ceph版本12root@lab8107:~/ceph# ceph -vceph version 9.2.0 (bb2ecea240f3a1d525bcb35670cb07bd1f0ca299) 创建RBD设备我们先来创建一个rbd 123456789root@lab8107:~/ceph# rbd create test --size 4000root@lab8107:~/ceph# rbd info testrbd image 'test': size 4000 MB in 1000 objects order 22 (4096 kB objects) block_name_prefix: rbd_data.10305695d26a format: 2 features: layering flags: 进行RBD容量使用查询我们来试一下rbd du命令 1234root@lab8107:~/ceph# rbd ...

Bluestore 作为 Ceph Jewel 版本推出的一个重大的更新，提供了一种之前没有的存储形式，一直以来ceph的存储方式一直是以filestore的方式存储的，也就是对象是以文件方式存储在osd的磁盘上的，pg是以目录的方式存在于osd的磁盘上的在发展过程中，中间出现了kvstore，这个还是存储在文件系统之上，以leveldb或者rocksdb的方式存储对象数据，这个也没有推广开来，性能上没有太大的改观，在某些情况下性能还低于filestore最终在sage的大力支持下，ceph社区准备撸一个新的文件系统，这个系统类似于rocksdb，但是数据是可以直接存储到裸设备上去的，也就是存储对象数据的地方是没有传统意义上的文件系统的，并且解决了一种被抱怨的写双份数据的问题，在filestore中，数据需要先写入journal再入磁盘，对于磁盘来说实际就是双份写了 在这里不做过多的探讨技术上的细节，bluestore处于开发阶段，在最新的版本的ceph中，发现已经集成了这个，虽然还是实验阶段，但是还是体现出其未来巨大的价值 环境准备由于没有测试大量的设备，就在一个小环境下进行性能的验 ...

通过dd来读取让硬盘灯闪来定位磁盘的位置 123456#!/bin/bashhd=$1for num in {1..5};do dd if="$hd" of="/dev/null" bs=4M count=1000 iflag=direct conv=noerror >/dev/null 2>&1 sleep 1done 写于: 2014年11月07日更新于: 2015年03月24日

在linux操作系统下，可能因为一些很小的误操作，都会造成非常重要的文件的丢失，而文件的备份并不是每时每刻都会注意到，一般是等到文件丢失了才会去想办法，这里讲下ceph.mon.keyring丢失的解决办法 1、没有启用部署认证的 auth_cluster_required =none 在进行部署的时候 ceph-deploy new 以后会生成ceph.mon.keyring文件,内容如下 123[mon.]key = AQBnutdWAAAAABAAPmLaAd9CeKaCRj1CIrztyA==caps mon = allow * 这个keyring在增加mon的时候，mon之间加密会用到的，如果在未开启认证的情况下，只需要在部署目录下面创建一个同名文件，里面填入一个格式相同的任意内容即可（需要有这个文件，不然无法部署新的mon)，在没有开启认证的时候是没有生成这个文件的 /var/lib/ceph/mon/ceph-lab8106/keyring 一般是在系统盘损坏的时候容易丢失这个部署目录,并且没有做备份 2、启用了部署认证 auth_cluster_requir ...

最近因为一个实验需要用到一个功能，需要快速的增加 ceph 的 osdmap 的 epoch 编号 查询osd的epoch编号12root@lab8107:~# ceph osd stat osdmap e4686: 8 osds: 8 up, 8 in 上面显示的 e4686 即为osdmap的epoch的编号 增加epoch现在需要增加1000 1ceph osd thrash 1000 执行完了后 12ceph osd statosdmap e5687: 8 osds: 3 up, 3 in; 232 remapped pgs 很快就增加了1000的编号，这个命令执行完了后，osd weight 会变成0，这个做下恢复即可，节点会down，调整下weight，恢复下状态就可以了