Server如何SAN(下):副本和管理

本文通过分析足球和篮球在团队精神上的不同侧重,从两大(规模、架构)四小(SSD、网络、副本、管理)共六个方面,来对比作为超融合架构根基的软件定义存储(具体到Server SAN),和融合架构常用的SAN存储设备。

轮换与替补:副本保冗余

 

一向以阵容厚度而为人称道的勇士队,在今年西决和总决赛期间突然发现,在强悍的对手面前,小前锋哈里森·巴恩斯成为薄弱环节。特别是在进攻中,巴恩斯不能稳定的把球投中,导致雷霆队和骑士队都可以把他放空,形成五防四的局面。

等到总决赛第五场,中锋安德鲁·博格特受伤,由于找不到合格的替补,这一问题就更加严重。结果勇士队连败三场,成为首支总决赛中3比1领先却被翻盘的球队。

赛季结束,勇士队放弃了巴恩斯和博格特,重金签下长期与LBJ齐名的超级巨星杜兰特。

足球队毕竟上场人数多一倍,有一个位置相对薄弱似乎还可以承受,但也要分情况:

  • 依靠少数明星球员的球队,其中一个不能上场,就有点类似于篮球了。譬如,今夏欧洲杯上的威尔士队,爆冷淘汰比利时队的比赛中,“二当家”阿隆·拉姆塞累积第二张黄牌,与后防中坚本·戴维斯一同在接下来的比赛中停赛,结果两球负于葡萄牙。

  • 实力雄厚如德国队,也无法承受2~4名主力球员缺阵。半决赛对东道主法国队,德国队中锋戈麦斯、后腰赫迪拉、中卫胡梅尔斯都不能上场。比赛中,替补赫迪拉的施魏因施泰格上半场送出点球;下半场另一名中卫热罗姆·博阿滕受伤,替换上场的穆斯塔菲防守经验不足,间接导致失掉第二球,德国队0比2遭淘汰。

葡萄牙队决赛中先失头牌,仍能在加时赛一击制胜,足以证明该队不是C罗“一个人的球队”。

最初的SAN存储系统构建于RAID(Redundant Array Of Independent Disks,独立磁盘冗余阵列)技术基础之上,经过多年的发展,RAID 5和6都已经很成熟了。

RAID 5牺牲1个硬盘的容量,RAID 6(通常)牺牲2个硬盘的容量,作为冗余。相应的,RAID 5能承受1个硬盘故障,RAID 6能承受2个硬盘同时故障,而不丢掉数据。热备(hot spare)盘就像RAID组中的替补球员,平时不上场,线上有“主力受伤或停赛”,赶紧顶上。

足球和篮球队中的替补队员,实力通常比相应位置的主力要差。RAID组中的“替补”倒不存在这个问题,新上来的状况可能还比被换下的“主力”好很多,问题是“换人”过程太长,充满风险。

根源依然是硬盘太慢,特别是大容量的低转速(如7200RPM及以下)硬盘,顺序写满一遍都要好几个小时。在替换掉故障盘,在新盘上重建数据时,RAID组中的其他硬盘可能还要响应正常的业务访问需求,会进一步拖慢重建速度。有可能需要一天,或更长的时间,才能完成RAID组的重建。

2007年测试的RAID 6(6+2)配置,1-3个盘掉线后的情况……几乎忘了那时自己做Gif的事儿

在这个过程中,RAID组中的其他硬盘都处于超负荷工作的状态。它们往往与故障盘同批制造、同期上线,在同样的环境中工作了同样的时间,有可能存在着同样的隐患,现在还要为挂了的“老朋友”加班,相继出问题的可能性很大。

所以,大容量低转速硬盘最好配置为RAID 6,在1个硬盘失效重建的过程中,还可以承受多1个硬盘失效而不丢失数据。

显然,一个RAID组中的硬盘数量越多,出现硬盘故障的几率也就越大。必须控制故障域的规模,如EMC的VMAX3家族,RAID 5可以配置为7+1,RAID 6可以配置为14+2。

即使是十几个15000RPM(15K RPM)硬盘组成的RAID组,能提供的IOPS也很有限(几千的水平),如果上面承载的业务出现热点,很可能成为性能瓶颈。存储厂商开发了一系列的技术,包括既能缓解单个硬盘性能压力又可以加快重建速度的各种所谓RAID 2.0,引入SSD作为Cache或分层存储,各有各的优势和局限性,这里就不展开讨论了。


“仅仅故障处理还是不够,亚健康也要处理”

从GFS和HDFS开始,软件定义存储普遍采用三副本的方式提供数据冗余,还可以获得较好的读操作性能,这对(提供块存储接口的)Server SAN尤为重要。

FusionCube分布式存储提供二副本或三副本的机制来保证数据的可靠性,即同一份数据可以复制保存为2~3个副本。数据的副本数设置决定了资源池初始化时的数据分布,分区的主磁盘与备磁盘位于不同的服务器(也就不可能在同一硬盘或SSD),当规划了机柜级安全时不会在同一个机柜。VBS通过DHT算法确定数据所在的主OSD,如果主OSD因故不能访问,再选择备OSD读取所需数据。


两副本时一个节点故障后的数据重建示意

由于数据的每一个副本都尽可能分布在不同节点乃至不同硬盘上,在进行数据修复时,会在不同的节点上同时启动数据重建,每个节点只需重建一小部分数据,多个节点并行工作,避免单个节点重建大量数据所产生的性能瓶颈,最小化对上层业务的影响。据称,FusionCube分布式存储恢复每TB数据,硬盘需要30分钟,SSD只需15分钟——在诸多现实条件的限制下,SSD有时不会比硬盘快太多。

类似于RAID 6和RAID 5的关系,三副本的可靠性比二副本更高,可以配置更大的故障域。华为出示的数据显示:2副本场景下,可靠性≤4个9;3副本场景下,可靠性≥7个9。数据可靠是第一位的,所以FusionCube分布式存储建议采用三副本,能够容忍同时2服务器故障乃至同时2机柜故障(前提是配置了多个机柜)。

更大的故障域意味着可以有更大的资源池。FusionCube分布式存储在二副本时,单个资源池的最大硬盘数为96个,三副本则可达2048个,比前者的20倍还多。


规模越大,对副本数的需求越高。据江湖传言,Gmail早期曾用过12副本来应对暴涨的访问压力。有时,性能和可靠性就是要靠钱堆出来……

当然,就像高水平的替补多了不都是好事,有可能引发不和谐(争抢上场机会),或者资源的浪费(花大钱买来上不了场),副本多了也有类似的问题。

一方面是写入性能。为了保证块存储的强一致性,主OSD接到写I/O请求后,同时以同步方式写入到本服务器的SSD cache和数据副本所在其他服务器的备OSD,都返回写成功才能向VBS交差。虽然备OSD也是将数据(副本)写入本服务器的SSD cache(异步刷入到硬盘)便向主OSD返回写I/O成功,但毕竟多一个备OSD(备1和备2)就要多等待一个网络传输。如果网络状况不佳(续上节),三副本的写入性能可能会比二副本低一些。


FusionCube分布式存储的读(左)写(右)I/O路径示意:从SSD缓存写入硬盘是异步操作,但之前的写入SSD缓存是同步操作,即要等待所有副本对应的OSD完成返回

另一方面是存储利用率。二副本的存储利用率是50%,三副本则只有33%,这在很大程度上抵消了Server SAN(因采用通用硬件)相对于传统SAN的成本优势。纠删码(Erasure Coding,EC)具有比RAID 6更好的容错性及相近的存储利用率,但会消耗更多的CPU和网络资源,目前看来更适合Ceph对象、Swift和Hadoop等对象存储类场景,而不是Server SAN。

比赛或许输得起,存储怎能丢数据?副本也好,备份也罢,不该省的坚决不能省。

教练的权威:管理一致性

有些C罗的球迷不能接受自己的偶像在决赛中早早离场,球队却能力克强敌的事实。于是,我罗在替补席前对队友指手画脚,“指挥球队”的表现,被部分媒体捧成了葡萄牙队获胜的关键。

葡萄牙的一位前辈评论道:如果你真的这样想,那么C罗在每一场比赛都该待在替补席。

无独有偶,勒布朗·詹姆斯因在骑士队“一言九鼎”的地位,而被戏称为身兼球员、教练、总经理三职。小皇帝一个人说了算的骑士队能打入总决赛,可要夺冠就差点儿意思。

转折点发生在今年1月,骑士队在主场狂输去年总决赛对手勇士队40分,主教练布拉特下课,助教泰伦·卢接过教鞭。

泰伦·卢作为主教练是个菜鸟,与小皇帝私交也不错。但他有一点做得比詹姆斯之前在骑士队的主教练们都好,就是敢于维护自己的权威,让詹姆斯听从指挥,做好自己分内的事。

詹姆斯之前在热火队两次夺冠,也得益于总经理足够强势,坚决维护主教练的权威。

从管理的角度,足球和篮球这样的集体项目,很像分布式系统,球员脑中存着日常训练形成和赛前准备安排的打法上场,在比赛中具有一定的自主权;球场上也可以有多位具有领袖气质的球员协商,统一全队思想。但是,平时如何训练,针对不同的对手采用什么样的打法,如何根据赛事的发展进行针对性的调整,必须有一个权威的声音裁夺。

有些天才球员由于所打的位置、对场上形势的洞察力和在队中的威望,被称为“场上的教练”。然而,若是场下的教练不行,也是白搭。

在体育运动日益职业化、市场化的今天,虽然足球和篮球教练的年薪往往没有队中的明星球员高,但是,不能服从他们指挥的球队,不会有很高的成就。

一个设计完善的分布式系统,其管理功能也应该是分布于多个节点上的,以避免单点故障(Single Point Of Failure,SPOF)。但是,分布式系统是在不断变化中的,而网络问题(网络多重要!)可能导致管理节点上储存的信息不一致,或者不能无限期的等待全部管理节点响应(或许有的已经挂掉了),怎么保证系统的一致性?

这就需要一个“民主选举”的机制来产生和变更集群的“领袖”。Paxos是获得业界广泛承认的分布式一致性算法,简单的说,就是所有管理节点参与投票,获得过半票数(N/2向前取整,N必须是奇数)的节点当选为集群的主管理节点,负责同步集群的管理信息。如果主管理节点失效(宕机或网络故障),失去与其他管理节点的联系,再重复选举,产生新的主管理节点。

Google开发的Chubby分布式锁服务被认为是Paxos的第一个大规模工程实现,Yahoo!借鉴Chubby的设计思想开发了ZooKeeper,并贡献为Hadoop的一个子项目。ZooKeeper在Chubby的基础上做了很多改进,而最关键的一点在于——它是开源的!因此,在各种分布式系统中都可以看到ZooKeeper的身影,可谓遍地开花。


FusionCube分布式存储逻辑架构

FusionCube分布式存储也采用了ZooKeeper(ZK),为MDC(MetaData Controller,元数据控制器)集群提供选主仲裁。一个系统需部署3、5、7等奇数个ZooKeeper组成ZooKeeper集群,从3个起步,系统部署后不能再增加数量,且必须保证大于总数一半的ZooKeeper处于活跃可访问。

MDC实现对分布式集群的状态控制,以及控制数据分布式规则、数据重建规则等。一个系统至少部署3个MDC,形成MDC集群。ZooKeeper和MDC都可以与VBS和OSD等组件部署于同一个物理节点上,所以FusionCube分布式存储的最小部署也是3个服务器(节点)。

系统启动时由ZooKeeper集群在多个MDC中选举主MDC,主MDC对其他MDC进行监控,主MDC故障时产生新的主MDC。每个资源池有一个归属MDC,当某池的归属MDC故障时,主MDC指定另外的MDC托管这个资源池,一个MDC最多管理两个资源池。

作为一个进程,MDC可以在每个存储节点启动,增加资源池会自动启动MDC,以维护资源池的分区和硬盘、服务器的映射关系,并推送到VBS和OSD——包括任何变化。一个系统最多启动96个MDC,最多支持128个资源池。

目前FusionCube分布式存储每个资源池最多可以有256个存储节点(3副本时可达2048个硬盘,合每节点8个硬盘),多资源池支持是其单集群最大存储节点数可达4096个的重要因素。

如果引用本站的原创文章,请注明原文链接:,本站保留追究责任的权利!

发表评论