一探文档存储的究竟

一探文档存储的究竟

揭开冷存储的神秘面纱

Per Brasher

互联网界的大老们均在追求服务期更加长久的解决方案。所谓服务期更长,所指的也许是MTBF(无故障运行时间)从3,000,000增至4,000,000,或者是7年的质量保证。不论所指为何,涉及到文档类硬盘,都会有些难缠的问题。本文的出发点即是弄清楚冷存储系统中最为要紧的几个因素。

如果您急于揭晓答案,文末专门有一小节归总结论,此外,还有向供应商以及客户提出的若干问题。

以前我在Facebook工作时,曾经发明了一个词:冷存储(ColdStorage)。我还(不无遗憾地)发明了“冷闪存”(ColdFlash)一词——这点留待后面再谈…

当时发明冷存储的意图是与“文档”及“备份”等应用区分开来。上述两种应用都意味着数据取用时存在巨大的延迟,并且消化吸收时负担很重。而冷存储的应用特点包括运营成本极低及数据持久度极高,在需要时,能够以几乎无损的速度来恢复数据或直接提供在线的数据访问。

1.    服务期

超大规模数据中心中服务期如何计算还有许多问题。常用的一种计算方法是将质保期的60%作为“浴缸效应”生效的开始,此时,硬盘在灰市上的价值为初始价值的50%。还有些公司会将设备用到质保期终结,届时再整体替换。目前尚无公司愿意将设备用到超出保证期直至终结。

我们都知道从MTBF(平均故障间隔时间)来推导出AFR(每年故障率)的方程式并非绝对精确,客户从设备的“完美实验数据”来推算出现实世界”的故障率时所用的方法也小有区别。公布出来的数据来看,实际结果与方程计算结果的倍数可能从5倍到10倍不等。来看看一些基本的事实。比方说,该程式假设故障率是恒定的——这当然是绝无可能的。但是,照此假设,一块标明MTBF为2M小时的硬盘算出来的AFR是.44%。从常温数据中心获得的实验证据表明,一组混合型的、老化了的(尚未超出保质期)硬盘的AFR为4.4%。就此看来,我们可以将从方程中得出的AFR值乘以10,得到数值的精准度还算令人满意。因此,800K小时MTBF的硬盘按照方程算出的AFR为1.1%,而根据如上的调整,AFR则为11%。这个调整后的故障率是不可忍受地高!

再来看另外一个难以确定的问题,到底是什么在影响硬盘的使用寿命?很清楚,物理特性、传送的字节数、加载/卸载周期、启始/停止周期都是些久经测试并为人熟知的影响因素。然而,在常温数据中心中又增加了一些鲜有记载的新的挑战。举例而言,每个小时硬盘的deg
T及% RH。测量方法是在硬盘前方9英寸处每个钟头读出一个值,然后将delta值上报。因此,一个常温数据中心完全可以启动汽化冷却——这种冷却方式会导致RH值和Temp的急剧变化,但在这个钟头的剩余时间内维持这个新的高度,从而保持在说明书中指定的范围。换句话说,说明中没有指定任何曲线变化的斜率而只是将其隐含在内。所以,如果缺少必要的信息,就很可能在这个过长的时间内在不知不觉中作出违规的操作。

那么,温度和湿度的变化幅度是不是重要的影响因素呢?(请记住,讨论针对的是文档类的存储)有关这个问题已经发表了一系列的研究论文,特别是在冷存储的环境下。看起来,那些无法自己维持温度稳定(从而抵御潮湿)的部件都难免遭遇更大型系统会碰到的各种困难。如果该系统允许“空气调节”中存在迅猛的变化,那么,可能造成的影响就十分巨大。为了理清这番讨论的真正含义,有证据表明,在常温数据中心里,空置或不常用的硬盘比常用硬盘的出错率更高。因此,对段落开始的问题的直接答案是肯定的。

2.
不可修复的比特误码率
UBER, Uncorrectable Bit Error Rate.

这第一段是我个人的一些牢骚话。如果您对我们作为一个行业整体造成的失误,那就请您跳至下一段,接着阅读有关数据的讨论。在硬盘中,不可修复的错误在所有类型的硬盘中时有发生。但硬盘消耗了惊人的甚至长达3,000
ms的时间来避免一次不成功的读写为人所知!!这是怎么回事呢?这种做法很成问题。问题就出在操作系统驱动的设计者身上。过去很长一段时间里,存储都是IT中未能得到足够重视的一部分。而现在,当我们进入了一切围绕“数据”的新时代,操作系统的设计者们必须要觉醒过来,认识到潜藏在数字系统之下的其实是一台模拟模糊的设备,然后对丢失的块、不可读的分区等作出妥善处理。纠删码在宏观层面效果不错,LEC再中级层面也很有潜力,但无论如何还是无法确定取出的数据究竟是否就是存进去的那些。(实现T10标准定义的DIF(Data
Integrity Field)是有效而微弱的第一步。)

UBER影响着运维。即便忽略掉由于操作系统无法完全掌握实际的情况而造成的硬盘无故被标错的情况,硬盘的不可修复的比特误码率的影响也十分巨大,。“软”错误的发生率还算在合理范围内,比如110-15。这个数据意味着每传输125拍字节的数据,在正常运营中就会发出一次出错信息。其在超大规模数据中心中造成的结果是损失了存储容量来换取网络/CPU。如果有个不带本地保护的N-1纠删码系统,那问题就简化成了,每传送125拍字节的数据,结果是至少有一个区段出错。这就意味着,在一个[10,14]纠删码的系统中,必须找到10个有效区段,重新计算4位校验码,写一个14块大的新条带,再将原来的(剩下的)区段设置到垃圾回收模式。

故此,若你要做简单的读10个区段的操作,该系统实际上要做的操作包括:
10+CPU+14+13, 即37次IO操作在加上CPU开销,并且同时会产生大量网络流量。因此,把系统对UBER指标的要求放宽松一个数量级(从110减为14)对系统整体的成本效应为1037倍。换而言之,每传送13PB的数据会导致37倍于此的I/O和网络系统的负载开销。

3.
使用模式

冷存储系统的目的在于防止数据彻底丢失。“使用者的无知”(推送有Bug的新版本代码上线到业务系统中造成全部在线资源的破坏)是我们准备防范的数据丢失的根源。在此情况下,要在任何意义上实现业务的持续性,系统必须具备某种程度的公平性。另一个主要目标是从设备设计到运营成本两个方面着手,在力所能及的范围内尽可能降低成本。由于在设备设计方面的成本缩减已经到了极致,在当前的各种局限下,从运营的角度来降低开支可能会带来更大的影响。

冷存储系统都有着非常怡人而富有创意的名字,如Pelican, SubZero等等。但这些系统都采用了某种公平调度的机制。Pelican系统中采用了热平衡与能耗平衡的机制,而SubZero系统则采用了时间切分机制。在两种系统中,任何一个需要恢复的数据集合都会跨越若干个平衡区,所以需要有一个临时区域先将数据整理清楚,然后再把数据返回到业务系统中去。这是所谓“冷闪存”的第一个实例,这一概念在每个行业中都多少有所扭曲,在此,我先向大家致歉。

冷存储中数据的保持期可能各有不同。有时,律师会要求将其记录保存至案子结束;公司的数据则需要保存七年时间;社会及医疗记录则需要留存达99年之久。但基本上没有短于五年期的。因此,由于BlueRay的数据保持时间很长,BlueRay
DVD技术又像打了鸡血一样重新获得了活力,成为冷存储市场的竞争技术之一。

有些超大规模数据中心转而开始使用磁带,因为磁带的介质和维护的成本低廉。但是,对于提供快速检索恢复的能力而言,磁带并非理想选择。实际情况是,如果有一个图书馆,在其间堆满磁带,从来不将磁带取出(为了满足快速恢复的需要),一年后的平均总成本基本等同于磁带!磁带在常温数据中心里也面临了颇有意思的挑战。温度升高时,磁带会伸长;环境潮湿时,又会粘在一起。还有,磁带的能耗如此之低,乃至于根本无法自己进行温度管理。所以,数据中心里必须要做一个单独的低能源效率的仓库来存放磁带……实在太不酷了。

4.
在大规模部署中将所有因素综合考虑

好,现在到了总结部分。首先,先把几个变量确定下来。先从一个标准的具有7MW电力供应、占地约20,000平方英尺、约1,000个机架的数据中心说起。为了管理I/O及无法避免的EC恢复的需要,合理的计算与存储的占比可以为:4%用于计算,余下为存储。提供总共约260,000个硬盘插槽。若是我们将上述方程计算得出的固定数值针对现实作出相应调整,得到的结果是,一个MTBF为2M小时的硬盘的出错率为5%,而一个MTBF为800K小时的硬盘的出错率为11%。这个数字再乘以磁盘总数,得出的结果是每一年,MTBF为2M的硬盘有12,975个会出错,而MTBF为800K的硬盘有28,545个会出错!大家都知道,“浴缸效应”的影响是高于上述数值的,第一年会是大约三倍于此,质保的最后一年也差不多。800KMTBF硬盘的质保期为三年,所以在单个生命周期当中,按照以上固定出错率来计算,会有85,635个硬盘需要更换,如果模型再根据浴缸效应作出调整,这个数字就变成了199,815(换句话说,也就是全部硬盘总数的77%)。依然是令人沮丧的局面啊!

现在,再回到数据完整性和生命期的问题。如果按照每年28,545块硬盘出错的数字,再在这些硬盘上加上一层纠删码,前面已经讲过,数据中的一个漏洞可能导致网络/磁盘子系统上的I/O达到37倍之多,每年累计达数字将是超过百万次全部数据的搬运(在网络上读剩余的位,计算新的校验码,在网络上写出新条带,对旧条带进行垃圾回收处理等等)。即便是在小到不能再小的1TB的硬盘上,每年也会有超过一艾字节的数据移动。如果系统中用的是个大容量的硬盘,很快,移动数据的总量就会超出系统能承担的最大负荷。数据的安全无疑就成了重大的隐患。

再从另一个角度来看这个问题。Yttibrium一直在建议此类系统的供应商及其用户注意一个设计要点,即MTBF为4M小时,生命期为7年的硬盘。我们还在硬件中设计了纠删码的辅助单元,让37倍之多的问题都能在每个存储节点内部得到解决,而不是在节点之间的网络上。有了Yttibrium的设计要点的帮助,在上文描述的假想系统环境中,出错率被调整到了2.1%(从实验室到现实世界的调节指数还是采用相同的10倍),也就是整体260,000中的5,450块硬盘。这样一来,也不再需要在第三年或第五年硬盘的生命周期终结时对数据进行迁移。此时,也恰好到了SEC保存的期限,因此硬盘与数据的使命同时终结——社会或医疗数据除外。除了上述优点以外,确有需要将数据保存超过7年时,数据的迁移可以在后台采用LEC算法透明地完成(只要存储节点在两次硬盘更换之间的空闲中能抽出时间来完成数据迁移的任务即可)。

几点请求

供应商:请为业界提供针对机箱内LEC而优化的、具备很高RV耐受力的硬盘,好让我们能进一步降低机箱的成本;一款MTBF为4M小时、使用期7年的硬盘,价格成本要能让我们的TCO(总拥有成本)收益在第三年得到全部实现并有盈余。

用户:请将更多有关硬盘、可靠性及运营环境的数据发布公开。向BackBlaze学习,将确切的需求及其使用条件更加公开化。要説服硬盘厂商延长产品的生命期并降低出错率并非易事。您的数据会有很大帮助。

时间: 2024-07-30 12:41:53

一探文档存储的究竟的相关文章

[Elasticsearch] 分布式文档存储

本文翻译自Elasticsearch官方指南的distributed document store一章. 分布式文档存储 在上一章中,我们一直在介绍索引数据和获取数据的方法.但是我们省略了很多关于数据是如何在集群中被分布(Distributed)和获取(Fetched)的技术细节.这实际上是有意为之 - 你真的不需要了解数据在ES中是如何被分布的.它能工作就足够了. 在本章中,我们将会深入到这些内部技术细节中,来帮助你了解你的数据是如何被存储在一个分布式系统中的. 路由一份文档(Document

MySQL更改默认的数据文档存储目录

MySQL默认的数据文档存储目录为/var/lib/mysql.假如要把MySQL目录移到/home/data下需要进行下面几步: 1.创建目录 cd /opt && mkdir data 2.把MySQL服务进程停掉 mysqladmin -u root -p shutdown .. 或者 service mysqld stop 3.把/var/lib/mysql整个目录移到/home/data mv /var/lib/mysql/* /opt/data/ 这样就把MySQL的数据文档移

微软的在线文档存储OneDrive使用帮助

onedrive默认空间5G,对于一般的文档存储够用的,很方便不限速!!! ###官方介绍 https://support.office.com/zh-cn/article/%E4%BA%86%E8%A7%A3-onedrive-files-on-demand-0e6860d3-d9f3-4971-b321-7092438fb38e?ui=zh-CN&rs=zh-CN&ad=CN ps:介绍的不错,get技能! 01.下载 download:  点下载 02.启动 //本地exe启动 C:

Elasticsearch分布式文档存储(四)

1.将文档路由到分片 索引文档时,它存储在单个主分片上. Elasticsearch如何知道文档属于哪个分片?当我们创建一个新文档时,它是如何知道它是否应该将该文档存储在分片1或分片2上? 该过程不能是随机的,因为我们将来可能需要检索文档.事实上,它由一个简单的公式决定: shard = hash(routing)%number_of_primary_shards 该routing值是一个任意字符串,默认为文档 _id,但也可以设置为自定义值. 此routing字符串通过散列函数传递以生成一个数

mongodb 分布式文档存储数据库

简述: MongoDB是一个基于分布式文件存储的数据库.由C++语言编写.旨在为WEB应用提供可扩展的高性能数据存储解决方案. MongoDB是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的. 他支持的数据结构非常松散,是类似json的bson格式,因此可以存储比较复杂的数据类型. Mongo最大的特点是他支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引. 在高负载的

分布式文档存储数据库 MongoDB

MongoDB 详细介绍 MongoDB是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的.他支持的数据结构非常松散,是类似json的bjson格式,因此可以存储比较复杂的数据类型.Mongo最大的特点是他支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引. 整体架构: 内部架构: 它的特点是高性能.易部署.易使用,存储数据非常方便.主要功能特性有: 面向集合存储,易存储

文档存储位置及备份情况

core data 存储的位置是Documents文件夹下,nsuserdefault 存储的路径为Library/Prefereces下的一个plist文件,因此在备份app时两者都会备份(library下的caches文件夹下的数据是不会备份的).

章节首语-分布式文档存储(distributed document store)

在上一个章节,我们了解来向index插入和检索数据的所有的方法.但是对于数据是怎么样分布和检索的很多细节都没有进行详细的解释.这种分开讲解(没有详细的解释)是故意的,你不用知道ES中数据是怎么分布,怎么工作的,但是就知道他能工作就行了. 在本章节,我们将会深入的讲解内部的细节,帮助你数据是怎么存储在一个分布式的系统上的. 内容提示 你会对下面呈现的内容感兴趣的.你不用必须去了解和记忆使用ES的所有细节.这个章节是为高级使用者准备的. 阅读这个章节将会了解ES是怎么工作的,并且知道在如果将来的某些

如何将arcgis的mxd文档存储为相对路径

在默认情况下,ArcGIS 10中地图文件mxd中添加的图层所引用的文件路径均为绝对路径.这就意味着,如果你在地图中引用了“D:\data\DEM.shp”文件,那map.mxd文件中保存的该层文件路径也为“D:\data\DEM.shp”.这时如果你要将该项目文件转移到其他位置时,即使将整个项目文件夹都复制了,再次打开map.mxd文件时也会出现引用错误的情况. 通过在ArcMap中将mxd文件设置为引用相对路径,则可避免日后项目转移可能面临的问题.对于已有引用绝对路径的mxd文件,也可通过相