本文转自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文件句柄数、过程和线程数、端口占用数等。此外慢盘、慢节点也更容易呈现，须要人工解决或者实现自动化。