最近有很多朋友拿着一篇关于“ceph运维那些坑”的文章来找我，起初我并没有在意，毕竟对于一个“新物种”来说，存在质疑是再正常不过的。不过，陆续有更多的合作伙伴甚至圈内同行来问我如何看待这篇文章时，我觉得做为一名Ceph开发和运维的技术者，理应站出来为Ceph说点什么。

首先，原作者分析Ceph运维中遇到的问题是真实存在的，甚至在实际的运维过程中还出现过其他更复杂的问题。因为最初的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。而这整个过程完全由运维平台自动完成，对运维管理员完全透明。