作者注：Server SAN是软件定义存储的一个分支，也是超融合架构的基石。2016年夏天，我以足球和篮球作比，由整体到局部探讨Server SAN的六个方面：规模、架构（两大）、SSD、网络、副本、管理（四小）……今夏，NBA与欧洲杯、美洲杯合体，LBJ和C罗先后被淘汰，意大利和梅西的阿根廷在24小时内相继捧杯……将此文翻出，仍别有一番风味。如5年前题材，分三期连载，以下为第三部分，最初发表于2016年9月20日
上部回顾：Server SAN之规模与架构
中部回顾：Server SAN之SSD与网络
轮换与替补：副本保冗余
一向以阵容厚度而为人称道的勇士队，在今年西决和总决赛期间突然发现，在强悍的对手面前，小前锋哈里森·巴恩斯成为薄弱环节。特别是在进攻中，巴恩斯不能稳定的把球投中，导致雷霆队和骑士队都可以把他放空，形成五防四的局面。
等到总决赛第五场，中锋安德鲁·博格特受伤，由于找不到合格的替补，这一问题就更加严重。结果勇士队连败三场，成为首支总决赛中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开始，软件定义存储（Software Defined Storage，SDS）普遍采用三副本的方式提供数据冗余，还可以获得较好的读操作性能，这对（面向块存储应用场景的）Server SAN尤为重要。
FusionCube分布式存储提供二副本或三副本的机制来保证数据的可靠性，即同一份数据可以复制保存为2~3个副本。数据的副本数设置决定了资源池初始化时的数据分布，分区的主磁盘与备磁盘位于不同的服务器（也就不可能在同一硬盘或SSD），当规划了机柜级安全时不会在同一个机柜。VBS通过DHT算法确定数据所在的主OSD（Object Storage Device，对象存储设备），如果主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个的重要因素。
（全文完）
