云存储与云灾备的原理与短板分析.docx
《云存储与云灾备的原理与短板分析.docx》由会员分享，可在线阅读，更多相关《云存储与云灾备的原理与短板分析.docx（13页珍藏版）》请在冰豆网上搜索。
云存储与云灾备的原理与短板分析
云存储与云灾备的原理与短板分析
导读：
本文认为，现有的云存储应对普通用户小数据的备份与恢复应该问题不大，但是企业级用户大数据量的存储与恢复则要慎重考虑。
来自IDC的报告显示，2011年，1800EB的数据被创建和拷贝，且数据年增长率达到60%。
如果将所有的数据都存储在CD光盘上，堆起来的高度是地球到月球距离的6倍。
另外，随着各种家庭数字终端的兴起以及Web2.0的广泛应用，大众成为信息创造的主体。
移动互联网把信息的生产从PC拓展到手机，物联网把信息的生产从人拓展到物，IDC预测2020年全球产生的信息将达到350亿TB。
这些数据中的绝大部分将存储在世界各地的大型数据中心。
图灵奖获得者JimGray曾断言，现在每18个月新增的数据量等于有史以来的数据量之和。
信息数字化所产生的呈指数级增长的数据对存储系统的容量提出了严峻的挑战。
磁盘驱动器是一种机电混合设备。
计算相比，存储系统具有很多不同的特性。
随着社会信息化程度的不断提高，对数据存储的急剧提升，导致了以“计算”为中心到以“数据存储”为中心的观念革新。
在过去的十多年中，磁盘的区域密度、轨密度和线密度分别获得了100%、50%和30%的增长[4]。
在存储领域有两个重要的技术对存储系统的发展和存储容量的扩展产生了重要的影响。
第一个是并行存储，比如磁盘阵列技术[5]；第二个就是网络技术对存储系统体系结构的影响。
通过将网络引入存储系统，改变主机与外部存储节点间的连接模式，出现了若干新型存储体系结构：
附网存储（NAS）和存储区域网（SAN）。
网络存储技术对于解决存储设备的分散性、I/O的并行性、协议的高效性提供了一种很好的手段。
网络与存储设备不同的结合方式可以形成不同拓扑结构的网络存储系统，不同的拓扑结构对于系统性能的影响也各不相同。
但由于性能、价格、可扩展性等各方面的原因，这些仍不足以应对爆炸性的数据增长。
另外，许多大型企业的IT基础设施的利用率只有35%。
在某些企业中可能会低至15%。
Google报告称其服务器的利用率往往在10%到15%之间[9]。
这使得工业界不得不重新思考所面临的问题，并努力寻求解决的方法。
2001年，Google在搜索引擎大会上首次提出云计算的概念。
2007年年底，Google的一名工程师再次提出了云计算。
自此，云计算开始得到工业界、学术界和各国政府的广泛响应。
严格意义上讲，云计算并不是一种新技术，而是一种新的服务模式。
云计算将应用和计算机资源包括硬件和系统软件虚拟化之后包装成服务，通过按需付费的方式，穿越Internet来满足用户各种不同的需求。
用户可以不再需要购买昂贵的计算机系统，不再因为需要短时间使用某个软件而不得不购买该软件的使用版权。
这种服务模式在过去的十多年中有过充分的探讨，这两年的重新兴起并以一个新的技术名词出现，并不是因为产生了某种技术上的突破，而是由于信息数字化导致数据的爆炸性增长所带来的一系列问题让我们不得不重新思考计算机系统发展的新走向。
另外，由于技术进步所带来的部分老技术的重新复苏也对云计算的发展起到了推波助澜的作用。
借助于云计算的理念，将存储资源进行整合，并实现存储资源的按需分配。
于是就产生了云存储。
1云存储面临的挑战
云存储面向个人的应用主要由网盘、在线文档编辑、工作流及日程安排；面向企业的应用主要有企业空间的租赁服务，企业级数据备份和归档、视频监控系统等。
无论是哪种应用，海量数据的高度聚集都要导致存储系统从少数的存储引擎向连在网络上的成千上万的商用化存储设备进行转变，从传统的烟囱式的建设模式转变为集约化的建设模式。
在过去的十多年中集群网络的重要进展之一是可以将成千上万的节点连起来，同时保证高可扩展性和相对较低的通信开销。
因此，我们认为，采用商用化的技术来构造可扩展的集群是云存储的基本组件。
因为我们可以以搭积木的形式来聚合存储组件以构造大规模的存储系统。
但是现有的存储系统进行规模的扩展之后还存在很多待解决的问题。
1.1名字空间
存储器空间的组织和分配，数据的存储、保护和检索都依赖于文件系统。
文件系统由文件和目录组成。
数据按其内容、结构和用途命名成不同的文件，而目录则构建文件系统的层次化结构。
现代的文件系统一般都是按树形的层次架构来组织文件和目录。
集群文件系统往往也采用树形架构来构造名字空间。
然而，当数据的访问从树根走向树叶的时候，访问的延迟会相应地增加。
另外，还有两个重要的因素导致树形架构不适合于云存储环境。
第一，树根本身就是一个单一失效点，而且很容易形成系统的“瓶颈”；第二，树形架构很难在Internet上扩展到地理上分布的规模。
另外，层次化结构使得文件的访问效率不高。
每一层目录都隐藏了它所包含的子目录和文件，用户很难知道一个目录下面到底有哪些文件和子目录。
因此，用户访问某个文件时，必须通过层次型的目录树结构到达其保存位置，如果不知道文件保存位置，则必须遍历整个目录。
因此云存储只有采用非集中式的名字空间来避免潜在的性能“瓶颈”和单点失效。
1.2元数据组织
元数据是描述数据的数据，主要用来反映地址信息和控制信息，通常包括文件名、文件大小、时间戳、文件属性等等。
元数据主要是用来管理的操作数据。
研究表明，在文件系统的操作中，超过50%的操作是针对元数据的[10]。
元数据最重要的特点是其往往是小的随机请求。
一般来讲，元数据都是存储在磁盘上的，然而，和磁盘存储容量的增长不同的是，由于机械组件所带来的延迟，磁盘的平均访问时间每年的降低不足8%。
Hitachi的磁盘在过去10年里磁盘访问时间和寻道时间的发展趋势[12]如图1所示。
对于这种由小的随机请求所组成的数据访问流，磁盘的寻道时间是磁盘访问延迟中最主要的部分。
因此，对于大规模系统来讲，元数据的访问往往成为制约整个系统性能的“瓶颈”。
图1磁盘访问时间和寻道时间的发展趋势
很多分布式的存储系统将数据访问和元数据的访问分离开来。
在这样的系统中，客户端首先和元数据服务器通信来获取元数据包括文件名、文件位置等信息。
然后，利用该元数据，客户端直接和数据服务器通信去访问相应的数据。
一般来讲，元数据服务器的内存可以满足大部分的读请求，但服务器不得不周期性地访问磁盘来读取需要的数据，并且所有元数据的更新也要写回到磁盘。
存储系统空间的增长可以通过增加额外的存储服务器来保证。
然而，对于一个管理数以亿计的数据文件的云存储系统，保证元数据的访问性能和可扩展性比较困难。
对于像云这样的需要高可扩展性的环境，对元数据的依赖给系统设计带来了巨大的挑战。
1.3能耗与地板空间
图2数据中心的热密度趋势图
2005年美国新建立的数据中心需要消耗的能量相当于加利福尼亚州所消耗能量的10%（大约5GW），需要花费大约40亿美金。
英国的1500个数据中心每年消耗的能量和英国第十大城市莱卡斯特所需要的能量相当。
2010年，英国单个数据中心每年在能量上的花费达到大约740万英镑。
在这些数据中心中，存储系统所消耗的能量达到了总能耗的27%。
另外，消耗的能量除了供各种计算机组件工作外，还会产生大量的热量。
由于大部分计算机组件只能在一定的温度环境下才能保证足够的可靠性，因此，还需要额外的能量驱动制冷设备。
Netapp的调查表明大型数据中心中制冷系统的能耗仅次于服务器。
数据中心主要设备的热密度趋势如图2所示。
可以认为，数据中心的能耗问题处于一个恶性循环的状态。
另外，由于数据的增长导致数据中心对新设备需求的不断增加，但是数据中心的可扩展性完全受限于其地板空间。
在数据中心的空间未扩展的情况下，随着单位地板面积内计算机设备的不断增加，传统数据中心的设备容量必将达到极限。
因此，能耗和地板空间成为当前设计和管理大型数据中心所面临的主要挑战。
2云灾备
图3数据丢失的原因
国际上对于IT系统灾难的定义是指由于人为或自然的原因，造成信息系统运行严重故障或瘫痪，使信息系统支持的业务功能停顿或服务水平不可接受，并达到特定的时间的突发性事件。
虽然数据是企业的命脉，然而在传统的存储系统下，数据丢失很难避免。
数据丢失的原因如图3所示。
图3表示人为因素是导致数据丢失的最重要的原因。
由于管理员或员工的活动造成数据的损失或变更，使数据的完整性与真实性受到影响，如误删除、误格式化或误分区、误克隆等误操作，系统管理员出错或蓄意破坏、窃取等等。
因此，如果在云计算环境下，专业的工程技术人员将能最大限度地避免由于人为因素所导致的数据丢失。
然而，设备和硬件故障所带来的数据丢失则很难避免。
例如，硬盘损坏是极为常见的导致数据丢失的原因，一般来讲，磁盘阵列（RAID）系统能够一定程度上避免硬盘故障导致的数据丢失，如RAID1、RAID5都能够在一块硬盘失效后对数据进行修复。
但在两块硬盘失效的情况下，则仅有RAID6数据保护模式能够保护数据不丢失，而RAID6由于复杂冗余和校验算法导致系统大量的开销，一般企业采用时存在顾虑。
另外，大型存储系统中磁盘的失效往往是具有相关性的，一块大容量磁盘失效后要进行长时间的重构（例如，1TB容量的磁盘重构可能需要数小时），会对系统带来极高的存储I/O率，这可能导致另一块磁盘的失效，从而引发连锁效应。
因此，利用蝴蝶效应来描述毫不为过。
2011年4月，亚马逊的网络服务经历了长时间断电，造成停机等一系列问题，并且影响到了云计算的服务。
在长达4天的时间里，一些客户无法使用亚马逊的存储服务，并且会出现网络配置错误。
2011年4月25日，Vmware的CloudFoundry在发布13天后连续两天发生服务中断事件。
第一次是由于某供电柜发生故障，在停机持续了10小时后，故障得到修复。
但在第二天，当Vmware的官方工作人员在尝试实施先期检测方案以避免前一天的事故再一次发生时，导致了新一轮的停机。
2011年8月，都柏林的亚马逊和微软的数据中心因遭遇雷击而停电，两家企业都经历了数天才完成修复。
国际最知名的IT企业也无法保证其IT基础设施的24×7×365业务连续性。
再者，不可预测的自然灾害也会导致数据丢失，如日本的广岛地震，中国的汶川地震等。
因此，对数据进行有效的灾备，并经常性的进行恢复演练确保备份的有效性能够最大程度的降低因为硬件故障导致数据丢失的可能性，充分得到云存储用户的信任。
2.1灾备的技术指标
在容灾体系中，人们往往采用恢复点目标（RPO）和恢复时间目标（RTO）这两个指标来衡量容灾体系的应急能力和系统保护能力。
RPO体现为灾难发生后，恢复运转时数据丢失的可容忍程度。
RTO表示需要恢复的紧迫性也即多久能够得到恢复的问题。
然而，在设计一个容灾系统时，并不意味着RPO和RTO越小越好。
因为系统投资会随着RPO和RTO的降低而增加。
因此，最佳的容灾方案不一定是性价比最好的方案。
2.2数据备份
数据备份是指为防止系统出现操作失误或系统故障导致数据丢失，而将数据集合从应用系统中以备份格式存储到处于离线的存储介质的过程。
在数据备份过程中，一般采用备份软件配合磁带库的物理介质保存系统来进行。
数据备份分为完全备份、差异备份和增量备份。
完全备份是指对某一个时间点上的所有数据或应用进行的一个完全拷贝。
差异备份则备份自上一次完全备份之后有变化的数据。
增量备份则备份自上一次备份（包含完全备份、差异备份、增量备份）之后有变化的数据。
无论哪种模式都完全服从备份计划的规定，即在固定的时间点开始备份。
传统的备份系统并不保证数据的实时性或近实时性。
而且，备份后的数据格式是专用的备份格式，并非应用系统中的数据原有格局。
因此，当发生灾难时，备份数据是不能立即使用的，必须先恢复。
恢复时要通过格式转换进行导回操作，这导致无法保证恢复的快捷。
例如，如果按Th的时间间隔来进行增量备份。
如果在A时间点发生了系统故障，那只能回复到上一个备份点A-T，而且还要进行数据格式的转换。
随着T的增加和数据量的增涨，需要恢复的时间也随之线性增涨。
因此，指标RPO和RTO都会较高，也很难保证IT基础设施的24×7×365业务连续性。
另外，为了提高RPO，必须提高数据备份的频度。
但大多数情况下，仅仅增加备份的频度会带来一系列的问题。
例如：
应用的高峰时段无法进行备份操作；备份数据所花时间太长。
因此，需要有一个契机和一个新的技术的诞生，来达到以用户为中心的数据安全和系统安全的要求。
2.3数据复制
为了保证较低的RPO和RTO目标，数据复制技术常应用于各种灾备系统。
数据复制是将原卷或原文件直接复制到目标卷或目标文件系统中，分别称为卷复制和文件复制。
由于数据复制的目标卷（目标文件）和源卷（源文件）的数据格式一致，可以消除备份系统中数据格式的转换时间。
数据复制又分为同步复制和异步复制。
2.3.1同步复制
同步复制表示，在数据复制系统的源端，主机发出的I/O请求在写入本地磁盘的同时，通过专用的数据网络或通道将数据从本地磁盘系统同步地复制到异地磁盘系统。
当异地系统完成该I/O操作后，通知本地系统I/O完成，本地的主机系统才能发出第二个I/O请求。
利用同步复制方式建立异地数据灾备，可以保证异地系统和本地系统数据的完全一致性。
但同步复制方式对性能的要求非常高。
由于每一次本地I/O必须要等到数据成功地写到异地系统，才能进行下一个I/O操作，因此同步复制的性能受网络带宽、网络的距离、中间设备及协议转换等多方面的影响。
2.3.2异步复制
异步复制是指在数据复制系统的源端，主机发出的/O请求在写入本地磁盘的同时，向本地磁盘系统上预留的空间发出相同的写请求（决定于不同的策略），然后通知本地系统I/O完成。
此时，本地的主机系统可以发出第下一个I/O请求。
在设定的复制规则满足后（基于时间、基于变化量等），系统的复制功能模块再将数据通过专用的数据网络或通道复制到异地的存储系统中。
2.4灾备分析
与同步复制相比，异步复制对网络带宽和距离的要求低很多，只要在某个时间段内能将数据全部复制到异地即可，同时异步复制对应用系统的性能影响也很小。
但是，当本地系统发生灾难时，异地系统上的数据可能会短暂缺失（在复制的时间间隔内数据未完整地从源端发送到目的端）。
因此，当源端灾难发生时，同步复制的RPO接近于0，异步复制的RPO则取决于复制时间间隔。
同时，在业务恢复时间上，相对于传统的备份系统而言，由于不存在数据格式的转换，可以在较短的时间内恢复业务系统，从而具有较好的RTO。
对于1000亿元人民币以上的银行，银监会要求建立200km以上的备份系统。
因此只能使用远程复制模式。
同城复制可以使用光纤，但是远程复制由于成本方面的因素，全光纤传输还很遥远。
因此，不可能采用同步复制。
所以，远程异步复制模式会越来越多。
3云存储与云灾备的短板
当用户向云存储系统中进行数据备份时，网络对系统性能的影响起到了至关重要的作用。
当云存储服务提供商在进行后台的云灾备时，远程的云备份和云复制也依赖于网络的性能。
图4英国剑桥大学到中国北京的网络带宽
3.1网络短板
按照Nielsen法则，终端用户的网络带宽以每年50%的速度增长。
然而，和局域网形成鲜明对照的是，广域网的性能不尽人意。
例如，一条T1线路的带宽只相当于千兆网的千分之一，许多帧中继线路的带宽只有256kb/s。
Garfinkel[19]通过测量发现从美国伯克利大学到西雅图的平均网络写带宽大约是5~18Mb/s。
通过使用网络测试工具iperf，采用256个数据流测量，数据表明在格林尼治标准时间下午7点到10点，从英国剑桥大学到中国北京的平均网络带宽大约是14Mb/s，如图4所示[20]。
基于以上的测试数据，如果假设网络带宽为20Mb/s，Armbrust[21]等人作了简单的计算，计算结果表明从美国伯克利大学传输10TB数据到西雅图需要45d的时间（10×1012B/（20×106b/s）=4000000s=45d）。
如果通过亚马逊来进行该数据传输，需要另外向亚马逊支付1000美元的网络传输费用。
另外，由于广域网物理距离的原因，不可避免的时延也会对带宽造成影响。
例如，一个T3链路（44.736Mb/s），当时延超过40ms时，其带宽很快就下降到与T1链路（1.544Mb/s）相当。
如果是进行云备份，时间上的开销相对还可以忍受，因为用户在本地还有一个数据拷贝可供使用。
但如果是从云存储系统中恢复数据，这是无法让人接受的，特别是对于那些需要提供24×7×365业务连续性的企业级用户。
为了缓解这个问题，对于云存储系统中大数据量的恢复，云存储提供商Mozy[22]和CrashPlan[23]提供了一个不得已的选择，在用户许可的情况下，将数据转存在DVD或者硬盘上，然后通过特快专递的形式交付给用户。
3.2网络优化
ACK：
确认
图5针对广域网数据传输的协议优化
针对广域网数据传输的协议优化如图5所示。
为了优化广域网环境下大规模数据传输的性能，我们曾将数据在套接字层在发送端进行分割，然后利用多个套接字流进行并行传输，最后在接收端进行数据重组（如图5（c）所示）。
理论上讲，对传输控制协议（TCP）管道而言，其最大的吞吐量为带宽延迟乘积，即容量=带宽×环回时间。
在传输窗口一定的情况下（图5中红色的方形区表示传输窗口，缺省为64kB），按通常100Mb/s的网络带宽来计算，传统的单套接字流显然无法填满TCP管道（如图5（a）所示），使得其效率极低。
通过加大传输窗口可以在一定程度上提高TCP管道的利用率（如图5（b）所示），但在丢包的情况下，会导致每次重传的数据增加。
因此，通过多个套接字流来并行传输的效果较好。
另外，由于采用了多流，不同的数据流在必要的情况下可以走不同的路由，也能够进一步优化广域网的性能。
正如前面提到的，云基础设施必须是地理上分布的，因为云的成功在很大程度上决定于其规模效应。
虽然计算和存储相对便宜，然而，由于广域网环境下的低带宽、高延迟和较高的丢包率，使得广域网成为云环境下那块最短的木板。
因此，在地理上分布的云环境下进行大规模的数据传输是非常昂贵的。
图灵奖获得者JimGray在2006年就指出在广域网上处理大数据集时，应该将程序传给数据，而不是将数据传给程序。
另外，也可以通过数据压缩、数据去重等方法来减少网域网上的数据传输流量，降低对网络带宽的需求。
还可以采用动态缓存、IP流量管理以及服务质量（QoS）控制等方法来降低广域网的延迟。
但是，这些方法只能在一定程度上来缓解网络“瓶颈”问题，不能从根本上解决问题。
因此，在设计云存储和云灾备系统时，必须要考虑广域网的带宽、延迟和包丢失率所带来的影响。
4云存储实例分析
图62.12GB数据的备份时间
图72.12GB数据的恢复时间
对于企业用户而言，现有的云存储更多的是一种在线远程备份系统。
Hu等人针对Mozy、Carbonite、Dropbox、Crashplan4种云存储系统进行了测试、比较和分析。
当将8GB的文件备份到云存储系统中时，有的系统的备份时间超过了30h，还有的系统经过4d的时间还未备份完成。
当他们将数据集减小到2GB左右时，云备份系统才回复到基本正常的工作状态。
图6表示Hu等人在Mozy、Carbonite、Dropbox、Crashplan4个不同的云存储系统下备份2.12GB数据时的远程备份时间。
其中横坐标从左到右的4种情况分别表示单个2.12GB的大普通文件、单个2.12GB的大稀疏文件、很多小的普通文件组成2.12GB的数据集、很多小的稀疏文件组成2.12GB的数据集。
稀疏文件表示该文件不包含用户数据，也没有分配用来存储用户数据的磁盘空间。
当数据被写入稀疏文件时，文件系统（例如微软的NTFS）才逐渐地为其分配磁盘空间。
可以看到对于正常2.12GB的文件数据4个系统的备份时间都超过了5h。
图7表示相应的恢复时间。
恢复比备份要相对快很多，这主要是由于网络的上行链路和下行链路带宽的不对称造成的。
通过大量的测试分析，Hu等人得出了一下结论：
（1）云存储系统必须对于网络失效具有回弹性，同时能够实现大文件的增量备份。
（2）云存储提供商在进行大数据的网络传输时还要进行加密、压缩等预处理以避免网络延迟。
（3）云存储用户需要手动检测重要的文件是否都已经进行了备份。
（4）云存储用户应该将云存储系统作为本地备份系统的一种补充，而不能将其当成主要的备份策略。
本文认为，现有的云存储应对普通用户小数据的备份与恢复应该问题不大，但是企业级用户大数据量的存储与恢复则要慎重考虑。
5结束语
云存储面向个人的应用主要有网盘、在线文档编辑、工作流及日程安排。
面向企业的应用主要有企业空间的租赁服务，企业级数据备份和归档、视频监控系统等。
云灾备则主要用于保证云存储服务商后台系统的可靠性和可用性。
对两者而言，海量数据的高度聚集会对系统带来一系列的挑战。
例如，如何实现海量存储系统从传统的纵向扩展向横向扩展转化？
如何实现系统的性能和规模线性可扩展？
如何处理海量存储系统的高度聚集带来的能耗和冷却？
等问题都是我们在进行云存储和云灾备系统设计时必须要考虑的重要因素。
当然，云存储最终能否成功，还受到其他很多因素的影响，如大量的数据存储在云端如何保证数据的安全和用户隐私等。
-全文完-
升级会员 