云存储硬核技术内幕——(12) 皮洛士惨胜罗马军团

新年伊始，万象更新。

方老师还没来得及回到深南大道10000号，已经收到了很多问题。其中，最有意思的一个问题是：

Ceph有什么问题与缺陷？

这个问题很难，也很简单。

作为一个开源软件，最大的缺陷就是，缺乏企业级别的SLA。

什么是企业级别的SLA呢？

让我们举一个栗子。

方老师的朋友，H老师，因工(搞)作(钱)需要，想拉一条专线从北京天通苑的家，到坐落于北京像素(不要问我为什么是这里，问就回答社会主义核心价值观)的工作室。

由于家与工作室之间需要网络互通，H老师打算找运营商，在两个站点之间建立一条100M带宽的MSTP企业专线，但一月上万元的费用让H老师望而却步……

H老师决定，利用家用路由器的IPSec VPN功能，在两个站点之间利用互联网线路建立IPSec VPN通道代替企业专线功能。那么，二者之间的区别是什么呢？

原来，企业专线的可用性是99.9%，持续故障时间不大于4小时。也就是说，ISP承诺，每年线路不可用时间不多于8小时，故障从报修到修复不多于4小时。而家庭宽带的可用性是80%，持续故障时间不大于72小时。大家可以自行计算平均每年无故障时间。

因此，H老师这种行为搭建的VPN通道只能是凑合着用，离真正的企业级线路还有较大的距离。

回到分布式存储的话题，我们发现，企业级SLA对业务可用性的要求一般是5个9，少数业务甚至要求6个9，也就是每年故障时间不得超过5分钟甚至30秒。而实际上，2路服务器本身的SLA大概为99.99%到99.995%，单块硬盘可用性一般为99.9%到99.99%之间——这就是为什么企业级别存储需要使用RAID，纠删码和多副本机制的根本原因：使用充分的冗余设计，让3个9到4个9的服务器/磁盘搭建起5个9到6个9的高可用系统。

实际上，对于冗余部件故障后的处理，才是搭建高可用系统的关键。Ceph集群中，当一块硬盘损坏时，有自动或手动恢复两种模式可选。在自动恢复模式下，可以指定备用盘，磁盘损坏时会将数据在备用盘上恢复，而手动恢复模式下必须手工替换磁盘才能恢复。显然，这两种模式都有企业级应用难以接受的缺陷。

企业级应用还有一个非常重要的要求：资源利用率——这个指标意味着投入的金钱到底能有多少产出。Ceph在这点上也有一些地方还需要改进。我们知道，Ceph的每个对象，通过CRUSH算法被分配到主副本及其他副本所在的物理磁盘并落盘。但是，CRUSH算法是一种伪随机算法。这就意味着，并不可能保证，从存储数据量的角度看，每个磁盘的负载是均衡的，如下图所示：

如图，当有磁盘存储满(红色磁盘)的时候，整个Ceph集群将停止工作——CRUSH算法无法保证新的对象不落在满的磁盘上。而且，磁盘数量越多，这种现象出现的可能性越大。在实践中，Ceph集群的真实可用容量很难超过理论容量的75%。

当Ceph集群容量接近警戒线时，有两个选择：

A：在较满的磁盘即将爆满时，手工调低它的reweight。但这种行为实际上是割地事秦，很快又会遇到另一个磁盘接近爆满。我们知道，在Ceph集群中，物理磁盘往往多达上百个，也就是说，管理员需要手工重复数百次这样的工作——像苏洵在《六国论》里面形容的那样：“今日割五城，明日割十城，然后得一夕安寝。起视四境，而秦兵又至矣……”

B：当Ceph集群使用量到达某个警戒值时，启动扩容。先抛开经济因素不谈，这种行为实际上属于皮洛士惨胜罗马军团的行为。随着Ceph集群的扩张，管控节点问题导致集群分裂或整集群业务出问题的的风险增加(后面会详细论述)，最终由于集群过大导致业务不可用。

因此，在规模较大，对可靠性要求高(如跑数据库)的场景，我们需要一个高可靠的分布式存储方案。

小故事：皮洛士是古希腊伊庇鲁斯国王，率领战象军团进攻罗马，虽然付出沉重代价取得了几场战役的胜利，终因实力消耗过大在整场战争中失败，依附的城邦也纷纷背离，最终病逝于征战途中。