17 个 Ceph 日常运维常见难点和故障的解决办法 | 运维进阶
Ceph是一个可靠地、自动重均衡、自动恢复的分布式存储系统，根据场景划分可以将Ceph分为三大块，分别是对象存储、块设备存储和文件系统服务。在虚拟化领域里，比较常用到的是Ceph的块设备存储，比如在OpenStack项目里，Ceph的块设备存储可以对接OpenStack的cinder后端存储、Glance的镜像存储和虚拟机的数据存储，比较直观的是Ceph集群可以提供一个raw格式的块存储来作为虚拟机实例的硬盘。
Ceph相比其它存储的优势点在于它不单单是存储，同时还充分利用了存储节点上的计算能力，在存储每一个数据时，都会通过计算得出该数据存储的位置，尽量将数据分布均衡，同时由于Ceph的良好设计，采用了CRUSH算法、HASH环等方法，使得它不存在传统的单点故障的问题，且随着规模的扩大性能并不会受到影响。
企业在实际Ceph遇到的五大问题：
一、扩容问题
Ceph中数据以PG为单位进行组织，因此当数据池中加入新的存储单元（OSD）时，通过调整OSDMAP会带来数据重平衡。正如提到的，如果涉及到多个OSD的扩容是可能导致可用PG中OSD小于min_size，从而发生PG不可用、IO阻塞的情况。为了尽量避免这种情况的出现，只能将扩容粒度变小，比如每次只扩容一个OSD或者一个机器、一个机柜（主要取决于存储隔离策略），但是这样注定会带来极大的运维工作量，甚至连扩容速度可能都赶不上数据增长速度。
二、数据迁移过程中的IO争用问题
在频繁数据迁移过程中带来的IO争用问题。当集群规模变大后，硬盘损坏、PG数量扩充可能会变得常态化。
三、PG数量调整问题
在解决了数据迁移过程中的PG可用性问题和IO争用问题后，提到的PG数量调整问题自然也就解决了。
四、集群利用率问题
存储成本问题主要是讲集群可用率问题，即：Ceph集群规模增大后，伪随机算法导致了存储资源分布不均衡，磁盘利用率方差过大的问题。
五、运维复杂度问题
Ceph本身是一个十分复杂的体系，要做到稳定运维非常看重团队的实力。
以下是一些典型问题解答，欢迎参考：
1、PG和PGP的区别是什么？调整 PGP 会不会引起 PG 内的对象的分裂？
@Lucien168：
首先来一段英文关于PG和PGP区别的解释：
PG = Placement Group
PGP = Placement Group for Placement purpose
pg_num = number of placement groups mapped to an OSD
When pg_num is increased for any pool, every PG of this pool splits into half, but they all remain mapped to their parent OSD.
Until this time, Ceph does not start rebalancing. Now, when you increase the pgp_num value for the same pool, PGs start to migrate from the parent to some other OSD, and cluster rebalancing starts. This is how PGP plays an important role.
By Karan Singh
以上是来自邮件列表的 Karan Singh 的PG和PGP的相关解释，他也是 Learning Ceph 和 Ceph Cookbook的作者，以上的解释没有问题，我们来看下具体在集群里面具体作用：
PG是指定存储池存储对象的目录有多少个，PGP是存储池PG的OSD分布组合个数
PG的增加会引起PG内的数据进行分裂，分裂到相同的OSD上新生成的PG当中
PGP的增加会引起部分PG的分布进行变化，但是不会引起PG内对象的变动
@宁泽阳：
我的理解是pgp用于承载pg，建议保持pg和pgp一致，调整pg数目时会进行pg内对象分裂，调整pgp时会引起pg重分布。
@zhuqibs：
（1）PG是指定存储池存储对象的目录有多少个，PGP是存储池PG的OSD分布组合个数
（2）PG的增加会引起PG内的数据进行分裂，分裂到相同的OSD上新生成的PG当中
（3）PGP的增加会引起部分PG的分布进行变化，但是不会引起PG内对象的变动
2、多节点组成Ceph存储集群后，时间如何同步？
@宁泽阳：
集群内配置ntp服务器，其他节点从这里同步时间即可。或者集群配置公司通用的ntp服务器也可以，如果有的话。
@wzpystcdc：
每台服务器开启NTP服务进行同步
@Lucien168：
通过ntp 然后进行监控， 如果不同步，集群也会出现告警提示。
@zhuqibs：
集群节点的时间同步，是传统的ntp服务
3、当Ceph集群存储容量快接近水位， 扩容一次扩多少节点合适？
@宁泽阳：
建议结合业务需求来进行扩容，覆盖业务需求后容量使用情况在50%左右为宜，即可以避免大量空间冗余浪费，也可以避免频繁扩容。
@zhuqibs：
缺省的水位线在85%~95%, 生产中一般将其改到70%~80%， 一旦达到一个区间，就可以考虑扩容了，节点数量要根据你一年内数据量增加的预估来计算
@Lucien168：
设置好水位线一般70%以内，然后进行扩容， 扩容的时候会有数据发送迁移， 控制好集群内数据迁移的大小， 避免迁移量太大， 影响客户端io请求延迟。
@大黑兔爱吃鱼：
主要和集群规模及单节点容量有关，最好在百分之60左右开始扩容，单个节点方式逐步增加，待数据平衡完成后在进行下一个节点，这样影响较小，比较安全。
4、调整pg数量有什么问题需要注意，会有什么影响，怎样提前规划好？
【问题描述】前期由于存储容量和集群规模不大，设置的pg数量也比较小，后期由于集群规模变大，势必需要调整pg数量，调整pg数量有什么问题需要注意，会有什么影响，怎样提前规划好？
@宁泽阳：
调整pg数目时会发生大量pg分裂迁移，建议在业务低峰期进行并做好恢复带宽限制。如果集群不能一次规划建设到位的话建议按照官方算法按照每次扩容完成后的总osd数目进行调整以获得最佳配比。
@zhuqibs：
（1）预设Ceph集群中的PG数至关重要，公式如下:
PG 总数 = (OSD 数 100) / 最大副本数
（2） 集群中单个池的PG数计算公式如下
PG 总数 = (OSD 数 100) / 最大副本数 / 池数
@Lucien168：
pg数量，一般都是按照pool的容量进行规划设置的。官方也有相关计算器，一般推进一个osd 大概100个osd左右进行评估设置。pg数量设置不好会影响数据均衡，影响性能。需要提前规划好。
5、Ceph扩容后，集群内数据迁移量过大，怎样不影响用户IO阻塞？
@宁泽阳：
可以限制重平衡的io数目和重平衡的io带宽减少对正常业务io的影响，或者只在业务低峰期打开重平衡。
@zhuqibs：
降低recovery的I/O优先级，使得Client IO优先
@djl2020：
通过对数据迁移进行时间和流量上的双重QOS策略来保证线上业务稳定运行。
@Lucien168：
集群内部流量迁移进行速率的控制， 优先保证客户端io请求流量。
6、集群规模增大后，伪随机算法导致存储资源分布不均衡，磁盘利用率方差过大， 怎样保证数据数据均衡，集群的利用率最大化？
@宁泽阳：
首先是要控制存储的分配情况，避免超分比过多，如果单个磁盘使用过多时，建议优先进行集群的整体扩容，将整体使用率降下来，使用率较低时集群的稳定性会更好。如果是在开发测试环境这种不太重要的用途上，可以配置osd定期自动reweight来重平衡osd的使用情况。
@zhuqibs：
频繁的调整osd的权重是不可取的，必须要做好规划，对数据规模进行必要的预估。
@djl2020：
在集群部署阶段，对业务的数据规模进行预估，调整osd的权重，减少数据量增加后，集群各个硬盘的使用率差值。在业务上限后，定期做好巡检，根据业务调整数据均衡。
@Lucien168：
一般这种情况，建议做个均衡插件，定期进行均衡设置，控制好均衡算法。
7、ceph集群扩容前要做哪些准备工作，如何确保扩容过程对业务影响最小？
@宁泽阳：
建议在规划存储池时对存储池的规模容量做好规划，一次建设完成，以避免对现有存储池的扩容，现有存储池扩容时会发生大量的数据迁移，迁移整体耗时会较长，如果必须扩容的话，可以提前评估业务低峰窗口，并限制数据平衡速率，在扩容完成后根据osd数目调整pg数目，减少对业务io的影响。
@zhuqibs：
crushmap改变导致的Ceph rebalance，所以 整体IO的下降（磁盘IO被反复的rebalance占满），甚至是某些数据暂时不可用。所以要在业务量较少的时间段进行扩容
@djl2020：
1.评估业务类型，根据业务关联性区分池内扩容和整池扩容。
2.评估业务模型特点，规避业务高峰期进行扩容和数据恢复。
3.评估线上业务流量和集群的性能，在扩容后对数据均衡进行流量控制。
@Lucien168：
扩容前，需要评估内部集群数据的迁移量，做好集群内部流量迁移的限速，避免迁移量太大，影响客户端io请求。
8、机器死机，如何不影响用户请求io，并且尽量让集群内部数据迁移量最小化，影响最小？
@宁泽阳：
死机后禁止数据恢复和数据重平衡，机器恢复后再打开数据平衡，此时不会影响pg和osd的映射关系，因此不会发生大量数据迁移，只会对旧数据进行追数更新，整个过程中都是不影响用户io的。
@djl2020：
设置集群维护模式，设置集群osd no-out，no-recovery,no-backfill；当有主机或OSD下线时，osd不会自动out，不会发生数据迁移，当主机恢复后，取消 no-recovery和no-backfill，集群只会对增量数据进行recovery和backfill，减少数据迁移量。
@Lucien168：
设置集群为维护模式， 避免有数据迁移的发生， 尽快恢复死机的机器， 重新拉起osd起来。
9、osd 龟速、无响应，会是哪些方面的问题？
@宁泽阳：
检查下集群是否存在slow request，如果存在的话可以看一下集中在哪些osd，这些osd是否硬盘故障或者网络中断，将这些osd踢出集群是否可以恢复。
@Lucien168：
一个反复出现的问题是 OSD 龟速或无响应。在深入性能问题前，你应该先确保不是其他故障。例如，确保你的网络运行正常、且 OSD 在运行，还要检查 OSD 是否被恢复流量拖住了。
Tip：较新版本的 Ceph 能更好地处理恢复，可防止恢复进程耗尽系统资源而导致 up 且 in 的 OSD 不可用或响应慢。
网络问题
Ceph 是一个分布式存储系统，所以它依赖于网络来互联 OSD 们、复制对象、从错误中恢复和检查心跳。网络问题会导致 OSD 延时和震荡（反复经历 up and down，详情可参考下文中的相关小节） 。
确保 Ceph 进程和 Ceph 依赖的进程已建立连接和/或在监听。
netstat -a | grep ceph
netstat -l | grep ceph
sudo netstat -p | grep ceph
检查网络统计信息。
netstat -s
@zhuqibs：
不太明白，是什么行为的慢
（1）io慢， 分布式存储的写，必然比单盘慢，因为有多副本，有网络传输时间；使用ssd盘，采用高速网络，是解决之道；
（2）如果是load balance慢， 那就是单看网络了；
其他，需要很多的参数调优
10、osd 启动报错了，应该从哪几个方面诊断排错?
@宁泽阳：
一般报错的提示都是比较明晰的，按照提示处理就可以了。
@Lucien168：
首先看报什么错误， 然后根据问题，找对应的解决方案，一般网上都有对应的解决方案。最后， 搞不定把详细的步骤和日志，帖到社区。
@zhuqibs：
原因太多了，主要工具就是看日志：
（1）文件系统的问题；
（2）认证的问题；
（3）osd状态不对；
（4）osd资源问题
……
11、如何用逻辑卷做OSD？
@宁泽阳：
用逻辑卷，物理卷或者文件来做osd都可以，流程都是一致的。
@zhuqibs：
使用bluestore
（1) 创建逻辑卷
vgcreate cache /dev/sdb lvcreate --size 100G --name db-lv-0 cache
vgcreate cache /dev/sdb lvcreate --size 100G --name wal-lv-0 cache
(2) 创建OSD
ceph-deploy osd create --bluestore storage1 --data /dev/sdc --block-db cache/db-lv-0 --block-wal cache/wal-lv-0
ceph-deploy osd create --bluestore storage2 --data /dev/sdc --block-db cache/db-lv-0 --block-wal cache/wal-lv-0
ceph-deploy osd create --bluestore storage3 --data /dev/sdc --block-db cache/db-lv-0 --block-wal cache/wal-lv-0
12、Ceph启动报错：Error ENOENT: osd.2 does not exist. create it before updating the crush map
@宁泽阳：
crushmap和实际osd对不上，实际没有osd2，却在crushmap里出现了，需要更新下crushmap或者创建下osd2。
@Lucien168：
提示很清楚， 根据提示多检查步骤。
@zhuqibs：
都说了osd不存在，创建一个呗
/usr/local/bin/ceph osd create
13、ceph报错，RuntimeError: Failed to connect any mon？
@宁泽阳：
该节点和monitor节点网络通讯异常的概率比较大，可以测一下到monitor的端口通不通。
@Lucien168：
ping mon地址， 检查mon日志，是否有错误日志。
@zhuqibs：
无法和monitor通讯，检查monitor的工作状态
14、客户端反馈ceph存储读写缓慢排查思路是怎么样的？
@宁泽阳：
从存储端-网络端-客户端逐层排查。首先确认慢是普遍慢还是个别客户端慢，个别客户端的负载如何，到存储端的网络路径和其他客户端相比如何，存储端是否有网络打满的情况，是否有不健康的磁盘，可以按照这种思路逐个去排查。
@zhuqibs：
1、 OSD请求缓慢的主要原因是：
a、 底层硬件的问题，例如磁盘驱动器，主机，机架或网络交换机。
b、网络问题。这些问题通常与flapping OSD有关。
c、系统负载。
2、 使用 dump_historic_ops administration socket命令确定慢速请求的类型
3、 使用ceph osd perf确定慢速磁盘
@Lucien168：
这种情况，一般去查看集群端，是否存在slow request 请求的日志， 如果有相关的慢请求日志， 跟进日志分析问题， 看看是否是某块盘出现问题。
15、ceph如何进行监控体系建设从而更快的进行故障恢复？
@宁泽阳：
首先是需要对事件和日志进行监控，同时需针对关键metric进行监控记录，事件及日志一般用于集群不可用的告警，metric主要用于提升存储系统性能，并发现潜在的性能隐患。推荐使用prometheus+grafana进行监控，官方是有ceph的exporter可以参考的。
@zhuqibs：
all-in-kubenetes，我们公司就用Prometheus+grafana把监控全包了，监控需要统一，工具太多，未必是好事。
@Lucien168：
ceph 监控 目前主流的Ceph开源监控软件有：Calamari、VSM、Inkscope、Ceph-Dash、Zabbix等，下面简单介绍下各个开源组件。也可以自己定制化开发。
监控指标按照等级进行划分， 设置相关的故障自愈等相关的措施。
16、ceph如何进行性能优化？
@宁泽阳：
从硬件配置选择，到bios-raid-os-ceph各层配置均按照社区建议方案进行调整，如果时间允许，可以对各参数进行压测以获得最佳配置。
@zhuqibs：
硬件层面
a、 硬件规划
b、SSD选择
c、BIOS设置
软件层面
a、Linux OS
b、Ceph Configurations
c、PG Number调整
d、CRUSH Map
e、其他因素
@Lucien168：
系统层面优化内核参数
客户端缓存
服务端缓存
调优队列大小等各种参数
@ntzs：
性能优化从底层硬件、网络、操作系统、软件参数、缓存等几方面
一、硬件：选用ceph合适的硬件。尽量增加SSD，合理分配到pool和index
二、网络：1.增加收发包ethtool -G eth4 rx 8192 tx 8192
2.增加网络带宽，区分集群内外网络
三、操作系统：1.调整包 echo "8192”> /sys/block/sda/queue/read_ahead_kb
2.减少swap使用vm.swappiness = 5
四、软件:
1.RGW（对象存储）
rgw_cache_enabled = true # 开启RGW cache
rgw_thread_pool_size = 2000
rgw_cache_lru_size = 20000
rgw_num_rados_handles = 128
2.RBD（块存储）
rbd_cache_enabled = true # 开启RBD cache
rbd_cache_size = 268435456
rbd_cache_max_dirty = 134217728
rbd_cache_max_dirty_age = 5
3.优化OSD scrub周期及相关参数
osd scrub begin hour = 4
osd scrub end hour = 12
osd scrub chunk min = 5
osd scrub chunk max = 5
osd scrub sleep = 1（不建议增大太多，会延长scrub完成时间）
osd scrub min interval = 2592000
osd scrub max interval = 2592000
osd deep scrub interval = 2419200
osd scrub load threshold = 0.30
osd scrub during recovery = false
osd scrub priority = 5
osd scrub interval randomize ratio = 0.35
五、缓存：增加磁盘缓存到SSD上（有版本要求） ceph-volume lvmcache add
17、如何发现和解决关键的存储问题？
【问题描述】Ceph分为三大块，分别是对象存储、块设备存储和文件系统服务。在实际运营中，如何发现和解决关键的存储问题？尤其是随着规模的扩大与业务的几何级数的扩张，存在运维中不可预测的问题，如何提前预判和防治？
@宁泽阳：
规模扩大和业务扩张是一个过程，在这个过程中建议加强对网络和磁盘IO这些容易出现问题的点的监控并进行历史趋势分析，从趋势中发现性能容量的瓶颈，并尽量将瓶颈提前消灭掉。
@zhuqibs：
不可预知的问题，要解决岂不是先知。
（1）全方位的监控是解决问题的问题的其中之一方法，thanos+Prometheus+grafana能同时监控很多kubenetes集群；
（2）可靠高速的网络，大部分ceph问题都是由网络引起的，ceph性能不仅靠磁盘性能，更靠高速的网络。
（3）kubenetes的自愈功能，kubenetes考虑了一部分的自愈功能
@lhs0981101410：
加强日常的巡检
@Daniel1111：
规模扩大和业务扩张需要关注存储节点资源的消耗，除了CPU、MEM、Disk io util、NIC throughout，还需要关注FD文件句柄数、进程和线程数、端口占用数等。此外慢盘、慢节点也更容易出现，需要人工处理或者实现自动化。
更多相关文章
- docker搭建mongodb分片集群
- ODL分布式集群底层实现分析
- kubernetes证书过期解决方案
- 消息中间件-技术专区-RocketMQ架构原理
- 服务复杂且集群规模扩大后，阿里妈妈怎样提升部署和构建效率？
- [业界方案] Yarn的业界解决方案和未来方向
- vSAN集群 无法识别磁盘处理
- aipai服务架构
- redis-cluster集群总结