云计算存储技术分析

1、云计算存储技术分析摘要随着网络应用业务量的不断增长 , 云存储技术作为云计算系统的重要应用之 一，也得到了更多的关注。对云存储技术的研究实质上是研究分布式存储技术。 不同于传统的存储体系 , 云计算存储技术需要解决更多的数据以及运算的负载， 需要保证更好的数据可用性以及数据一致性， 需要提供更快的系统响应时间。 针 对这些需求， 各大公司都开发出可以很好的解决方案， 本文主要针对主流的云存 储系统( Google File System 、 Amazon Dynamo 等)进行分析，主要分析其在 冗余备份、动态扩展、负载均衡等方面的解决策略。关键词 ：云存储， 冗余备份，动态扩展，负载均衡Ab

2、stractAs with the rapid growth of web application, cloud storage is getting more and more attention. In fact, research on cloud storage is essentially research on distributed storage technology. Distinguished from conventional storage system, distributed storage technology needs to better support en

3、ormous amount of data and computing workload, guarantee better data availability and integrity, and provide shorter system response time. To meet those requirements, lots of giant companies have come up with great solutions, this article mainly analyses mainstream cloud storage system, such as Googl

4、e File System, AmazonDynamoetc. And the main focus is on strategy for redundant backup, dynamic extension, workload balance.Keywords ： cloud storage, redundant backup, dynamic extension, workload balance1 云计算与云存储简介近年来，云计算无疑是最热门的技术话题之一，越来越多的 IT 企业推出了 自己的云计算产品， 它的商业价值被给予了巨大的肯定， 被认定是未来发展的必 然趋势之一。那么什么是云

5、计算呢？目前，对于云计算的认识还在不断地发展变化，并没 有一个统一的定义。号称“网格之父”的 Ian Foster 是这样定义云计算的： “云 计算是由规模经济拖动， 为互联网上的外部用户提供一组抽象的、 虚拟化的、 动 态可扩展的、 可管理的计算资源能力、 存储能力、 平台和服务的一种大规模分布 式计算的聚合体”。1 从概念上看，云计算实质上是一种分布式计算，云计算的 核心思想， 是将大量用网络连接的计算资源统一管理和调度， 构成一个计算资源 池向用户按需服务，提供资源的网络被称为“云” 。当云计算系统需要运算和处理大量数据的存储和管理时， 云计算系统中就需 要配置大量的存储设备，高性能的云

6、存储也就成为了实现云计算服务的基本条 件。云存储是指通过集群应用、 网格技术或分布式系统等功能， 将网络中大量不 同类型的存储设备通过应用软件集合起来协同工作， 共同对外提供数据存储和业 务访问功能。 事实上，几乎在所有的基于云计算服务的应用中都需要高性能的云 存储来满足数据处理的需求。2. 云计算存储技术从云计算和云存储的概念中可以看出， 云存储实质上是一种分布式存储， 因 此对于云计算存储技术的研究的核心在于对分布式存储技术的研究。 由于云存储 底层设备的软硬件环境各不相同， 且所处的网络也是一个多变的环境， 因此云计 算的存储技术除了需要解决基本的海量数据的存储与获取之外， 还需要解决负

7、载 均衡、提高容错性、动态扩展等许多传统存储系统没有遇到过的挑战。针对上面提到的几点挑战，本文将对现有的技术进行介绍、分析及对比。2.1 提高容错性分布式存储系统（如 Amazon Dy name和GFS都是应用在实际服务器上的系 统，每一次出错都会带来巨大的损失， 然而由于分布式系统的运行环境决定了其 需要面对巨大的压力。据Google说，其每1000台服务器的集群中，平均每天坏 掉一台机器，因此容错性是分布式存储系统在设计时就必须优先考虑的问题。 2 为了提供较高的容错性， 常用的方法主要是冗余存放。 具体的做法就是将同一份 数据复制为多份（具体的数量是根据不同的应用场景决定） ，同时存储

8、在多个节 点上，这样就可以在某一节点出现故障（临时故障或永久性故障）时，存储在其 他节点上的数据备份可以继续提供服务。由之前所述平均每 1000台服务器每天 会有一台故障， 那么其实只需要将同一份数据保存在三台服务器上， 那样在同一 天三台机器同时出错的概率就降低为 10-9 ，几乎可以视作完全安全了。所以 Amazon Dynam和Google File System 都采用了这个策略。在提供了较高的数 据可用性的同时， 冗余存放还能带来分流数据请求， 降低服务器平均负载压力的 好处。同一份数据存储在多处地理位置不同、 网络情况不同的服务器中， 对于处 于正常服务状态的数据节点来说， 用户在

9、对数据进行读取操作时， 距离用户较近 并且网络状况较好的服务器节点可以提供更多的服务， 同时其他节点可以同时提 供数据传输，降低了各自的负载压力，提高了用户获取数据的速度。下面对AmazonDynamo和Google File System在提高容错性方面的策略（主 要是冗余存放）进行具体的分析和比较。2.1.1 Amazon Dynamo 冗余存放策略策略定义了 N,W,R三个参数，其中N代表系统中每条记录的副本数， W弋表 每次记录成功写操作需要写入的副本数，R代表每次记录读请求最少需要读取的 副本数。只要 W+R>N就可以保证数据的一致性，因为 W+R>N寸读写总会有交集 必

10、定最少有 W R- N个读请求会落到被写的副本上，所以必然会读到“最后” 被更新的副本数据。至于谁 “最后”的判断需采用时间戳或时钟向量等技术完 成，有逻辑关系先后由时钟向量判断，否则简单的用时间戳先后判断。这种做法相比我们最朴素的想法我们直观的想法一定认为如果系统要 求记录冗余 N 份，那么每次就写入 N 份，而在读请求时读取任意一份可用记录 即可要更安全，也更灵活。说其更安全是指数据一致性更能被保证：比如说客户写入一条记录，该记录 有三个副本在三个不同点上， 但是其中一个点临时故障了， 因此记录没有被写入 或更新。那么在对该记录再读取时，如果取两点（ R=2 ）则必然会读取到最少一 个正确

11、的值（临时故障点有可能在读是恢复， 那么读出的值则不存在或者不是最 新的；若临时故障点还未恢复，则读请求无法访问其上副本） 。而使用我们传统 方法可能读到发生临时故障的那点， 此刻就有可能读出现错误记录 （旧的或者不 存在），因此可以看到加大 W,R 可提高系统安全性；说其更灵活则是指可通过配 置 N,W,R 这几个参数以满足包括访问方式、速度和数据安全等迥异需求的各种 场景：比如对于写多读少的操作，可将 W 配低， R 配高；对于写少读多的操作， 则可将 W 配高， R 配低。Dy namO对于临时故障的处理方式是：找到一台可用机器，将数据暂时写到其 上的临时表中， 待临时故障恢复后， 临时

12、表中的数据会自动写回原目的地。 这样 做得目的是达到永远可写， 即使该云中只有一台机器可用， 那么写请求的数据就 不会丢失。2.1.2 Google File System 冗余存放策略该策略主要通过GFS来实现数据的冗余存储。GFS将整个系统的节点分为三 种：Master、ChunkServer和Client。GFS中的文件被分成大小固定的数据块， 并由 Master 节点在创建时分配一个 64 位全局唯一的数据块句柄。数据块被ChunkServer 以普通 Linux 文件的形式存储在磁盘中。为了保证数据的可用性， 数据块默认保存三份。Master节点中则维护着系统的元数据（文件及数据块名

13、字节点、GFS文件到数据块之间的映射和数据块位置信息等），同时也负责GFS的全局控制（数据块 租约管理、垃圾数据块回收、数据块复制等）。Master节点定期与ChunkServer 通过心跳的方式交换信息，获得节点的活动状态。Client是GFS提供给应用程序的访问接口，它是一组专用接口，不遵守POSIX 规范，以库文件的形式提供。Client访问GFS时，首先访问Master节点，获取 与之进行交互的ChunkServer信息，然后直接访问这些 ChunkServer，完成数据 存取工作。需要注意的是，GFS中的客户端不缓存文件数据，只缓存Master中获取的元 数据，这是由GFS的应用特点

14、决定的。GFS最主要的应用有两个：MapReduce与 Bigtable。对于Map Reduce GFS客户端使用方式为顺序读写，没有缓存文件数 据的必要；而 Bigtable 作为云表格系统，内部实现了一套缓存机制。另外，如 何维护客户端缓存与实际数据之间的一致性是一个极其复杂的问题。2.2 动态扩展分布式存储系统的另外一项重要特性就是动态扩展， 所谓动态扩展就是在不 改变当前分布式存储系统的运行状态下实现系统的升级和维护， 主要是针对节点 的增加和删除。3本小节将分析GFS的动态扩展机制。GFS主要采用了 Master节点通过心跳的方式和ChunkServer交换信息，从而 获得节点的状

15、态信息。在 Master 服务器启动的时候，或者新的 ChunkServer 加 入到集群中时， Master 节点会向各个 ChunkServer 轮询它们所存储的数据块的 信息，通过这样的方式来支持动态节点加入。master 对每个 chunkserver 维护一个 hb_sequence ，表示 master 最近给 chunkserver 发送心跳的时间点 （ 单位为秒 ） ， master 会把这个值写入向 chunkserver发送的心跳请求中；同时维护一个 hb_res_sequenee，表示最后收 到 chunkserver 心 跳 请 求 的 时 间 点 ， chunkser

16、ver 的 心 跳 请 求 中 包 含 hb_res_sequence ， 每 次 收 到 chunkserver 的 心 跳 请 求 更 新 该 值 。 如 果 hb_sequence-hb_res_sequence 大于某个给定的值， 则认为该 chunkserver 已经下线在 ChunkServer 端 ， 当 其 收 到 Master 的 心 跳 之 后 得 到 本 次 请 求 的 hb_sequenee,然后 ChunkServer 更新全局的 g_hb_sequenee, 同时向 Master 发 起心跳请求，请求中包含 hb_sequence。 同时 ChunkServer 存

17、在一个定时器线 程定期检查本地时间和 g_hb_sequenee 的差值, 如果发现长时间没有收到 Master 的心跳请求, ChunkServer 就杀死自己, 因为他认为在这么长的时间内 没有收到 Master 的心跳,那么 Master 肯定已经认为自己死掉了, 所以就把自 己杀死。2.3 负载均衡随着现有网络各种业务量的不断增多,访问量和数据流量的快速增长,其处 理能力和计算强度也相应地增大, 使得单一的服务器设备根本无法承担。 负载均 衡(Load Bala nee)就是通过在分布式的系统上，将负载分配到多个操作节点上 运行,并在每个节点的负载处理完成之后, 将结果汇总并返回给用户

18、。 通过负载 均衡,分布式系统的负载承受能力得到了大幅度提升。 这样做的另外一个好处是, 大量并发访问被分摊到多个节点处理可以大大降低用户等待的时间。 分布式存储 系统在负载均衡方面都有着自己的核心技术，本节主要介绍Hadoop和GFS的负载均衡机制。2.3.1 Hadoop 中的负载均衡在hadoop的HDFS中设计有自动负载工具来进行负载均衡。其 中， ReplieationTargetChooser 类专门负责为新生成的数据块寻找存储节点，即主 要管理新数据块的备份数量、申请的客户端地址及已经注册的数据服务器位置， 其算法基本思路是只考虑静态位置信息， 优先照顾写入者的速度， 让多份备份

19、分 配到不同的节点中去。 4Balaneer 类则负责动态负载的调整和均衡，是 Tool 类的派生类，以可配置 的独立进程的形式运行。 它运行有 NamenodeProtoeol 和 ClientProtoeol 两 个 协议，与主控服务器进行通信， 获取各个数据服务器的负载状况， 从而进行调整， 即将一个数据块从一个服务器迁移到另一台服务器中。 5Balaneer 向目标数据服 务器发送DataTransferProtocoLOPREPLACEBLOCK?肖息，随后该服务器会写入Balancer该数据块，写入成功之后原服务器会将该数据块删除。可以通过配置 的负载差距阈值， Balancer

20、会根据配置来平衡负载。232 GFS中的负载均衡在GFS中,负载均衡是在数据块的创建和重新复制之后进行的。首先Master 服务器创建一个数据块， 决策把初始的空副本放在那里主要有几个因素。 首先副 本应尽量放置在平均硬盘使用率低于平均值的ChunkServer 上，以便平衡ChunkServer 之间的硬盘使用率， 其次应该尽量限制 ChunkServer 上的近期创建 操作数，因为虽然创建本身是廉价的， 但是它会紧跟这沉重的写操作， 因为写入 者需要写的时候才会进行创建， 而在我们的 "追加一次或多次 "的工作负载下块一 旦被成功写入就会变为只读。第三应该尽量将数据库分

21、散在不同的节点中。一旦数据块的可用副本数少于用户指定的数目， 服务器就会重新复制它。 这 种情况的产生主要原因有： 某个 ChunkServer 上的副本损坏、 磁盘故障导致不可 用或者用户提高了副本数目的配置。 需要被重新复制的数据块会基于几个因素排 序，一是数据块离它的副本数量目标的差距， 差距越大的数据块优先级越高， 二 是，活着的文件的优先级会高于近期删除的文件块， 最后， 为了失效对正在运行 的应用程序的影响，我们提高阻塞客户机流程的块的优先级。 Master 节点会选 择优先级最高的块，然后通知其他ChunkServer直接从源数据块拷贝到本地来实 现数据块的复制。在创建和重新复制之后， Master 节点会周期性对副本进行负载均衡，它先 检查当前副本的分布情况，然后移动副本来均衡负载和磁盘的剩余空间。另外， Master 节点必须选择哪些现有的副本要被移走。一般来说，它移动那些剩余空 间低于平均值的块服务器上面的副本，这样就可以平衡硬盘使用率。3. 总结云存储系统随着云计算的蓬勃发展，越来越多的得到应用，常见的云存储系 统（主要是GFS Hadoop Dynamc等）在处理分布式数据存储的时候都有着各自 的优点缺点，现在各个公司也都在基于开源或者商用的代码并针对自身的需求进 行开发。相信随着