快速识别Ceph分布式存储的五大问题

首先，分析Ceph运维中遇到的问题是真实存在的，甚至在实际的运维过程中还出现过其他更复杂的问题。因为最初的Ceph只是社区提供的一套开源版，因而想要实现产品化需要趟过很多次“坑”，就像最早的安卓系统一样。 任何产品在一开始都难以做到十全十美，因为技术本身就是在发现问题与解决问题的道路上不断前进发展的。

一、扩容问题

Ceph本身基于Crush算法，具备了多种数据复制策略，可以选择在磁盘、主机、机柜等等位置附着。例如：如果采取3副本的数据保护策略，就可以通过复制策略来决定这3个副本是否同时分布在不同的磁盘、不同的主机、不同的隔离域、不同的机柜等位置来保证部分硬件故障后数据安全性和服务运行不中断。

Ceph底层是用资源池（POOL）来实现数据逻辑隔离，往往我们会出现因容量或性能不足需要对资源池进行扩容的问题，但是在容量扩容过程中，势必会带来进行数据重新平衡的要求。Ceph中数据以PG为单位进行组织，因此当数据池中加入新的存储单元（OSD）时，通过调整OSDMAP会带来数据重平衡。

如果涉及到多个OSD的扩容是可能导致可用PG中OSD小于min_size，从而发生PG不可用、IO阻塞的情况。为了尽量避免这种情况的出现，只能将扩容粒度变小，比如每次只扩容一个OSD或者一个机器、一个机柜（主要取决于存储隔离策略），但是这样注定会带来极大的运维工作量，甚至连扩容速度可能都赶不上数据增长速度。

正是针对这个问题，元核云分布式存储产品在运维管理平台层面进行了优化。扩容发生时，运维人员只需要将待扩容的服务器信息以及策略加入到运维管理平台中，后面的事情都由运维管理平台进行自动化处理。简单来说，运维平台会根据PG的状态和待扩容OSD资源，寻求一个最优的扩容方式，即在不影响PG可用性的情况下，循序渐进地进行OSD扩容，直到扩容动作完全完成为止。

例如：在三副本的场景下，当某一个PG加入两个OSD后，运维平台会通过算法把扩容分为两次完成，每次仅扩容一个OSD，这样就能保证PG的min_size始终大于1。而这整个过程完全由运维平台自动完成，对运维管理员完全透明。

二、数据迁移过程中的IO争用问题

当集群规模变大后，硬盘损坏、PG数量扩充可能会变得常态化。以运维经验来看，客户大概每年都会有几次的相关运维操作。在运维过的所有集群中，最大的超过了1000个存储节点，而在这过程中会遭遇到每个月损坏1-2台硬盘、3个月左右进行一次集中换盘的情况。这些运维操作都需要通过数据迁移来进行数据恢复，数据恢复过程中会对硬盘的IO进行争用，如何有效、智能地控制并恢复IO，并做到使业务IO不受影响，是Ceph运维管理的核心工作。

三、PG数量调整问题

在解决了数据迁移过程中的PG可用性问题和IO争用问题后，关于文章中提到的PG数量调整问题自然也就解决了。

数据迁移本身是一个常态化的过程，当控制了数据在迁移过程中的不良影响，同时在OSDMap变化过程中，PG始终能够保持可用状态，那么就并不会有调整PG数量而带来灾难性的后果。 何况，从实际上看来PG的调整确实也不是一个经常性的动作。

四、集群利用率问题

Ceph集群规模增大后，伪随机算法导致了存储资源分布不均衡，磁盘利用率方差过大的问题。其实要做到保证每块盘的数据均衡，这是一个比较复杂的过程。因为首先要确保数据分布能够遵循每个Pool的Rule-Set规则，同时又要保证每个Pool对应的PG较为合理的分布在每个OSD中（因为有些Pool是放元数据的，并不会承载大量的数据），同时还要保证当PG数量发生变化时不会发生灾难性的数据迁移（stable_mod）。

五、运维复杂度问题

Ceph本身是一个十分复杂的体系，要做到稳定运维非常看重团队的实力。除了对Ceph核心需要进行了深度优化，还需要支持跨数据中心多Ceph集群的自动化运维管理平台，能极大提高运维效率、降低Ceph存储集群运维成本。

软件定义存储软件系统属于工程型项目，需要大规模的生产实践经验和时间积累，遇“坑”填“坑”，才能保证其产品的成熟度。存储毕竟是底层核心的关键技术产品，数据的最后一道防线，如果要正式进行生产应用，还是建议大家使用成熟的商业化Ceph存储产品。

＊部分图片信息来源于网络