本文转自 twt 社区。
【导读】Ceph 日常运维中有几类常见问题，社区日前组织 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 文件句柄数、过程和线程数、端口占用数等。此外慢盘、慢节点也更容易呈现，须要人工解决或者实现自动化。