Ceph 知识摘录(常见故障、可用性测试)

高可用测试目的
为了验证集群没有单点故障，一个服务进程down 不影响业务。进程恢复后，集群状态正常。(稳定性、可靠性)

可用性相关设计
rgw、osd、Mon(Lead、非Lead) 节点宕机
rgw、osd、Mon 服务进程异常
rgw、osd、Mon 管理、业务、存储网异常
ceph-rest-api
keepalived 进程异常

三副本模式下：1个PG对应的1个OSD Down
纠删码模式下：1个PG对应的1个OSD Down 或者2个OSD Down

Mon 对应的时钟不一样步

磁盘故障、更换磁盘(日志检查是否disk error 故障，检查磁盘可否正常读写)

运维
版本升级、回退
集群容量使用率(85%，95%)

破坏性
三副本下，一个PG对应2个Osd被stop
三副本下，一个PG对应3个Osd被stop
纠删码4+2，一个PG对应3个Osd被stop
网络时延、频繁闪断

 

Mon节点故障处理

线上环境，Mon的个数是2n+1（n>=0）个，在线上至少3个，只要正常的节点数>=n+1，ceph的paxos算法能保证系统正常仲裁（quorum），若是ceph的Mon节点超过半数挂掉，没法仲裁，会阻塞对集群操做，直到超过半数Mon恢复。

解决方法:经过monmaptool导出monmap，初始化新的Mon节点。

 

数据盘替换流程

一、定位故障磁盘(SAS盘：sas2ircu/sas3ircu SATA盘：ledctl LSI-RAID卡:MegaCli64)，*物理硬盘与逻辑磁盘及挂载点的对应关系很重要*
二、中止故障OSD(停进程后,umount挂载点)
      虽然osd的服务已中止，然而他仍然被标记为IN（集群中）状态。只要他的状态仍是IN，集群就不会为它触发数据恢复。默认状况下，ceph集群须要5分钟来将一个DOWN状态的磁盘标记为OUT状态，而后开始数据恢复。能够手工将故障OSD标记为OUT。一旦该OSD被标记为OUT，ceph集群会为该OSD上的PG启动恢复过程。

• 当某个PG对应的OSD set中有一个OSD被标记为down时(假如是Primary被标记为down，则某个Replica会成为新的Primary，并处理全部读写 object请求)，则该PG处于active+degraded状态，也就是当前PG有效的副本数是N-1。

• 过了5分钟以后，假如仍是没法链接该OSD，则它被标记为out，Ceph会从新计算PG到OSD set的映射(当有新的OSD加入到集群时，也会从新计算全部PG到OSD set的映射)，以此保证PG的有效副本数是N。

三、删除故障OSD
     从ceph CRUSH map中移除
     从ceph 删除osd秘钥
     从ceph集群中删除该osd

     拔掉故障盘，插入新磁盘()

四、从新组建RAID

五、建立OSD，加入集群(格盘、起进程、加回集群)
      触发backfilling操做

 

Ceph中查找一个对象的位置
一、上传一个文件到pool（示例中叫作test）中     
rados -p  test put cirros cirros-0.3.2-x86_64-disk.img
二、查看pool中刚才上传的对象       
rados -p test ls | grep cirros
三、查看对象的位置信息       
ceph osd map test cirros       
输出结果：osdmap e20062 pool 'test' (13) object 'cirros' -> pg 13.9576dc54 (13.54) -> up ([5,3], p5) acting ([5,3], p5) 
这表明pool test中的cirros这个对象位于13.54这个pg中，而且位于osd5和osd3上（两个副本）。
四、进入到对应osd的存储目录，找到对应文件便可。     
cd /var/lib/ceph/osd/ceph-3/current/13.54_head; ls     
这个目录下存放了13.54这个pg中全部的object，能够根据指纹9576dc54来定位到具体的文件。

 

常见故障
Mon空间写满，集群网络不稳定
客户端不能链接：防火墙
PG故障：扩缩容
进程是否被卡住、重启进程

故障排查：开启调试模式、查看日志信息