云存储技术剖析文档格式.docx
- 文档编号:15768675
- 上传时间:2022-11-16
- 格式:DOCX
- 页数:12
- 大小:28.84KB
云存储技术剖析文档格式.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块。
因此,只把数据保存在一块盘中是无法保障数据可靠的。
通常我们都会将数据在不同的服务器上保存多份,称之为“副本”。
原则上,副本越多,越可靠。
但是,过多的副
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 存储 技术 剖析