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

2022-08-04 15:31:47 浏览数 (3)

新年伊始,万象更新。

方老师还没来得及回到深南大道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集群的扩张,管控节点问题导致集群分裂或整集群业务出问题的的风险增加(后面会详细论述),最终由于集群过大导致业务不可用。

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

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

1 人点赞