5.2 分布式块存储功能和特点
5.2.1 分布式块存储的大规模scale-out、线性扩展
采用基于通用x86服务器的分布式存储，其主要的优势之一就是可以通过分布式软件来达到比较好的线性scale-out扩展能力。大规模线性扩展也是分布式块存储系统首先要解决的关键技术之一。
总体而言，现在scale-out的分布式存储技术可以大体上分为两大类：一类是将数据分片，通过元数据方式记录不同分片的位置，来达到横向扩展；另一类是将数据分片，通过类似DHT的算法来计算出数据分片的位置，从而达到线性扩展。这两种技术，不同的厂家有不同的实现，有些厂家的产品是这两种技术的结合。
5.2.1.1 通过元数据方式实现横向扩展
通过元数据记录方式实现横向扩展的，如Google GFS和开源HDFS这类分布式存储系统，将数据切成较大的分片，这样数据分片对应的元数据占用较少，可以缓存在集中的某个或某几个元数据节点的内存中，实现数据的快速查找和定位访问。
这类技术用在分布式文件系统和对象存储等要求大块吞吐的场景下比较合适，但是用在分布式块存储系统中，会存在一定的问题：一个是数据切片过大（如HDFS默认的64MB），如果上层的块存储应用在这个64MB内形成了随机I/O热点，那么性能就会比较差，因为这些随机I/O在底层全部落到了某个硬盘上；另一个是如果将数据切片变小，则元数据就无法放入内存中，每次I/O访问的时候都要进行元数据查找，这个对块存储I/O的时延影响极大，虽然可以通过在应用侧缓存元数据的访问来避免每次跨网络的访问开销，但是仍然是无法满足块存储I/O对时延苛刻的要求。所以这种技术架构的系统一般主要用于大块I/O的场景会比较合适。
5.2.1.2 通过DHT等Hash方式实现横向扩展
通过DHT等Hash方式实现横向扩展，如华为的FusionStorage和开源的Ceph，将数据切片成较小的分片，通过数据地址计算Hash key，映射到存储节点硬盘上，实现数据的快速路由和访问。
DHT等Hash算法实现的分布式系统，具有以下特点。
● 自动负载均衡：数据能够尽可能均衡分布到所有的存储节点中，这样可以使得每个节点负载均衡，不会出现系统热点和瓶颈；当有新节点加入系统中时，系统自动完成数据均衡，将新节点的空间和性能都均衡利用起来。
● 时延低性能好：通过特定的Hash算法，将数据分片编址，通过一定的规则计算出各数据片的位置，从而避免元数据的查找，可以降低I/O时延，加快读写访问的速度。
● 线性扩展能力强：系统不会随着总容量的变大而变慢，不管系统总容量变得多大，Hash计算和路由的数据都不会增大，所以可以做到大规模的容量和性能的线性扩展。
业界采用Hash相关算法进行数据分片寻址产品和开源也比较多，比如Ceph RADOS、Sheepdog等。
5.2.2 分布式块存储的性能和时延
衡量一个分布式块存储系统整体性能和时延的要素，可以分解为如下几个方面。
● Roud delay：网络上消息往返次数，即应用层的一次读或写请求，需要底层分布式存储多少次的网络消息往返才能完成。每次跨网络消息交互都会增加响应时延，降低性能，所以对于分布式存储系统而言，越少的网络消息往返，就意味着越好的时延表现。
● Messages：网络上消息的总数，即应用层的一次读或写请求，总共需要分布式存储层多少条消息交互才可以完成。这个计算的是消息总条数，和roud delay的消息往返次数有区别。每种网络都有一定的pps，如果上层的一个读写请求，消耗越多的网络pps，也就意味着整个系统最终可以达到的IOPS越少。
● Disk reads：读磁盘次数，即应用层的一次读或写请求，需要读多少次磁盘I/O才能完成。应用层的一次读写请求，消耗越多的磁盘读，也就意味着整个系统的IOPS越低。
● Disk writes：写硬盘次数，即应用层的一次读或写请求，需要写多少次磁盘I/O才能完成。应用层的一次读写请求，消耗越多的磁盘写，也就意味着整个系统的IOPS越低。
● NVM reads：NVM cache介质读的次数，即应用层的一次读或写请求，需要读多少次NVM Cache介质才能完成。此处的NVM cache介质并不特指SSD cache、NVDIMM cache或DRAM。应用层的一次读写请求，消耗越多的NVM cache介质读，也就意味着整个系统的IOPS越低。
● NVM writes：NVM cache介质写的次数，即应用层的一次读或写请求，需要写多少次NVM Cache介质I/O才能完成。应用层的一次读写请求，消耗越多的NVM cache介质写，也就意味着整个系统的IOPS越低。
● Network b/w：网络带宽消耗，即应用层的一次读或写请求（如4K，8K等），需要消耗掉多少网络带宽。消耗带宽越多，意味着整个系统的MBPS越低。
上述7点，基本上可以决定一个分布式存储系统的性能和时延到底可以达到什么程度，表5-1以Amazon Dynamo和Zookeeper作为例子，分别给出上面7点涉及的内容。
表5-1 分布式存储系统的性能和时延分析表
5.2.3 分布式块存储的数据冗余保护和可靠性策略
分布式块存储系统一般都会采用多副本的方式进行数据冗余保护，也有些少量系统会尝试采用跨网络的Erasure Code进行数据冗余保护。多个副本之间需要保证数据的强一致性。当应用程序成功写入一份数据时，后端的几个数据副本必然是一致的，当应用程序再次读时，无论在哪个副本上读取，都是之前写入的数据，这种方式也是分布式块存储系统必须做到的。业界也有很多采用最终一致性的分布式集群技术，如Amazon Dynamo介绍的NRW机制（N表示存储的副本数、W表示返回写成功必须写入的副本数、R表示返回读成功必须读取成功的副本数），在R+W≤N的时候，这类分布式数据一致性集群技术无法满足数据库、VM/VDI等场景的要求。
分布式块存储需要考虑硬盘故障、服务器故障和机柜故障，特别是在大规模数据中心中（如公有云），机柜级的故障比较常见。在柜级电源故障、柜级交换机故障时都会导致整个机柜，甚至几个机柜的服务器无法访问，分布式块存储系统需要能够容忍这样的故障，保证数据不丢失，仍然可访问。
分布式存储的数据重建速度要求很高，数据被切片，多个副本被分散到不同的存储服务器上，当发生某台服务器故障的时候，往往意味着很多的磁盘不可访问，在没有人工参与更换的时候，系统需要自动把这台服务器的故障数据快速重建在其他服务器上，保证系统的副本数足够，防止发生双点故障。这就要求分布式块存储系统的重建不能像传统的多盘RAID组一样缓慢，需要把数据分散重建到除故障服务器外的尽可能多的不同的服务器上，通过多服务器并发重建来加快速度。
分布式存储也需要处理硬盘坏扇区的数据修复，比如多个副本上某个副本的扇区出现故障，但是硬盘是好的，此时如果正好读到这个扇区的数据，需要能够从其他副本把好的数据读过来修复这些故障扇区。
5.2.4 分布式块存储的高级功能
分布式块存储，和SAN一样，也需要提供常用的高级存储功能，比如快照、瘦分配、链接克隆、SSD Cache或分级等，这些都是在虚拟化、云平台场景下比较常用的功能。
分布式块存储系统的快照，首先要解决的就是数据分散在如此大规模的集群中需要一起打快照点，而且性能也不能随着快照点的增多而下降。一般而言，采用元数据索引方式的分布式存储，做快照的时候会在元数据上打快照点，如GFS；采用Hash等方式的分布式存储，一般会在各存储节点的数据层上打快照点，如华为的FusionStorage。不管哪一种方式，都需要解决秒级快照和同时打快照的问题。秒级快照，就是打快照的时候速度快，不会发生真正的数据拷贝，有些系统仅拷贝一份元数据就可以实现，有些系统仅作一个快照标记就可以完成。打快照就是在分布式块存储的各节点上同时打快照，保证快照时的数据一致性，相比SAN在控制器中打快照会复杂些，特别是在没有元数据的分布式存储架构中，需要考虑采用什么样的机制才可以做到多个节点上快照的一致性。
分布式块存储的链接克隆，和快照是一个原理，一般都是基于快照来实现。一个母卷，克隆出多个链接克隆卷，刚创建出来的链接克隆卷和母卷数据内容一致，但是数据只有一份，后续针对克隆卷的修改不会影响原始的快照和其他克隆卷。分布式存储系统通过支持批量进行虚拟机卷部署，可以在秒级批量创建上百个虚拟机卷。克隆卷继承普通卷所有功能：克隆卷可支持创建快照，从快照恢复以及再次作为母卷进行克隆操作。
分布式块存储系统的瘦分配，和SAN一样是为了在多租户和多应用之间按需弹性共享存储空间，从而提高存储系统的空间利用率。一般分布式存储系统在存储节点上都会有针对硬盘空间管理的文件系统或者K-V DB，上层应用的卷的有效数据分散到各个存储节点的时候，会被这些文件系统或K-V DB进行索引管理和空间块分配，当卷被删除的时候，这些索引和空间块又会被删除，以便给其他卷使用。对于应用的卷，没有写入数据的LBA在底层存储节点是不会被分配空间的。
5.2.5 分布式块存储的跨数据中心容灾
分布式块存储的跨数据中心容灾，和SAN的一样，包括同步、异步、双活，满足不同的容灾需求。有些分布式存储会将数据的多个副本同步、异步地放置到多个数据中心来实现容灾，如LinkedIn的voldemort，它将数据的3个副本放置在2个数据中心，在1个数据中心同步放置2个副本，在另一个数据中心异步放置1个副本。采用这种方式一般要求分布式集群中各节点之间不能有强同步的状态和控制信息，局域网环境和跨数据中心的专网环境对集群设计的约束是不一样的。
有些分布式存储通过在每个数据中心部署一套系统，在这两套系统之间做同步、异步、双活的数据容灾关系，每一套系统内仍然采用多个副本的冗余方式；或者将整个集群划分成多个不同的资源池，不同的资源池部署在不同的数据中心，跨资源池做数据的同步、异步、双活的保护，每个资源池内仍然采用多个副本的冗余方式。
如果分布式存储底层实现的是Erasure Code的数据冗余保护，那么在做跨数据中心容灾的时候，一般不建议将Erasure Code条带像副本一样分布在不同的数据中心，可以采用两个资源池或者两套系统分布在不同的数据中心，在每一个资源池或每套系统中采用Erasure Code的冗余保护。
5.2.6 分布式存储的硬件和软件兼容性
分布式块存储系统基于通用的x86服务器硬件，很多客户会要求可以采购不同厂家的服务器产品，这样就要求上层的分布式块存储软件具备很好的硬件兼容性，可以运行在主流的x86服务器上，如DELL、IBM、HP、华为等。
不同厂家的硬件，可能采用不同的RAID卡、不同的SSD卡、不同SSD盘和HDD盘，有些会上报不同的错误码，上层的分布式块存储软件需要能够以相对通用的机制来处理这些错误码，甚至采用插件机制来针对一些特殊硬件的错误码进行插件化处理，才能降低硬盘的AFR（Annualized Failure Rate，年故障率），从而保证存储系统的可靠性。