转载

2015年12月25日

在一个微信群里面，大家谈到外面拿出来分享的东西， PR 多而实际对人有用的分享少；

又把高度调整到国人更多喜欢吹水，不愿意分享干货；

那就从我做起吧；

把最近团队在 ceph 这边碰到的问题总结一下；分享一下；

ceph现状：

支持我们开发测试环境 20 0TB /1000 个云盘的存储；（本地 root 盘都跑在 local disk 上面）；基本配置：

7 node （刚刚扩容到 7--> 10 个节点，后续继续扩容到 20 个节点）； 2 套这样的集群；

12 sata*4tb

Centos7 .1

ceph 0. 87.2

无 ssd （计划添加）

万兆存储网络环境；

总体设计： Ceph 支持云盘；（从 GlusterFS 迁移过来的） VM 的 root 都跑在 openstack HV 的本地盘上；（ 1. 稳定； 2. 没有强 Failover 需求， 3 ，利用起来 HV 本地存储）

总结和分享一下我们碰到的问题：

问题 0 ：系统运营，设计先行；一开始的考虑，从 GlusterFS 迁移到 Ceph 之后，本来就已经限定了， ceph 只是支持所有 VM 的云盘需求；云盘包含了绝大部分的的开发测试环境的数据库（最大 / 最重要的极少数还是跑在物理 +flash 卡上），大数据开发测试环境（ hadoop/hbase/kafka), 以及开发测试环境的工具（包管理系统存储）等；开发测试环境用户会 abuse ，不受控的影响到其他 vm 对云盘的 IO 需求；改进点 1 ：按照上面用户的 Priority QOS 的需求，我们要把 ceph 拆分成两个 Pool ；保证 Priority 应用的 IO 需求；防止部分不严肃的用户影响大盘；

改进点 2 ：和每个 VM 限制 IO 一样，每个云盘也要限制 IO 能力；按照 provision 的容量来限制每个云盘的 io 能力；

问题 1 ：监控需要完善；系统运营，监控先行；我们的几个缺点：主要只是监控了 Ceph 的主机层面的关键 metrics ，和一部分 ceph 层面的；但是 ceph 本身的状态（是否 health_ok, 多少 degraded pg 等），是没有正确监控，展示的；

2015年12月25日

改进点 1 ：展示出了 raid degrade （磁盘 fail ），还需要监控 Media Error 的坏 Block 率；在磁盘彻底 Fail 之前主动替换掉；改进点 2 ：需要监控和展示整个集群和各个 pool 的 io 状况 (ceph cluster total xxKB read/second, xxKB write/second, xxx OP/Second) ， backfill_toofull PG#, degraded PG#, recovery object degraded #, misplaced object count#, misplaced object percentage#, near full OSD COUNT#, ceph cluster total space#, ceph cluster used space#, ceph cluster free space#; 改进点 3 ：需要能够看到每个集群上面 top IO 的来源；在 io 过载的时候，可以定位到，来自于什么用户的 IO ；

问题 2 ：维护的 SOP 换盘；在一次巡检里面，发现有一部分的 disk 包大量 media error ；（ megacli 检查）；之前只有在生产 hadoop 等节点上面有这个检查，在 ceph 节点上面没有这个检查；启动换盘；之前的换盘，都是一个一个硬盘的坏，发现和替换；结果这次运维的同学一下子换掉了一个机器上面的 4 个硬盘；上面的云盘用户纷纷报告 io 卡死。。。 action ：马上停止换盘；重新 online OSD ；等待 recover 完成，再晚上一个一个换盘；华为的破机器， RAID 卡比较低，必须对每个单独硬盘先做 raid0 ，才能用；团队不知道，重启了机器才能认到硬盘；(后续经过确认，是可以online重新认到硬盘的）扩容：为了保证扩容的 100% 稳定性，我们需要有完善的 SOP ；鉴于 re-balance 导致了上面的云盘不够稳定（用户 complain ），我们很谨慎的规划了扩容；第一次集群扩容还是蛮紧张的，毕竟是存储的扩容；要保证数据绝对不能丢，也要保证上面的用户影响尽量小；总结下来，没啥特别，核心思路，就是先加入磁盘， noin/recovery ，然后改成 in ， OSD 权重调整的非常低，逐步一点一点调高；尽量让每次 weight 调整，在 1am-7am 之间完成 rebalance ；但是这样的时间，就会拉的很长；每次晚上 re-balance ，也要尽量做到不影响用户（用户无感知），通过调低 re-balance 的 io 权重和相关参数（ osd_disk_threads / osd_recovery_op_priority / osd_recovery_threads ）