前言
UCloud在2020年8月正式发布了基于US3的全新一代归档存储产品,该产品采用UCloud全新自研存储架构,相较标准存储降低近80%存储成本的同时,与市场同类归档存储产品相比降低近30%的价格。
据IDC的预测,全球年新增数据量到2025年将达175ZB,真正能存储下来的数据仅有15ZB左右,流失率超过91%。在目前企业数据的冰山模型里,80%的数据量来源于冷数据。在公有云领域,UCloud认为容量型存储通过技术手段提升发展的空间还十分巨大。
如何最大化利用最新的高容量硬件来进一步降低存储成本?如何在归档存储长期保存的场景下充分保障用户的数据安全?这些都需要对US3归档存储的整个IO路径做较大的优化以及硬件适配工作,同时我们还需要保障产品的易用性,避免给用户带来额外的使用成本。
接下来本文将从UCloud如何利用硬盘技术提升存储密度以及优化IO调度来降低运营成本这两个角度,详细解析US3归档存储的底层存储引擎的软件以及硬件选型优化细节。
采用SMR盘+JBOD设备提高存储密度
降低硬件层面的成本,主要体现在提高存储密度上。这里我们探索过包括蓝光,磁带、硬盘等不同的存储介质,也有参考过微软的Pelican系统的硬件设计。考虑到我们最终实现的目标是期望用户可以在紧急情况下分钟内实现数据的激活与读取,正常情况下可以在小时内完成激活与读取,对于用户的最短保存时间不需要以年来计算。因此,UCloud结合自身的存储技术优势,暂时排除了蓝光以及磁带的存储介质实现,主要采用高密度硬盘的方式来实现归档型的云存储服务。
这里先介绍一下传统硬盘是怎么记录数据的。
这种传统的硬盘一般来说是属于垂直磁记录PMR类型的硬盘。数据通过写入彼此平行而不重叠的磁道来记录数据,提升数据存储容量只能通过提升磁道数量来提升。
相较于这种传统的硬盘还有一种基于叠瓦磁记录SMR的磁存储数据记录技术的硬盘可以提升存储密度以及整体硬盘的存储容量。这里介绍SMR硬盘的硬件实现之前还需要先了解一个背景知识,首先我们将磁盘的磁头放大来看。
由于物理上的原因,磁盘写入磁头所需要的宽度要比读取的磁头宽上很多,这就导致了读写两个操作对于磁道宽度的需求其实是不对等的,写入需要的宽度更多,这就给提高磁盘密度带来了可能性,下面我们再来看一下SMR磁盘的构造。
SMR硬盘写入的新磁道与先前写入的磁道部分重叠,从而使先前的磁道更窄,因此能拥有更高的磁道密度。由此可以看出,使用叠瓦磁技术的磁道相互重叠,与用作屋顶的瓦片堆叠方式类似,所以叫做叠瓦磁记录硬盘。
从SMR硬盘的硬件构造我们不难看出在提升硬盘存储容量的同时,对于写入其实会造成很大的困难,一旦当前磁道的下一条磁道被写入过数据,这个磁道如果再想写入,由于磁道有重叠,写入的磁头又较大就会对后面的数据造成影响。所以从使用的角度来看,SMR硬盘会被划分成若干的Zone,每个Zone中的数据只能够进行追加写入,这其中又会有1%的Zone,磁道不重叠,叫做CMR Zone,可以支持随机读写。
可想而知如果要对上层屏蔽SMR盘带来的限制的话会带来不少的代价,这里有device managed、host aware两种方式来简单屏蔽掉SMR的顺序写入限制,但不论哪一种,都是将随机IO转化为顺序IO,这样会带来一定的写放大以及读性能下降,以及在特定IO场景下的硬盘寿命影响,且上层对其影响不可控。
UCloud存储团队在多个现有产品上,都有绕过文件系统直接对块层存储操作的技术积累,为避免对底层存储落地文件系统有强依赖,我们选取了host managed的方式来对SMR盘进行读写管理。
在硬盘数据落地的同时,我们也将相关的少量元数据与数据合并在一起写入,这样做有三方面考虑:
一是这部分少量元数据,我们会包含这一次IO的整体CRC,用于防止硬盘的静默错误(Silent Data Corruption),提高用户在使用US3归档存储时的数据可靠性,因此在冷存储这种海量且长期存储场景硬盘的比特位反转(bit flip)等错误还是需要我们特别关注的。
二是当我们的元数据受到一些毁灭性的软硬件问题导致不可用时,我们可以通过重新读取这些随IO写入的元数据复原出整体的结构,当然这个代价也是比较大,预期也是在应对一些黑天鹅事件时的处理方案。
三是可以降低我们的写放大,在写入时不会由于需要更新元数据而写入两次IO,这在随机IO能力不是强项的HDD硬盘场景下也格外重要。
我们选取了其中头部的若干CMR Zone用于自解析当前盘的元数据,并冗余多份,这里由于自身1%的CMR Zone对于元数据来说还是较多,所以这里我们将部分CMR Zone和只能追加写的SMR Zone都抽象成了只能追加写的Data Zone,来最大化的利用磁盘的空间。
至此我们提高了单块磁盘的存储密度,使单块硬盘存储空间提升150%,相较于之前,我们还提高了单机柜的磁盘密度来进一步提升整体的存储密度。相较于传统36盘位的传统高密机型,我们采用了JBOD的方式。这里受益于 UCloud自建机房的优势,先前单机柜机房地板承重以及高功率机柜稀缺的限制不再存在,从而可以在单机柜存放更多的JBOD存储设备,使单位机架的存储容量提升5.375倍,硬盘数量增加59%。
除此之外,我们还采用了双机头硬件架构,所有JBOD中的硬盘保证同时双机头可见,这样保证了在单机宕机的情况下,仍然可以通过我们的选主算法立刻切到另外一个机器上,保证服务的可用性。
优化IO调度算法降低运营成本
提高密度本质上降低的是我们的CAPEX(Capital Expenditure)资本性支出,在归档存储的场景下长期的OPEX(Operating Expense)运营成本也占比较大。这里我们做出的优化是在不影响用户使用体验及存储性能的前提下降低我们的电费支出(即降低OPEX成本)。
为此我们在IO调度层增加基于硬盘Spin-up、 Spin-down的调度算法。用来降低在高密度机型的冷存储场景下大量硬盘空转的电力浪费。
这里整体的调度算法需要考虑的因素很多,我们首先根据故障域把JBOD中的磁盘分成若干个磁盘组,保证在适当的EC条带以及JBOD个数下,能够容忍磁盘以及JBOD层面的故障,之后Spin up-down的操作都基于磁盘组为单位进行操作。
同时我们需要考虑在满足用户紧急读取需求的同时保证硬盘的Spin up-down次数在一定的范围之内,这里我们将硬盘使用寿命内的可操作上下电次数平均到每天每小时,在算法上保证磁盘的每次Spin up-down会有一定的冷却时间,而用户的普通读再通过正常的轮询上电的时间片内进行读取,这样既可以降低用户的使用成本也保证了用户数据在硬盘使用方式层面的可靠性。
除了可靠性上面的考虑,我们也需要保证写入的性能是否能够吃满我们的硬件,由于SMR盘以及业务逻辑的特殊性我们的写入包括之后的Compaction都是大量顺序写入,所以我们配合EC条带的大小保证一个磁盘组的写入数据带宽可以吃满我们整体设备的网卡带宽,这样在性能上就不会有额外的浪费。
写在最后
基于上述提高磁盘存储密度以及降低运营成本(即电费)两个主要方面的设计考虑,我们研发了US3归档存储的底层存储引擎(如上图所示),在大幅降低US3归档存储成本的同时,保障了在归档存储这种长期冷存储下的数据高可靠性。
后续US3归档存储会继续从各个方面提升产品的使用体验,例如更加便捷自动的数据降冷处理,更加智能化的降低存储成本,让用户充分享受UCloud技术创新带来的价格红利。还会探索深度归档场景下磁带等其他存储介质的使用,让用户不用与复杂的底层硬件进行直接的交互,就能满足海量冷数据存储的需求。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。