第十章分布式件系统名字空间实现研究.docxVIP

第十章、分布式文件系统名字空间实现研究1、空间概述名字空间(Namespace)即文件系统文件目录的组织方式，是文件系统的重要组成部分，为用户提供可视化的、可理解的文件系统视图，从而解决或降低人类与计算机之间在数据存储上的语义间隔。目前树状结构的文件系统组织方式与现实世界的组织结构最为相似，被人们所广泛接受。因此绝大多数的文件系统皆以Tree方式来组织文件目录，包括各种磁盘文件系统(EXTx, XFS, JFS, Reiserfs, ZFS, Btrfs, NTFS, FAT32等)、网络文件系统(NFS, AFS, CIFS/SMB等)、集群文件系统(Lustre, PNFS, PVFS, GPFS, PanFS等)、分布式文件系统(GoogleFS, HDFS, MFS, KFS, TaobaoFS, FastDFS等)。随着面向对象存储和云存储的发展，出现了一种称为偏平化(Flat)的文件系统组织方式，典型代表有Lustre, PanFS, Amazon S3, Google Storage。这种方式把所有文件目录看作对象Object，每一个对象有一个全局唯一的标识UUID，户使用此UUID(而非路径)来访问存储系统。然而，UUID仅仅对计算机有意义，在用户接口层往往还是需要提供树状文件系统视图，再由系统在Path和UUID之间进行转换。在对象存储层，对象或对象数据分片以文件形式存储在磁盘文件系统之上，物理存储层仍然是树状存储结构。另外，对于法规遵从数据存储领域广泛使用的固定内容存储系统CAS(Content addressed storage, 内容寻址存储)，采用基于对象的存储系统，机制与此类似。具体实现上，磁盘文件系统的名字空间直接在磁盘上来实现，通常以B*/B+/B-树的形式来组织，元数据和数据存储在相同的介质上。而对于分布式文件系统来说，元数据和数据和存储和访问是分离的，这是由高性能、可用性、可扩展性等设计要求所决定的。通常，数据的存取由I/O服务器来实现，而元数据由元数据服务器来负责。名字空间是元数据服务器的核心任务之一，此外可能还要负责安全机制(如授权与认证)、锁机制、I/O负载均衡等。因此，由于元数据与数据的分离，分布式文件系统名字空间实现的自由度比较大，实现方式有更多的选择空间。这里将要介绍四种分布式文件系统名字空间实现机制，均为树状文件系统视图，大致分为基于文件系统的实现和基于全内存的实现，但不包括基于数据库的实现。基于数据库来实现文件系统名字间有众所周知的性能问题，尤其是递归遍历文件目录空间。2、文件系统名字空间实现(1)基于文件系统的设计这是一种站在巨人肩膀上的设计。磁盘文件系统本身就是树状结构视图，因此可以利用这现成的机制在元数据服务器上实现名字空间。对于分布式文件系统中的每一个目录或文件，在元数据服务器的本地文件系统之上一一对应创建一个目录或文件(以下称为元目录和元文件)，两者之间的映射关系如图1所示。元目录用来表示DFS中的目录，其元目录属性保存DFS目录属性；元文件用来表示DFS中的文件，元文件属性保存DFS文件属性，元文件内容则用来保存元数据，包括更详细的文件属性、访问控制信息、数据分片信息、数据存储位置等信息。图1 基于文件系统的设计(DFS与本地文件系统名字映射)基于文件系统我们以极小的代价构建了DFS的名字空间，实现起来简单快速。元文件仅用来存储数据文件的元数据，一般都是小于1KB的小文件，如果文件目录数量达到千万量级就会形成LOSF(Lots of small files)的性能问题。实际应用中如何来解决这种问题呢？目前主要有两种解决方法，一是采用适合海量小文件存储的文件系统。Reiserfs对小文件存储进行了特别优化，它不仅文件查找效率高，而且节省磁盘存储空间，实际测试结果也验证了这一点。二是采用高性能的存储介质，尤其是IOPS指标。非常幸运，固态硬盘SSD技术上已经比较成熟，成本不断降低，非常适合高性能的存储应用。SSD的特点是IOPS高，普通SSD读写IPOS可以达到10000 ~ 50000，高端SSD甚至可以达到100000以上，而FC、SAS、SATA磁盘的IPOS基本小于300，远远小于SSD。因此，采用SSD和Reiserfs文件系统，性能能够得到大幅提升，大多数应用问题不大。　　(2)基于全内存的分层设计这种方式与HDFS实现相仿。与基于文件系统的实现不同，名字空间完全在元数据服务器的内存中，使用层次结构来表示，如图2所示。这种层次结构相当于一棵树，每个结点表示DFS的一个目录或文件，结点的孩子结点理论上没有数量限制(取决于内存可用量)，孩子结点使用动态数组来表示。结点数据结构如下所示，其中metadata表示(1)中文件目录类似的元数据信息，children是