云存储技术剖析文档格式.docx

云存储技术剖析文档格式.docx

《云存储技术剖析文档格式.docx》由会员分享，可在线阅读，更多相关《云存储技术剖析文档格式.docx（12页珍藏版）》请在冰豆网上搜索。

实用的云存储可以分作两类：

对象存储和块存储。

对象存储存储是地道的数据仓储，仅仅存放key/value数据：

用户有一个数据对象，需要存储起来，他就给这个对象起一个名字（key），然后将对象连同名字一起存放入对象存储。

当需要的时候，用这个名字作为key，向存储系统索要。

而对象存储系统必须在需要的时候将数据返还给用户，除非用户已将此数据从存储系统中删除。

块存储则是充当操作系统底下的块设备（笼统地说，就是磁盘），供系统使用。

块存储实际上就是一种SAN（StorageAttachNetwork），将集群的存储空间分配给用户，挂载到操作系统，作为磁盘使用。

因为块存储需要模拟磁盘的行为，因此必须确保低延迟。

尽管两种云存储有完全不同的目标、用途和特性，但在分布式存储基本特性方面都面临着相同的问题，这里的讨论对两者都有意义。

为了简便起见，这里只讨论对象存储的情况。

但很多内容和结论可以外推到块存储。

2.存储的基础

云存储功能非常简单，存储用户的数据而已。

但简单归简单，几个要点还是需要做的。

当用户将一个key-value对上传至存储时，存储系统必须找合适的服务器，保存数据。

通常会保存在多台服务器上，以防止数据丢失。

这叫多副本。

于是，一个关键的问题就是如何选择存放数据的服务器。

服务器的选择是很有技术含量的事，需要兼顾到几个要点：

首先，数据必须在服务器之间平衡。

不能把数据集中到少数几台服务器，造成一部分服务器撑死，而另一部分饿死。

其次，在用户读取数据时，可以方便快捷定位。

随后，满足云存储服务高可靠高可用大规模的特点。

最后，尽可能简单。

于是，对于每个对象，都有一个key到数据存储位置的映射:

key->

pos。

映射方式很多，最直接的，就是将每一个对象的key->

pos数据对保存下来。

这些数据通常被称为＂元数据＂。

但还有一些更巧妙的方式：

根据key的特征，将key空间划分成若干分组，并将这些分组对应到不同的存储节点上。

这种方式可以笼统地成为”Sharding"

。

如此，可以直接按照一个简单规则定位到服务器。

常用的分组方式之一是按key的区间划分，比如a开头的是一组，b开头的是一组等等。

而另一种更具＂现代感＂的分组方式，就是对key哈希后取模。

哈希方案实际上就是哈希表的自然延伸，将桶分布到多台服务器中。

这两大类映射方式实质上是在不同的粒度上进行映射。

＂元数据＂在对象粒度上，而sharding则是在一组对象的粒度。

这两种不同的粒度，决定了它们有着完全不同的特性。

也决定了它们在实际应用中的表现。

3.元数据和一致性哈希

于是，在云存储方案中产生了两大流派：

元数据模型和Sharding模型。

而Sharding模型中，一致性哈希最为流行。

一致性哈希本身很难直接用作实际使用，进而产生了很多衍生方案，其中包括著名的"

Dynamo"

这里用“一致性哈希方案”指代所有基于一致性哈希的设计。

元数据方案是对象级别的key->

pos映射，也就是一个会无休止增长的＂map＂。

每多一个对象，就会多一条元数据。

通常会将元数据保存在一组数据库中，方便检索和查询。

元数据方案没有什么特别的地方，其核心是元数据存储部分。

这部分设计的好坏，关系到系统整体的特性。

关于元数据存储的设计不是本文的重点，本文将集中探讨元数据方案和一致性哈希方案的比较。

标准的一致性哈希模型是对key进行哈希运算，然后投射到一个环形的数值空间上。

与此同时，对节点（存储服务器）进行编码，然后也做哈希运算，并投射到哈希环上。

理论上，只要哈希算法合适，节点可以均匀地分布在哈希环上。

节点根据自身在哈希环上的位置，占据一个哈希值区间，比如从本节点到下一个节点间的区间。

所有落入这个区间的key，都保存到该节点上。

在这个模型中，key到数据存储逻辑位置的映射不通过存储，而是通过算法直接得到。

但是，逻辑位置（哈希环上的位置）到物理位置（节点）的转换无法直接得到。

标准的做法是任选一个节点，然后顺序寻找目标节点，或者采用二分法在节点之间跳转查找。

这种查找方式在实际的存储系统中是无法忍受的。

所以，实用的存储系统往往采用的是一个混合模型（暂且称之为“混合方案”）：

系统维护一个哈希区间->

节点的映射表。

这个映射本质上也是一种元数据，但是它是大粒度的元数据，更像是一个路由表。

由于粒度大，变化很少，所以即便用文本文件都可以。

这个映射表也需要多份，通常可以存放在入口服务器上，也可以分散到所有的存储节点上，关键是保持一致即可，这相对容易。

一致性哈希解决了标准哈希表改变大小时需要重新计算，并且迁移所有数据的问题，只需迁移被新加节点占据的哈希区间所包含的数据。

但是，随着新节点的加入，数据量的分布会变得不均匀。

为了解决这个问题，包括Dynamo在内的诸多模型，都采用了＂虚拟结点＂的方案：

将一个节点分成若干虚拟节点。

当节点加入系统时，把虚拟节点分散到哈希环上，如此可以更加＂均匀地＂添加一个节点。

一致性哈希及其衍生方案，将数据按一定规则分片，按一定规则将分片后的数据映射到相应的存储服务器上。

因此，它只需要维护一个算法，或者一个简单的映射表，便可直接定位数据。

更加简单，并且由于少了查询元数据，性能上也更有优势。

但是，这只是理论上的。

如果我们只考虑存储的功能（get，put，delete），一致性哈希非常完美。

但实际情况是，真正主宰云存储架构的，是那些非功能性需求：

1、大规模和扩展性

2、可靠性和一致性

3、可用性和可管理

4、性能

在实际的云存储系统中，非功能需求反而主导了架构和设计。

并且对key-pos映射的选择起到决定性的作用。

4规模和扩展

首先，云存储最明显的特点是规模巨大。

对于一个公有云存储服务，容纳用户数据是没有限度的。

不可能以＂容量已满＂作为理由，拒绝用户存放数据。

因此，云存储是“规模无限”的。

意思就是说，云存储系统，必须保证任何时候都能够随意扩容，而不会影响服务。

另一方面，云存储作为服务，都是由小到大。

一开始便部署几千台服务器，几十P的容量，毫无意义。

资源会被闲置而造成浪费，对成本和现金流量产生很大的负面作用。

通常，我们只会部署一个小规模的系统，满足初始的容量需求。

然后，根据需求增长的情况，逐步扩容。

于是，云存储系统必须是高度可扩展的。

面对扩展，元数据方案没有什么困难。

当节点增加时，系统可以更多地将新来的写请求引导到新加入的节点。

合适的调度平衡策略可以确保系统平衡地使用各节点的存储空间。

但对于一致性哈希和它的衍生方案而言，却麻烦很多。

原始的哈希表一旦需要扩容，需要rehash。

在基于哈希的分布式存储系统中，这就意味着所有数据都必须重新迁移一遍。

这当然无法忍受的。

一致性哈希的出现，便可以解决此问题。

由于对象和服务器都映射到哈希环上，当新节点加入后，同样会映射到哈希环上。

原来的区段会被新节点截断，新加入的节点，会占据被切割出来的哈希值区间。

为了完成这个转换，这部分数据需要迁移到新服务器上。

相比原始的哈希，一致性哈希只需要传输被新服务器抢走的那部分数据。

但是终究需要进行数据迁移。

数据迁移并非像看上去那样，仅仅是从一台服务器向另一台服务器复制数据。

云存储是一个在线系统，数据迁移不能影响系统的服务。

但迁移数据需要时间，为了确保数据访问的延续性，在迁移开始时，写入操作被引导到目标服务器，而源节点的待迁移部分切换至只读状态。

与此同时，开始从源节点迁移数据。

当用户试图读取迁移范围内的数据时，需要尝试在源和目标节点分别读取。

这种单写双读的模式可以保证服务不受影响。

但是，必须控制数据迁移的速率。

如果迁移操作将磁盘吞吐能力跑满，或者网络带宽耗尽，服务必然受到影响。

另一个问题是，除非成倍地增加节点，否则会存在数据不平衡的问题。

为了平衡数据，需要迁移更多的数据，每台节点都需要迁出一些，以确保每个节点的数据量都差不多。

虚拟节点的引入便是起到这个作用。

于是实际的数据迁移量同增加的容量数成正比，系数是当前存储系统的空间使用率。

于是，一个1P的系统，三副本，70%的消耗，扩容200T，那么需要迁移大约140T*3=420T的数据，才能使数据存储量得到平衡。

如果使用现在常用的存储服务器（2T*12），需要新增21台。

如果它们都并发起来参与迁移，单台迁移速率不超过50MBps，那么这次扩容所需的时间为420T/（50M*21）=400000秒，大约4.6天。

这是理想状况，包括软硬件异常，用户访问压力，迁移后的检验等情况，都会延长迁移时间。

很可能十天半月泡在这些任务上。

而在数据迁移完成，老服务器的存储空间回收出来之前，实际上并未扩容。

那么万一扩容实在系统空间即将耗尽时进行，（别说这事不会碰到，一个懒散的供货商，或者厂家被水淹，都可能让这种事情发生。

云计算什么事都会遇到），那么很可能会因为来不及完成扩容而使系统停服。

云存储，特别是公有云存储，扩容必须是快速而便捷的。

更复杂的情况是迁移过程中出错，硬件失效等异常情况的处理过程会很复杂，因为此时数据分布处于一种中间状态，后续处理必须确保系统数据安全一致。

系统的扩容规模越大，困难程度越大。

当系统有100P的规模（很多系统宣称可以达到的规模），而用户数据增长迅猛（公有云存储有明显的马太效应，规模越大，增长越快），在几百上千台服务器之间迁移成P的数据，是多么骇人的场景。

数据迁移会消耗网络带宽，吃掉磁盘负载，搅乱服务器的cache等等，都是云存储的大忌，能不做尽量不做。

元数据方案一般情况下不需要做迁移。

迁移只有存储服务器新旧更替，或者租借的服务器到期归还时进行。

由于数据对象可以放置在任何节点上，因而可以把一台节点需要迁移的数据分散到其他节点上。

并且可以从其他副本那里多对多并发地传输数据。

负载被分散到整个集群，对服务的影响更小，也更快捷。

实际上，这个逻辑和数据副本修复是一样的。

很显然，相比一致性哈希方案动不动来回迁移数据的做法，元数据方案提供一个动态平衡的机制，可以无需数据迁移，服务器一旦加入集群，可以立刻生效，实现平静地扩容。

5可靠性和一致性

可靠性（本文特指数据的可靠性，即不丢失数据）无疑是云存储的根本。

用户将数据托付给你，自然不希望随随便便地丢失。

维持可靠性是云存储最困难的部分。

（当然，更难的是在保持高可靠性的前提下确保高可用）。

在任何一个系统中，硬件和软件都无法保障完全可靠。

芯片会被烧毁，电路可能短路，电压可能波动，老鼠可能咬断网线，供电可能中断，软件会有bug，甚至宇宙射线会干扰寄存器…。

作为存储的核心部件，硬盘反而更加脆弱。

在标准的服务器中，除了光驱和风扇以外，硬盘是唯一的机电元件。

由于存在活动部件，其可靠性不如固态电路，更容易受到外界的干扰。

所以，硬盘时常被看作消耗品。

在一个有几万块硬盘的存储集群中，每周坏上几块硬盘是再寻常不过的事。

运气不好的时候，一天中都可能坏上2、3块。

因此，只把数据保存在一块盘中是无法保障数据可靠的。

通常我们都会将数据在不同的服务器上保存多份，称之为“副本”。

原则上，副本越多，越可靠。

但是，过多的副