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