一种无中心的云存储架构分析

余秦勇，陈 林，童 斌

（成都卫士通信息产业股份有限公司，四川 成都 610041）

0 引言

云存储是从云计算概念上衍生、发展出来的一个概念，指利用集群、分布式文件系统等技术，将网络中大量各种不同类型的存储设备集合起来协同工作，共同对外提供数据存储和业务访问功能的一个系统。云存储作为云计算系统的基础和支撑，专注于解决云计算中海量数据的存储挑战，所以云存储是一个以数据存储和管理为核心的云计算系统。与传统的存储系统相比，云存储系统具有以下优点。

高可靠性。云存储使用了数据多副本容错、存储节点异构可互换等措施来提升系统的可靠性，因此云存储能够容忍节点的故障，甚至有很大一部节点失效也不会影响系统的正常运行，较好的解决了硬件故障的影响，提高了可靠性。

高扩展性。云存储技术通过将不同厂商、型号、位置的存储设备抽象成一个虚拟的存储资源池，资源池的规模可以动态伸缩，满足应用和用户规模增长的需要，使之具有高可扩展性。高扩展的特性使云存储能够适用于海量数据存储。

高可用性。传统的存储系统在做定期性的维护和升级时，通常会导致服务的临时中断。而云存储通过虚拟化资源池技术，能实现系统不停机的情况下数据动态迁移，因此使用云存储不会导致业务的中止，具有高可用性。

低成本。云存储对大量价格低廉的同构或者异构存储设备进行了有效整合，降低了系统的构建成本；云存储的通用性使资源的利用率大幅提升，缓解了成本与资源利用率之间的矛盾，降低了运行成本。

综上所述，云存储除了可以节省整体的硬件成本外，还具备良好的可扩展性、对用户的透明性、按需分配的灵活性和负载的均衡性等特点，云存储系统为海量数据的存储提供了有效的解决方案[1-2]。

1 典型云存储架构介绍

云存储作为一个复杂的综合系统，其核心在于内置的分布式文件系统，它是云存储的基础。所谓分布式文件系统是指文件系统管理的物理存储资源不局限在本地节点上，而是通过网络与节点相连，然后把整个分布式存储资源以统一的视图呈现给用户。目前已有大量的分布式文件系统，有些是商业化产品，有些是开源项目，每种分布式文件系统各有其特点和适用场景，以是否存在元数据节点可以将其分为两类：基于中心的分布式文件系统和无中心的分布式文件系统，它们决定了云存储系统的架构。其中GFS（Google File System）是前一种类型的代表，HDFS是其开源实现；Dynamo是Amazon设计开发的存储基础架构 ，是无中心云存储架构的典型，下面分别对其做概要介绍。

1.1 GFS架构介绍

GFS是Google公司为了满足迅速增长的数据处理要求，设计并实现的分布式文件系统,。GFS分布式文件系统主要有 3个组件：Master、Chunkserver和GFS Client[3]，如图1所示。

图1 GFS体系结构

Master管理所有的文件系统元数据。这些元数据包括名字空间、访问控制信息、文件和Chunk的映射信息、以及当前Chunk的位置等信息。

Chunkserver负责具体数据的存储，GFS存储的文件都被分割成固定大小的Chunk。在Chunk创建的时候，Master节点会给每个Chunk分配一个不变的、唯一的64位的Chunk标识。Chunk节点把Chunk以文件的形式保存在本地硬盘上，并且根据指定的Chunk标识和字节范围来读写块数据。出于可靠性的考虑，每个块都会复制到多个块服务器上。

GFS的客户端以代码库的形式被链接到客户程序里。客户端代码提供了一套类似传统文件系统的API接口函数，支持常用的文件操作，如创建新文件、删除文件、打开文件、关闭文件、读和写文件。

为了提高系统效率，GFS采取了把数据流和控制流分开的运行机制。Master和 Client及Chunkserver节点的通信只交互控制流（元数据信息），所有的数据操作都是由客户端直接和 Chunk节点进行交互的。

GFS文件系统具有几个特点：①系统定位于存储大量的大文件，系统也支持小文件，但未针对小文件做专门的优化；②大部分文件的更新是通过添加新数据完成的，而不是改变己存在的数据，一旦写完，文件就只可读；③系统工作主要由两种读操作构成。对大量数据的流方式的读操作和对少量数据的随机方式的读操作。

由以上分析可以看出，GFS并不是一个通用的云存储系统，它更适合于大型的搜索业务，因为GFS的设计考虑了许多具体搜索业务的特性，如文件的大小、读写频率等。GFS采用中心节点来管理整个文件系统的元数据，这可以大大简化设计，从而降低实现难度。但是，这样的结构也带来了单点失效和性能瓶颈的问题，而这也将在一定程度上影响系统的扩展性。

1.2 Dynamo架构介绍

Dynamo是Amazon设计、开发的一种基础存储架构。由于业务的快速发展，传统的存储系统无法满足电子商务交易过程中产生的海量、半结构化数据的需求，因此 Amazon设计开发了自己的存储系统Dynamo。Dynamo在设计之初被定位为一个高可靠、高可用且具有良好容错性的系统，它以简单的键/值方式存储数据，不支持复杂的查询，Dynamo中存储的是数据的原始形式，不识别任何数据结构，这使得它几乎可以处理所有的数据类型。

相比传统的集中式存储系统，Dynamo是一个完全分布式的、无中心节点的存储系统。如何在节点上均匀分布数据是非常关键的问题，Dynamo使用改进后的一致性哈希算法解决这个问题，如图2所示。一致性哈希算法分两步进行，首先计算出设备节点哈希值，将设备配置到环上的一个点（每个点代表一个哈希值）；然后计算数据的哈希值，按顺时针方向将其映射到环上距其最近的节点；当新增节点时，按照上述规则，调整相关数据到新的节点上。删除节点和添加节点过程相反[4]。

Dynamo通过一致性哈希算法切分数据，分放在不同的节点上。环上每个节点只需要处理落在它和它的前驱节点之间的数据，这样当有新的节点加入或者撤出时系统的震荡较小。一致性哈希是一种随机函数，在节点量较少的情况下很有可能造成节点数据分布的不均匀，并且一致性哈希算法在选择节点位置时并没有考虑环上不同节点的性能差异。为了解决这个问题，亚马逊在Dynamo中引入了节点虚拟化的概念。每个虚拟节点属于一个实际的物理节点。一个物理节点根据性能的差异可能拥有一个或多个虚拟节点。每个虚拟节点能力基本相当，并随机分布在哈希空间中。存储时，数据按照哈希值映射到某个虚拟节点负责的区域，然后被存储在该虚拟节点所对应的物理节点。分布在一致性环上的虚拟节点有效的解决了性能不均问题，它将放在环上作为一个节点的视为一组机器，这一组机器是通过同步机制保证数据一致的。

图2 一致性哈希算法

2 Gluster架构分析

Gluster是一个开源的无元数据节点的分布式文件系统，由于其无中心的特点，因此具有强大的横向扩展能力，通过扩展能够支持数 PB存储容量。Gluster通过TCP/IP或InfiniBand RDMA网络将物理分布的存储资源聚集在一起，使用单一全局命名空间来管理数据。Gluster基于可堆叠的用户空间设计，可为各种不同的数据负载提供优异的性能[5]。

2.1 总体架构

Gluster主要由存储服务器（Brick Server）、客户端以及存储网关组成，如图3所示。由图3可以看出，Gluster架构中没有元数据节点，这是其最大的设计特点，对于提升整个系统的性能、可靠性和稳定性都有着决定性的意义。客户端可通过原生Gluster协议访问数据，对于不支持运行Gluster客户端（如Windows系统）的节点可采用NFS/CIFS标准协议通过存储网关访问存储系统[6]。

图3 Gluster架构

存储服务器主要提供基本的数据存储功能，数据通过弹性哈希算法分布在不同的存储服务器上。存储服务器运行Gluster的后台服务进程，负责处理来自客户端的数据服务请求。数据以原始格式直接存储在服务器的本地文件系统上，如EXT3、EXT4、XFS、ZFS等，运行服务时指定数据存储路径。

在客户端方面，由于没有元数据服务器，客户端需要实现数据卷管理、I/O调度、文件定位、数据缓存等功能。客户端利用FUSE（File system in User Space）模块将 Gluster挂载到本地文件系统之上，以POSIX兼容的方式来访问系统数据。Gluster客户端的负载相对传统分布式文件系统要高，包括CPU占用率和内存占用。

Gluster存储网关提供弹性卷管理和 NFS/CIFS访问代理功能。卷管理器负责逻辑卷的创建、删除、容量扩展与缩减、容量平滑等功能，并负责向客户端提供逻辑卷信息及主动更新通知功能等。对于Windows客户端或没有安装Gluster的客户端，需要通过 NFS/CIFS代理网关来访问，这时网关被配置成NFS或Samba服务器。

2.2 弹性哈希算法

对于基于中心的分布式系统而言，元数据处理是决定系统扩展性、性能以及稳定性的关键。大多数传统分布式存储系统通过使用一个中央元数据服务器来解决这个问题。它是一个集中的服务器，里面包含的所有文件的名称和相关的物理位置，但这样系统可能有两方面的问题。

1）性能瓶颈：元数据服务器成为性能瓶颈。数据在任意时间被以任何方式被存取时，元数据都必须同步更新记录信息。由于文件和文件操作的增加，集中式的元数据系统可能成为性能瓶颈。

2）单点故障：这可能是一个更为严重的问题，即集中式元数据服务器成为单点故障。如果元数据服务器离线或被破坏，所有操作基本上就会停止。

另一种方法是放弃集中元数据服务器，而采用分布式元数据的方法，即引入多个元数据服务器，形成一个元数据服务器集群。这种方法虽然克服了集中式元数据存储的缺点，但它又引入了新的性能和可用性问题。因为元数据服务器之间通过使用各种锁和同步机制来保持数据同步时，带来了大量的性能开销，还面临着元数据未能正确保持同步或被损坏时，导致多个实例之间不再完全一致的风险情况。

因为将元数据和数据分离的存储系统都面临着性能和可靠性问题，Gluster另辟蹊径，不再将元数据从数据中分离，而通过弹性哈希算法寻址数据，它是Gluster许多独特的优势的关键。Gluster中数据访问流程如下：

1）以文件路径和文件名作为输入参数，计算Hash值。

2）根据Hash值在集群中选择子卷（存储服务器），进行文件定位。

3）对所选择的子卷进行数据访问。

通过使用弹性哈希算法，使得Gluster的每次文件存取操作更快和更可靠，因为使用算法计算元数据在速度上超过任何从存储介质检索元数据的速度，也不存在对任何单一的元数据存储节点的访问瓶颈了，因为每个节点都是独立的，无需同步元数据，实现了真正的分布式部署的线性扩展。

Gluster的弹性哈希算法的采用的是 Davies-Meyer算法，将一个给定的路径/文件名作为算法的输入，然后得到唯一的定长输出值。Davies-Meyer算法具有良好的平均分布特性，计算效率很高。假设逻辑卷中的存储节点有N个，则输出值的整数空间被平均划分为N个连续子空间，每个空间分别映射到一个存储节点。这样，计算得到的Hash值就会被投射到一个存储节点，即选择的子卷。

然而在具体产品实现中需要考虑到现实中可能发生的各种情况，比如磁盘故障、容量耗尽、文件需要重新分配等，所以弹性哈希算法还需要适应添加或删除物理磁盘、个别磁盘访问频率过高等问题，从而使系统具备弹性线性扩展的特点。Gluster通过以下方法来解决：

1）设置了一个非常大数目的虚拟卷。

2）使用哈希算法分配文件给虚拟卷。

3）使用一个单独的进程来分配虚拟卷到多个物理设备。

因此，添加或删除磁盘或节点时，算法本身并不需要改变，只是将虚拟卷重新迁移或分配到新的物理卷。这样负载波动或性能调优时，存储服务器可以动态添加或删除，数据自动在整个存储系统的服务器中重新平衡[7]。

如果文件重命名或移动文件，弹性哈希算法显然会计算出一个不同的值，这会导致文件被定位到一个不同的逻辑卷。因为文件可能很大，改写并移动文件通常不是一个实时操作。为解决这个问题，在文件被重新命名时，Gluster会创建一个指向原逻辑卷的指针。用户通过新文件名计算出逻辑卷位置时，系统会通过指针将文件重定向到以前逻辑卷的位置。在后台进程完成文件的迁移后，指针被移除。类似地，如果文件需要移动或重新分配（例如，如果磁盘因为访问频率过高或性能在下降），前台实时发布迁移操作指令，物理数据迁移置于后台选择适当时机执行。

2.3 系统特点

（1）弹性存储

弹性存储的概念，是指能够灵活地适应数据的增长（或减少），在不中断系统的情况下按需对存储池中的资源做添加或删除。Gluster设计目标之一就是弹性，它允许动态增删数据卷、扩展或缩减数据卷、增删存储服务器等，而不影响任何正在运行的业务。最新Gluster版本已具有良好的弹性，能够满足对存储系统弹性要求高的应用需求，尤其是对云存储服务系统。

（2）线性横向扩展

存储系统的扩展能力分为纵向扩展（Scale-Up）和横向扩展（Scale-Out）。纵向扩展指提高单个节点的存储容量或性能，但存在理论上或物理上的各种限制，不能无限制的增长。横向扩展指通过增加存储节点来提升整个系统的容量或性能，这是最主要的存储扩展机制，目前大多分布式文件系统都具备横向扩展能力[8-10]。

但要真正实现线性扩展对于存储系统而言是非常困难的，通常系统规模扩展与性能提升之间是LOG对数曲线关系，因为规模的扩展同时会产生开销而消耗了部分性能的提升。Gluster是真正线性横向扩展架构，它通过横向扩展存储节点即可以获得线性的存储容量和性能的提升。Gluster利用3种基本技术来获得线性横向扩展能力：①消除元数据节点；②高效数据分布，获得扩展性和可靠性；③通过完全分布式架构的并行化获得性能的最大化。

Gluster通过综合纵向扩展和横向扩展技术，获得了多维扩展能力，能够将更多磁盘、内存、I/O资源聚集成更大容量、更高性能的虚拟存储池。

3 结语

通过先进的架构设计，Gluster在大幅降低构建和维护成本的基础上，能够提供具有高扩展性、高性能、高可用性的弹性存储系统。通过使用弹性的哈希算法完全消除元数据的特点，使Gluster的具有突出的适应能力，这极大地降低了数据丢失、损坏或变得不可用的风险。

目前，Gluster正处于快速发展的过程中，无中心的架构使它具有天然的独特优势，现在已有基于它推出商业化的存储系统，因此Gluster是一个有着广阔前景的集群文件系统，特别适合于构建云存储系统。

[1] 王会波.安全存储与存储安全[J].信息安全与通信保密,2012(12):18-19.

[2] 侯建,帅仁俊,侯文.基于云计算的海量数据存储模型[J].通信技术,2011,44(05):163-165.

[3] GHEMAWAT S,GOBIOFF H,LEUNG S-T.The Google File System[C]//Proceedings of the 19th ACM Symposium on Operating Systems Principles. New York:ACM Press,2003:29-43.

[4] DECANDIA G,HASTORUN D,JAMPANI M,et al.Dynamo:Amazon's Highly Available Key-value Store[C]//SOSP'07:Proceedings of the 21st ACM Symposium on Operating Systems Principles.New York: ACM,2007:205-220.

[5] Gluster Community,Introduction_to_Gluster.pdf[EB/OL].(2012-04-13)[2010-10-15].http://download.gluster.com/pub/gluster/documentation/Introduct ion_to_Gluster.pdf.

[6] Gluster Community,Gluster Documentation[EB/OL].（2012-04-18）[2011-08-10].http://www.gluster.org/community/documentation/index.php/Gluster_3.1.x_Documentation.

[7] Gluster Community,Gluster_Architecture[EB/OL].（2012-04-18）[2010-10-15].http://download.gluster.com/pub/gluster/documentation/Gluster_Architecture.pdf.

[8] Gluster Community, An Introduction to Gluster Architecture[EB/OL].（2012-04-22）[2011-08-10].https://confluence.oceanobservatories.org/download/attachments/30998760/An_Introduction_To_Gluster_ArchitectureV7_110708.pdf?version=1&modificationDate=1322845342000.

[9] 张秋江,王澎.云计算的安全问题探讨[J]. 信息安全与通信保密,2011(05):94-95.

[10] 项力,吴学智,王斌.基于云计算的下一代数据中心设计[J].通信技术,2012,45(06):107-109,112.