云计算存储技术分析.doc

云计算存储技术分析摘要随着网络应用业务量的不断增长,云存储技术作为云计算系统的重要应用之一，也得到了更多的关注。对云存储技术的研究实质上是研究分布式存储技术。不同于传统的存储体系,云计算存储技术需要解决更多的数据以及运算的负载，需要保证更好的数据可用性以及数据一致性，需要提供更快的系统响应时间。针对这些需求，各大公司都开发出可以很好的解决方案，本文主要针对主流的云存储系统（Google File System、 Amazon Dynamo等）进行分析，主要分析其在冗余备份、动态扩展、负载均衡等方面的解决策略。关键词：云存储， 冗余备份，动态扩展，负载均衡AbstractAs 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 enormous 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 Google File System, Amazon Dynamo etc. And the main focus is on strategy for redundant backup, dynamic extension, workload balance.Keywords：cloud storage, redundant backup, dynamic extension, workload balance1 云计算与云存储简介近年来，云计算无疑是最热门的技术话题之一，越来越多的IT企业推出了自己的云计算产品，它的商业价值被给予了巨大的肯定，被认定是未来发展的必然趋势之一。那么什么是云计算呢？目前，对于云计算的认识还在不断地发展变化，并没有一个统一的定义。号称“网格之父”的Ian Foster是这样定义云计算的：“云计算是由规模经济拖动，为互联网上的外部用户提供一组抽象的、虚拟化的、动态可扩展的、可管理的计算资源能力、存储能力、平台和服务的一种大规模分布式计算的聚合体”。1从概念上看，云计算实质上是一种分布式计算，云计算的核心思想，是将大量用网络连接的计算资源统一管理和调度，构成一个计算资源池向用户按需服务，提供资源的网络被称为“云”。当云计算系统需要运算和处理大量数据的存储和管理时，云计算系统中就需要配置大量的存储设备，高性能的云存储也就成为了实现云计算服务的基本条件。云存储是指通过集群应用、网格技术或分布式系统等功能，将网络中大量不同类型的存储设备通过应用软件集合起来协同工作，共同对外提供数据存储和业务访问功能。事实上，几乎在所有的基于云计算服务的应用中都需要高性能的云存储来满足数据处理的需求。2. 云计算存储技术 从云计算和云存储的概念中可以看出，云存储实质上是一种分布式存储，因此对于云计算存储技术的研究的核心在于对分布式存储技术的研究。由于云存储底层设备的软硬件环境各不相同，且所处的网络也是一个多变的环境，因此云计算的存储技术除了需要解决基本的海量数据的存储与获取之外，还需要解决负载均衡、提高容错性、动态扩展等许多传统存储系统没有遇到过的挑战。针对上面提到的几点挑战，本文将对现有的技术进行介绍、分析及对比。2.1 提高容错性分布式存储系统（如Amazon Dynamo和GFS）都是应用在实际服务器上的系统，每一次出错都会带来巨大的损失，然而由于分布式系统的运行环境决定了其需要面对巨大的压力。据Google说，其每1000台服务器的集群中，平均每天坏掉一台机器，因此容错性是分布式存储系统在设计时就必须优先考虑的问题。2为了提供较高的容错性，常用的方法主要是冗余存放。具体的做法就是将同一份数据复制为多份（具体的数量是根据不同的应用场景决定），同时存储在多个节点上，这样就可以在某一节点出现故障（临时故障或永久性故障）时，存储在其他节点上的数据备份可以继续提供服务。由之前所述平均每1000台服务器每天会有一台故障，那么其实只需要将同一份数据保存在三台服务器上，那样在同一天三台机器同时出错的概率就降低为10-9，几乎可以视作完全安全了。所以Amazon Dynamo和Google File System都采用了这个策略。在提供了较高的数据可用性的同时，冗余存放还能带来分流数据请求，降低服务器平均负载压力的好处。同一份数据存储在多处地理位置不同、网络情况不同的服务器中，对于处于正常服务状态的数据节点来说，用户在对数据进行读取操作时，距离用户较近并且网络状况较好的服务器节点可以提供更多的服务，同时其他节点可以同时提供数据传输，降低了各自的负载压力，提高了用户获取数据的速度。下面对Amazon Dynamo和Google File System在提高容错性方面的策略（主要是冗余存放）进行具体的分析和比较。2.1.1 Amazon Dynamo冗余存放策略策略定义了N,W,R三个参数，其中N代表系统中每条记录的副本数，W代表每次记录成功写操作需要写入的副本数，R代表每次记录读请求最少需要读取的副本数。只要W+RN 就可以保证数据的一致性，因为W+RN时读写总会有交集必定最少有WRN个读请求会落到被写的副本上，所以必然会读到“最后”被更新的副本数据。至于谁 “最后”的判断需采用时间戳或时钟向量等技术完成，有逻辑关系先后由时钟向量判断，否则简单的用时间戳先后判断。这种做法相比我们最朴素的想法我们直观的想法一定认为如果系统要求记录冗余N 份，那么每次就写入N 份，而在读请求时读取任意一份可用记录即可要更安全，也更灵活。说其更安全是指数据一致性更能被保证：比如说客户写入一条记录，该记录有三个副本在三个不同点上，但是其中一个点临时故障了，因此记录没有被写入或更新。那么在对该记录再读取时，如果取两点（R=2 ）则必然会读取到最少一个正确的值（临时故障点有可能在读是恢复，那么读出的值则不存在或者不是最新的；若临时故障点还未恢复，则读请求无法访问其上副本）。而使用我们传统方法可能读到发生临时故障的那点，此刻就有可能读出现错误记录（旧的或者不存在），因此可以看到加大W,R 可提高系统安全性；说其更灵活则是指可通过配置N,W,R 这几个参数以满足包括访问方式、速度和数据安全等迥异需求的各种场景：比如对于写多读少的操作，可将W 配低，R 配高；对于写少读多的操作，则可将W 配高，R 配低。Dynamo对于临时故障的处理方式是：找到一台可用机器，将数据暂时写到其上的临时表中，待临时故障恢复后，临时表中的数据会自动写回原目的地。这样做得目的是达到永远可写，即使该云中只有一台机器可用，那么写请求的数据就不会丢失。2.1.2 Google File System冗余存放策略该策略主要通过GFS来实现数据的冗余存储。GFS将整个系统的节点分为三种： Master、ChunkServer和Client。GFS中的文件被分成大小固定的数据块，并由Master节点在创建时分配一个64位全局唯一的数据块句柄。数据块被ChunkServer以普通Linux文件的形式存储在磁盘中。为了保证数据的可用性，数据块默认保存三份。Master节点中则维护着系统的元数据（文件及数据块名字节点、GFS文件到数据块之间的映射和数据块位置信息等），同时也负责GFS的全局控制（数据块租约管理、垃圾数据块回收、数据块复制等）。Master节点定期与ChunkServer通过心跳的方式交换信息，获得节点的活动状态。Client是GFS提供给应用程序的访问接口，它是一组专用接口，不遵守POSIX规范，以库文件的形式提供。Client访问GFS时，首先访问Master节点，获取与之进行交互的ChunkServer信息，然后直接访问这些ChunkServer，完成数据存取工作。需要注意的是，GFS中的客户端不缓存文件数据，只缓存Master中获取的元数据，这是由GFS的应用特点决定的。GFS最主要的应用有两个：MapReduce与Bigtable。对于MapReduce，GFS客户端使用方式为顺序读写，没有缓存文件数据的必要；而Bigtable作为云表格系统，内部实现了一套缓存机制。另外，如何维护客户端缓存与实际数据之间的一致性是一个极其复杂的问题。2.2 动态扩展分布式存储系统的另外一项重要特性就是动态扩展，所谓动态扩展就是在不改变当前分布式存储系统的运行状态下实现系统的升级和维护，主要是针对节点的增加和删除。3本小节将分析GFS的动态扩展机制。GFS主要采用了Master节点通过心跳的方式和ChunkServer交换信息，从而获得节点的状态信息。在Master服务器启动的时候，或者新的ChunkServer加入到集群中时，Master节点会向各个ChunkServer轮询它们所存储的数据块的信息，通过这样的方式来支持动态节点加入。master对每个chunkserver维护一个 hb_sequence，表示master最近给chunkserver发送心跳的时间点(单位为秒)， master会把这个值写入向chunkserver发送的心跳请求中；同时维护一个hb_res_sequence，表示最后收到chunkserver心跳请求的时间点， chunkserver的心跳请求中包含hb_res_sequence，每次收到chunkserver的心跳请求更新该值。如果hb_sequence-hb_res_sequence大于某个给定的值，则认为该chunkserver已经下线。在ChunkServer端，当其收到Master的心跳之后得到本次请求的hb_sequence，然后ChunkServer更新全局的g_hb_sequence，同时向Master发起心跳请求，请求中包含hb_sequence。 同时ChunkServer存在一个定时器线程定期检查本地时间和g_hb_sequence的差值， 如果发现长时间没有收到Master的心跳请求，ChunkServer就杀死自己， 因为他认为在这么长的时间内没有收到Master的心跳，那么Master肯定已经认为自己死掉了， 所以就把自己杀死。2.3 负载均衡随着现有网络各种业务量的不断增多，访问量和数据流量的快速增长，其处理能力和计算强度也相应地增大，使得单一的服务器设备根本无法承担。负载均衡（Load Balance）就是通过在分布式的系统上，将负载分配到多个操作节点上运行，并在每个节点的负载处理完成之后，将结果汇总并返回给用户。通过负载均衡，分布式系统的负载承受能力得到了大幅度提升。这样做的另外一个好处是，大量并发访问被分摊到多个节点处理可以大大降低用户等待的时间。分布式存储系统在负载均衡方面都有着自己的核心技术，本节主要介绍Hadoop和GFS的负载均衡机制。2.3.1 Hadoop中的负载均衡在hadoop的HDFS中设计有自动负载工具来进行负载均衡。其中，ReplicationTargetChooser类专门负责为新生成的数据块寻找存储节点，即主要管理新数据块的备份数量、申请的客户端地址及已经注册的数据服务器位置，其算法基本思路是只考虑静态位置信息，优先照顾写入者的速度，让多份备份分配到不同的节点中去。4Balancer类则负责动态负载的调整和均衡，是Tool类的派生类，以可配置的独立进程的形式运行。它运行有NamenodeProtocol 和ClientProtocol 两 个协议，与主控服务器进行通信，获取各个数据服务器的负载状况，从而进行调整，即将一个数据块从一个服务器迁移到另一台服务器中。5Balancer向目标数据服务器发送DataTransferProtocol.OP_REPLACE_BLOCK消息，随后该服务器会写入该数据块，写入成功之后原服务器会将该数据块删除。可以通过配置Balancer的负载差距阈值，Balancer会根据配置来平衡负载。2.3.2 GFS中的负载均衡在GFS中，负载均衡是在数据块的创建和重新复制之后进行的。首先Master服务器创建一个数据块，决策把初始的空副本放在那里主要有几个因素。首先副本应尽量放置在平均硬盘使用率低于平均值的ChunkServer上，以便平衡ChunkServer之间的硬盘使用率，其次应该尽量限制ChunkServer上的近期创建操作数，因为虽然创建本身是廉价的，但是它会紧跟这沉重的写操作，因为写入者需要写的时候才会进行创建，而在我们的追加一次或多次的工作负载下块一旦被成功写入就会变为只读。第三应该尽量将数据库分散在不同的节点中。一旦数据块的可用副本数少于用户指定的数目，服务器就会重新复制它。这种情况的产生主要原因有：某个ChunkServer上的副本损坏、磁盘故障导致不可用或者用户提高了副本数目的配置。需要被重新复制的数据块会基于几个因素排序，一是数据块离它的副本数量目标的差距，差距越大的数据块优先级越高，二是，活着的文件的优先级会高于近期删除的文件块，最后，为了失效对正在运行的应用程序的影响，我们提高阻塞客户机流程的块的优先级。Master节点会选择优先级最高的块，然后通知其他ChunkServer直接从源数据块拷贝到本地来实现数据块的复制。在创建和重新复制之后，Master节点会周期性对副本进行负载均衡，它先检查当前副本的分布情况，然后移动副本来均衡负载和磁盘的剩余空间。另外，Master节点必须选择哪些现有的副本要被移走。一般来说，它移动那些剩余空间低于平均值的块服务器上面的副本，这样就可以平衡硬盘使用率。3. 总结 云存储系统随着云计算的蓬勃发展，越来越多的得到应用，常见的云存储系统（主要是GFS、Hadoop、Dynamo等）在处理分布式数据存储的时候都有着各自的优点缺点，现在各个公司也都在基于开源或者商用的代码并针对自身的需求进行开发。相信随着更多的推广和应用，云存储系统也会遇到更多新的问题，本综述仅针对云存