篮足启示：SDS之Server如何SAN(上)

作者注：Server SAN是软件定义存储的一个分支，也是超融合架构的基石。2016年夏天，我以足球和篮球作比，由整体到局部探讨Server SAN的六大方面：规模、架构、SSD、网络、副本、管理……眼下，恰逢欧洲杯和NBA再次合体，LBJ虽已被淘汰，C罗仍保有卫冕希望，将此文翻出，别有一番风味。如5年前题材，分三期连载，以下为第一部分，最初发表于2016年9月12日

系列回顾之首篇：究竟什么是超融合？

系列回顾之二篇：如何“超”融合：超融合架构是与非

刚刚过去的这个夏天，足球界和篮球界的最大赢家，分别是人称“霸道总裁”的皇马及葡萄牙国家队球员Cristiano Ronaldo（克里斯蒂亚诺·罗纳尔多，C罗），和NBA骑士队身兼球员、教练、总经理三职的LeBron James（勒布朗·詹姆斯，LBJ）。

6月14日，NBA总决赛第5场，3比1手握赛点的勇士队，全能内线格林停赛。
7月11日，欧洲杯决赛，半场刚过一半，面对星光更密的法国队，葡萄牙头号球星C罗因伤下场。
当骑士队头号球星詹姆斯一次次冲击少了格林的内线时，勇士球迷的内心是崩溃的。
当法国队中场西索科一次次带球冲向葡萄牙队的禁区，支持法国队的老司机却感觉形势不妙。
格林在勇士队的排位也就在二三名之间，但他缺阵这一场，被公认为骑士能够逆转夺冠的关键。
C罗在葡萄牙队说一不二，但他因伤下场后，葡萄牙队越踢越好，在加时赛打入全场唯一进球，逆袭夺冠。
大约十年前，阿迪达斯先后放出这两个团队项目的广告：

• 何塞+10（Jose+10）迎接2006世界杯；
• 篮球是5个人的（IT takes 5）开启NBA新赛季。

足球11人，篮球5人，这不是常识吗？当然，常识里面有知识。

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

规模决定规律：软件定义存储兴起

不算守门员的话，足球的场上人数也比篮球多一倍，但大得更多的是场地：

• 常见的标准田径场内嵌足球场地长105米，宽68米；
• 是国际篮联标准场地（28×15）的17倍；
• 换成NBA的场地（28.65×15.24），也在16倍以上；
• 以人均活动面积计，足球约8倍于篮球。

更直观一点：整个篮球场的面积，还没有每位守门员辖区（禁区，40.32×16.5）的三分之二大，却要塞下10名运动员。

规模导致规律不同：规模越小，单干越无解；规模越大，单干越无效。

活动范围或守护区域不够大的时候，（单个）球员的身高臂长很重要，譬如篮球运动员的身高明显超过足球运动员，而守门员的身高又明显超过其他位置的球员。

传统企业中的应用种类比较多，但每个应用的规模通常不会很大，可以多个应用共享一个外置磁盘阵列，即SAN（Storage Area Network，存储区域网）存储设备。按照配置和价格区间的不同，SAN存储分为高、中、低端，目前最大的高端存储系统是EMC的VMAX 400K，支持多达5760个2.5英寸驱动器，或2880个3.5英寸驱动器。

VMAX 400K配满DAE（磁盘扩展柜）的示意图

互联网企业的特点是单一应用的规模大、用户数量多，譬如一个Hadoop集群可以有上万台服务器。即使以一个集群5000台服务器、每台服务器12个硬盘计，驱动器总数也能达到6万个，已经比VMAX 400K的10倍还多，是任何单一存储系统无法达到的规模。

受到Google公布的GFS（Google File System，2003年10月）和MapReduce（2004年12月）两大论文的启发，Hadoop项目创建于2006年1月（又是2006！比本文开头提到的两个广告略早），5月在Yahoo!部署了300台机器的集群，10月就达到600台的规模。

Hadoop架构示意图

MapReduce、GFS及其“模仿者”HDFS（Hadoop Distributed File System，Hadoop分布式文件系统）不能直接照搬到传统的企业应用场景中，但其在以下几个方面的实践，得到了借鉴：

1. 集群中高度并行、分布式的算法；
2. 基于工业标准硬件（x86服务器）的分布式软件定义存储；
3. 计算与存储融合（即超融合）的思路和框架。

所以，软件定义存储的兴起，和以集成、简化为主要诉求的超融合架构，都是起源于互联网的技术带动传统IT架构变革的体现。

从GFS和HDFS来看，软件定义存储（Software Defined Storage，SDS）属于实践先行，配套的理论还没完全跟上，而可以涵盖的范围之广亦让我们很难给出一个简短且明晰的定义。较强的市场语言色彩是“软件定义存储”这个概念经常为人诟病之处，却也是其接受程度比之前的“存储虚拟化”（storage virtualization）高得多的原因之一。

部分套用SDN（Software Defined Networking，软件定义网络）的理念，SDS可以分为侧重于控制平面（Control Plane）与数据平面（Data Plane）的两大流派：前者着眼于控制平面与数据平面的分离，以实现不同类型存储的自动化管理；后者通过将存储功能的实现与特定硬件解耦，用软件抽象大量COTS（commercial off-the-shelf，商用成品）硬件资源，作为统一的存储池提供，主要表现为基于x86服务器的分布式存储，典型如本文要剖析的所谓Server SAN。

VMware对软件定义存储的Control Plane和Data Plane划分

“数据平面派”很大程度上颠覆了传统的存储行业，近期活跃度明显更高，华为FusionCube分布式存储软件（FusionCube的核心组件，即上篇提到的FusionStorage）、VMware的vSAN、开源软件Ceph以及大量存储初创公司推出的SDS产品都属于这一领域。

传统企业对规模的要求无法与Google、Facebook、BAT等互联网巨头相比，但SDS仍体现出明显优于传统SAN的扩展潜力，以华为FusionCube分布式存储软件为例：

单集群最大存储节点数4096个，单集群硬盘数量49152个——在这种情况下，平均每个节点12个硬盘，正好是一台2U存储服务器（前面板）所能容纳的3.5英寸硬盘的数量。

FusionCube分布式存储支持多种扩展方式

很显然，分布式存储拼的不是单个设备的纵向扩展（Scale-up）能力，而是靠多个设备组成集群的横向扩展（Scale-out）能力，以量取胜。

因为规模越大，单个设备的能力就越“显得”微不足道——但不代表不重要，我们不能从一个极端走向另一个极端。

巨星与团队：纵向扩展到横向扩展

绰号“小皇帝”的勒布朗·詹姆斯与其他超级巨星最大的区别就是“自带体系”，围绕他配备一群功能单一（抢篮板，或者投三分）的角色球员，就可以在总体偏弱的NBA东部联盟脱颖而出，连续闯入总决赛。
全队命脉系于吾皇一身时，有两大不良后果：

• 上限不高，如14年在热火韦德退化、15年在骑士欧文缺阵，面对多点开花的西部球队，最终都败下阵来；
• 下限很低，LBJ先后于10年离开骑士、14年离开热火，两支球队立刻连季后赛都进不去……

规模更大的足球则更依靠整体的力量，梅西和一众球星组成的阿根廷队连续两年决赛不敌星味平平的智利，葡萄牙伤了C罗却能登顶欧洲。
给詹姆斯配个得力的副手，便能击败整体组织更好的对手夺冠，而在顶级足球赛事中，情况则几乎完全相反——仅靠两三名超级球星走不了太远，团结一致的平民球队笑到最后的场景倒是隔不几年就能一见——最近的例子是上赛季英超冠军莱斯特城。

虽说足球和篮球都是集体运动，但……

• 足球更强调整体协作，就像Scale-out；
• 篮球更突出巨星领军，就像Scale-up。

归根结底还是规模导致发展方向不同。

传统SAN存储设备走的是纵向扩展路线，即所谓的Scale-up，其主要特征是由一套控制器带一组JBOD。存储控制器（Storage Controller，俗称“机头”）具有运算能力和存储操作系统等软件（智能），处理所有的I/O请求；JBOD则是大量磁盘的简单聚合（Just a Bunch Of Disks，俗称“傻盘柜”），在控制器的调度下存储或读取数据。控制器和JBOD的关系，有点儿像负责处理球权的LBJ和功能单一的角色球员们。

中端存储系统的双控制器架构：（蓝色椭圆框中的）控制器上接服务器（主机），下接磁盘（扩展），作为数据流的必经之路，很容易成为瓶颈

存储控制器介于服务器和存储资源之间：前端（FE）端口连接主机（服务器），后端（BE）端口连接JBOD。这种架构存在两大问题：

1 可用性。存储控制器一旦失效，JBOD等存储资源就不可访问，所以一定要保证存储控制器的高可用（High Availability，HA），这就又分成两大类：

1.1 高端存储系统使用复杂的单片式（Monolithic）架构，典型如EMC的Symmetrix DMX家族；
1.2 中低端存储系统使用双控制器（双控）架构，甚至IBM的DS8000系列高端存储也可以归入此类。

2 可扩展性。存储控制器作为数据必经之路，成为瓶颈是无法避免的宿命。

后一点充分体现了纵向扩展模式的局限性。不论是单片式控制器，还是一对控制器（双控），其计算资源和I/O资源（前后端端口）的增加都是有限度的，能连接的存储容量、输出的访问性能和服务的主机数量，自然也突破不了相应的限制。

EMC中端存储系统VNX系列的硬件配置：上面红色方框内不同型号的能力（支持驱动器数量和Cache容量），与下面红色方框中的控制器配置（CPU型号、内存容量、后端SAS端口数量）直接相关

事实上，存储系统不仅分为高中低端，同一个系列里还有由高到低的不同型号，最根本的区别就是存储控制器的配置不同。当存储系统的性能不够满足需求时，升级到同产品系列的更高型号还可以只更换控制器（需要停机），更换到其他存储系统便难以避免迁移数据等工作了，面临所谓的“叉车式升级”（forklift upgrade）。

高端存储系统控制器的单片式架构和集群架构

一个折中的选择是增加存储控制器的数量，控制器之间采用高速互连技术组成集群，即横向扩展（Scale-out），也称“向外扩展”。EMC用来接替DMX家族的VMAX家族，就采取了Scale-out + Scale-up的方案：

• 一对控制器构成引擎，引擎之间横向扩展，最多可以增加到8个；
• 每个引擎带多个JBOD（VMAX3可达6个）继续纵向扩展，横向扩展与纵向扩展相结合。

采用横向扩展的方式，多个引擎之间，更像足球场上的队友，彼此分担工作，覆盖更大的区域。但是，这种10个左右的集群规模，主要还是依靠纵向扩展能力，纯论横向扩展，必须服Server SAN。

类似于“软件定义存储”，Server SAN也是一个市场色彩较浓的名词，但可以用来指代软件定义存储或分布式存储中的一种特定类型。顾名思义，Server SAN是用服务器来实现（传统）SAN的功能，而SAN的本质是块存储。

所以，严格来讲，Server SAN指的是分布式块存储，应该提供SCSI或iSCSI等标准的块访问接口，例如开源的Ceph（块场景）和商业化的华为FusionCube分布式（块）存储软件。

从这个角度而言，VMware的vSAN倒真的是“Virtual SAN”，但不排除未来会有所变化。

纵向扩展存储像左侧的瓶子，长于“储存”，输出时有瓶颈（适合单人使用）；
横向扩展存储像右侧的杯子，主要就是为输出设计，单个容量不大但容易“并发”……

传统SAN的纵向扩展架构中，集中式控制器相当于一台具有很强I/O处理能力的服务器，如果成为系统的瓶颈，解决方法是换一台性能更强的……而Server SAN采用横向扩展架构，单个服务器节点论Scale-up比不了高端SAN的控制器，所以采用加入更多节点（Scale-out）分担压力的做法，来达到更大的规模。

这就意味着，要把访问请求尽量平均分配到多个节点上并行处理，避免让某一个节点成为访问的“热点”——如果整个集群的性能会受限于单个或某几个节点的处理能力，扩展的潜力也不可能很大。

因而，不仅数据要尽可能平均的分布在不同的节点里，也不能有一或几个节点专门用来保存元数据。元数据（metadata）记录不同数据的位置信息，每次I/O操作都需要查询元数据服务。随着系统规模的增长，元数据的容量也会越来越大，系统所能提供的并发操作能力将受限于元数据服务所在服务器的能力。换言之，集中式的元数据管理也是不可以的！

分布式哈希表（Distribute Hash Table，DHT）是业界广泛认可的一种，可以平均分布数据并避免集中式元数据管理的路由数据算法。以FusionCube分布式存储为例，采用Key-Value（键-值，“简直”，简称KV）的方式存储数据，DHT路由算法由VBS（Virtual Block Storage，虚拟块存储）和OSD（Object Storage Device，对象存储设备）共同完成：

• VBS通过计算确定数据存放在哪个服务器（节点）的哪块硬盘上。每个节点上默认部署一个VBS进程，管理卷的元数据，多个节点上的VBS组成集群，通过SCSI或iSCSI接口（为计算资源）提供分布式存储接入点服务。VBS与其所能访问的资源池的所有OSD点对点通信，使VBS能并发访问这些资源池的所有硬盘。
• OSD通过计算确定数据存放在硬盘上的具体位置。每个硬盘默认分配一个进程，每个节点会有多个硬盘，也就运行着多个OSD进程。OSD进程在系统初始化时对硬盘进行分片管理，并在硬盘的元数据管理区域记录每个分片的分配信息。

VBS提供访问入口，OSD实现存储功能

既然元数据管理的任务被下放到每个节点（默认一个VBS和/或多个OSD进程），元数据服务也就不会成为FusionCube分布式存储系统的性能瓶颈。

逻辑卷和硬盘的分片单位都是1MB，一个资源池的地址不超过2的32次方的哈希空间。应用对FusionCube分布式存储的访问请求经操作系统转发到本节点的VBS模块（单个节点上也可以通过部署多个VBS来提升I/O性能），VBS将其中的地址信息（LUN ID和LBA ID，后者对1MB取整）组成1个Key，通过哈希计算出一个整数，确定具体硬盘，再把I/O操作转发到该硬盘所属的OSD模块。OSD根据Key查找数据在硬盘上对应的分片信息，进行I/O操作后返回（数据或写入完成）给VBS。

2的32次方是hash（哈希）计算出整数的范围，逻辑卷被切分成很多1MB数据块，多个1MB块的地址信息Key（LUN ID+对1MB取整的LBA ID），经过hash计算后可能会得到同一个整数，这样就会被路由到同一个OSD节点，OSD会根据地址信息Key进行硬盘上的位置映射。所以，Hash计算的整数范围是2的32次方，而数据和地址信息Key可以是无穷大，支持的硬盘数量也可以无穷大。华为从可靠性的角度考虑，把故障域限制为每个资源池2048个硬盘，整个集群可以达到49152个硬盘。

FusionCube分布式存储与资源池相关的一些指标如下表：

简单哈希算法的一个问题是不能保证数据分布的均衡性，可能会导致有些硬盘存储的数据过多，从而成为性能和扩展的瓶颈。

为了叙述方便，上面没有提到的一点是，FusionCube分布式存储采用的DHT算法，在硬盘和（1MB）切片之间，还引入了分区（Partition）的概念：

系统初始化时，将（资源池对应的）哈希空间划分为N等份，每1等份是1个分区（Partition），这N等份按照硬盘数量进行均分（如每个硬盘100个分区）。FusionCube分布式存储系统的“分区-硬盘”映射关系所需空间很小，从而可以在每个节点的内存中保存该映射表，用于进行快速路由，并会随着系统中硬盘数量的变化进行调整。

所以，前面描述中提到哈希计算出的整数，首先落在指定的分区中，再根据内存中记录的“分区-硬盘”映射关系确定具体硬盘。

相应地，FusionCube分布式存储要求同一资源池中提供存储服务的服务器配备的数据盘类型、规格和数量最好相同，或者不要超过一定范围。软件和硬件互相配合，可以使得所有节点负载均衡，保证性能充分发挥。

分布式存储的集群规模，很大程度上取决于存储服务在各个节点间分配的平均程度。“热点”是任何类型的存储都应该极力避免的现象。

（未完待续……）