分布式文件系统中元数据管理策略的研究-软件工程专业论文.docxVIP

华中科技大学硕士学位论文 华 中 科 技 大 学 硕 士 学 位 论 文 PAGE 10 PAGE 10 1 绪论 1.1 研究背景 近些年来，分布式文件系统逐渐成为大规模数据存储的首要选择。在分布式存 储架构中，为了提高系统性能，更有效地管理元数据和文件数据，通常把元数据的 处理和文件数据的访问分离开来[1]，由元数据服务器（MDS）管理文件系统命名空 间和文件各种属性，并负责与客户端交互，提供文件访问权限和文件存储位置等信 息，同时由存储服务器负责存储文件，并直接处理客户端对文件数据的各种读写请 求。这样分离之后，就可以利用分布式文件系统的访问特性，具体针对系统瓶颈进 行优化，而最近的研究显示，文件系统中 50%-80%的访问操作对象都是元数据[2]， 而不是占据整个文件系统绝大部分大小的文件数据，因此，元数据的管理策略对于 系统性能具有至关重要的影响。 目前，主流的分布式文件系统都能很高效地管理百万级别的文件数据，但是随 着数据敏感的科学计算和云计算的逐渐升温，越来越多的文件和数据需要进行存储， 数据规模急剧膨胀，由此就为分布式存储带来更多的挑战。而元数据管理作为系统 核心组成部分，也面临着以下三种主要挑战。 （1）当目录规模扩展到数十亿文件时，仍要能有效维护此类目录。当下比较流 行的网络服务已经需要管理数十亿个文件，例如 Facebook 和 Flickr 等网站，目前用 户文件总量已超过百亿，且仍以每天大约数百万的速度在增长[3]；同样的，科学计算 程序对文件系统存储规模也提出越来越高的要求，如地理信息系统就要管理数十亿 卫星照片，并且随着卫星技术发展，以后还需要管理更多、更精确的照片。基于这 种趋势，将来分布式文件系统就要管理规模更为庞大的文件，相应的目录平均规模 也会达到数十亿文件大小。而如果元数据组织不具有良好的可伸缩性，那么就会直 接导致目录管理效率低下，进而降低系统整体性能。 （2）当分布式文件系统规模达到万亿文件时，仍要能提供高性能的元数据处理。 系统规模急剧膨胀，意味着对系统的访问请求也会随之迅速增加，如 Facebook 每秒 钟大约需要处理 55 万张照片访问请求，Flickr 也同样需要每秒钟支持 38 万张照片处 理请求；而在科学计算领域，千万亿次大型机每次需要同时打开数以千计的文件， 并且这个数字还在不断增长[4]。因此，对将来的元数据管理来说，支持每秒钟数万个 元数据处理操作至关重要，但遗憾的是，现有分布式文件系统的同步机制极大限制 了元数据修改操作的并发性，这也造成了元数据管理的性能低下。 （3）有效平衡 MDS 机群的工作负载。对系统的大规模并发访问会造成两个连 续的问题：元数据缓存（Cache）的低使用率和 MDS 机群之间的负载不均衡。当规 模庞大的用户同时访问系统时，对于每个 MDS 来说元数据请求都是随机的，这种缺 乏局部性的访问会导致元数据缓存的低命中率，进而使得缓存中的元数据需要频繁 替换；更糟糕的是，随机访问同时会造成 MDS 机群的工作负载不均衡，有的 MDS 需要处理的请求多，而有的 MDS 需要处理的请求少，那些超负载的 MDS 就成为了 系统的瓶颈。 如果能够针对各种挑战都能提出应对的解决方法，并应用到元数据管理策略中， 那么分布式文件系统的性能和可扩展性都会有很大的提高。 1.2 国内外研究现状 1.2.1 元数据管理系统架构发展 在传统的文件系统中，元数据和文件数据保存在一个共同的计算机上，并由同 一个文件系统管理。设计者通过优化元数据和目录的数据结构以及对应的管理策略， 文件系统能高效地管理 GB 规模的文件。 而随着数据规模的激增，单一节点的存储能力已经不能满足各种应用需求，且 传统的文件系统在管理规模更大的文件时效率低下，此时分布式存储和分布式文件 系统就随之产生[5]。在这种架构下，元数据单独由 MDS 服务器管理，文件数据由另 外的存储器管理，两种数据之间通过网络相互交互，使得用户能够独立直接两种访 问服务器。其中，MDS 服务器可以单独由一台计算机来承担所有元数据访问相关的 工作负载，也可以由多台计算机共同组成一个服务器机群来完成所有的工作负载， 具体的系统可根据现实需求进行不同的部署。在这种架构对应的分布式文件系统中， Google File System（GFS）[6]和 Hadoop File System（HDFS）是最著名的，且原理大 概相同。GFS 和 HDFS 中只有一个 MDS 服务器，它负责存储完整的命名空间以及所 有文件和目录的各种属性，并与存储文件的服务器机群定时交互，以高效管理系统 中的所有文件，同时它还负责与客户端交互，根据请求操作的类型提供文件的属性， 如文件修改时间和文件大小等信息。 在实际使用过程中，大规模