分布式文件系统的实现原理和优化技术

3.2.3.1 分布式文件系统简介

1)分布式文件系统特性

根据CAP(consistency,availability,tolerance to network partitions)理论,在分布式系统中,一致性、可用性、容错性三者不可兼得,追求其中两个目标必将损害另外一个目标。并行数据库系统追求高度的一致性和容错性(通过分布式事务、分布式锁等机制),无法获得良好的扩展性和系统可用性,而系统的扩展性是大数据分析的重要前提。

分布式文件系统向客户端提供了一种永久的存储器,在分布式文件系统中一组对象从创建到删除的整个过程完全不受文件系统故障的影响。这个永久的存储器由一些存储资源联合组成,客户端可以在存储器上创建、删除、读和写文件。分布式文件系统与本地文件系统不同,它的存储资源和客户端分散在一个网络中。文件通过层级结构和统一的视图在用户之间相互共享,虽然文件存储在不同的存储资源上,但用户就像是将不同文件存储在同一个位置。分布式文件系统应当具有透明性、容错性和伸缩性。

(1)透明性。对用户来说,分布式文件系统应表现为常规的集中式文件系统,即服务和存储器的多重性和分散性对用户应该是透明的;透明性的另一个方面是用户的可移动性,即用户可以在系统中的任何机器上登录。分布式文件系统的透明性一般包括以下几个方面:①名字透明性,名字的含义不依赖于系统中的场点,用户仅依据名字就可以存取相关的资源;②位置透明性,资源的名字独立于该资源位置,一个资源可以从一个场点迁移到另一个场点而不必改变其名字;③程序执行的透明性,在响应一个用户提供的某个执行程序时,可以在系统内任何可用的处理机上调度所指程序的执行,并对用户保持这种透明性;④复制透明性,系统对用户提供资源的副本;⑤存取透明性,存取资源与该资源的位置无关,存取透明性不仅保证一个进程可以从一台处理机迁移到另一台处理机上运行,而且还可以实现将一个任务分配后,使其各子任务在不同的处理机上并发执行;⑥性能透明性,主要是指系统使访问远程资源与访问本地资源所需的开销之差小到可以忽略的程度;⑦故障透明性,系统对进程或者用户隐藏故障,而用户可以通过系统性能的衰减而察觉系统的故障点。

(2)容错性。容错性是指在发生各种故障时分布式文件系统应该能够正常工作,尽管其性能可能有所降低。分布式文件系统的容错性与其可用性、可靠性、安全性和可维护性息息相关。可用性指系统可以工作,可靠性指系统可以无故障地持续工作,安全性指系统在偶然发现故障的情况下可以正确操作而不会造成任何灾难,可维护性指系统发生故障后恢复的难易程度。

引起分布式文件系统的故障可分为暂时的、间歇的和持久的。分布式文件系统根据不同的故障类型,可使用冗余掩盖故障、进程容错、可靠的点对点通信容错和可靠的组通信容错等方案实现系统的容错功能。

(3)伸缩性。分布式文件系统通过简单配置即可实现文件存储空间的扩展,同时可通过扩展名称服务器集群来提高名称服务器的并发性能,并可通过增加副本文件来实现存储服务器的I/O吞吐量扩展。分布式文件系统的扩展性架构可分为Client-Server和Cluster-Based两类。

Client-Server架构:多个服务器管理、存储和共享元数据和信息数据,并且分布式文件系统向多客户端之间的数据提供一个全局的命名空间。Cluster-Based架构:元数据和信息数据是解耦模式,一个或者多个服务器用于管理元数据,剩余服务器用于存储数据,如果系统只有一个元数据服务器则称为集中式,系统具有多个分布式的元数据服务器被称为完全分布式。

2)分布式文件系统结构

图3-8所示是一种比较典型的分布式文件系统架构,主要包括主控服务器、多个数据服务器以及多个客户端,客户端可以是各种应用服务器,也可以是终端用户。

图3-8 分布式文件系统典型架构

(1)主控服务器。也称元数据服务器、名字服务器等,通常会配置备用主控服务器以便在故障时接管服务,也可以两个都为主的模式。其功能主要是管理命名空间的维护、数据服务器管理、服务调度等。

(2)数据服务器。也称存储服务器、存储节点等,其功能主要包括数据本地存储、本地服务器的状态维护以及数据的副本管理。

(3)客户端。客户端可以是各种应用服务器,也可以是终端用户。用户可以通过文件系统提供的接口来存取数据。但是,在对分布式文件系统的文件进行存取时,要求客户端先连接Master获取一些用于文件访问的元信息,这一过程不仅加重了Master的负担,也增加了客户端请求的响应延迟,因此为了加速该过程,同时减轻Master的负担,系统将元信息进行缓存,数据可根据业务特性缓存在本地内存或磁盘,也可缓存在远端的高速缓存系统上。另外,客户端还可以根据需要支持一些扩展特性,如将数据进行加密保证数据的安全性,将数据进行压缩后存储降低存储空间使用,或是在接口中封装一些访问统计行为,以支持系统对应用的行为进行监控和统计。

基于上述架构,分布式文件系统可以处理超大文件,并可运行在廉价的机器集群上。但是并不适合低延迟数据访问,而且无法高效地存储大量的小文件。

3)分布式文件系统发展过程

本地文件系统只能通过I/O总线访问主机磁盘上的数据。当局域网出现后,主机间通过网络互连起来。但是如果每台主机上都保存一份大家都需要的文件,既浪费存储资料,又不容易保持各份文件的一致性。于是提出文件共享的需求,即一台主机需要访问其他主机的磁盘,这直接导致分布式文件系统的诞生。最初的分布式文件系统应用发生在20世纪70年代,之后逐渐扩展到各个领域,并且随着网络技术的飞速发展,分布式文件系统在体系结构、系统规模、性能、可扩展性、可用性等方面经历了巨大的变化。

分布式文件系统的发展主要经历了以下四个阶段:

(1)20世纪80年代,早期的分布式文件系统一般以提供标准接口的远程文件访问为目的,更多地关注访问的性能和数据的可靠性。早期的文件系统以网络文件系统(network file system,NFS)和andrew文件系统(andrew file system,AFS)最具代表性。

(2)1990—1995年,面对广域网和大容量存储需求,出现了xFS、Tiger Shark并行文件系统及Frangipani等分布式文件系统。

(3)1995—2000年,网络技术的发展推动了网络存储技术的改进,基于光纤通道的SAN、NAS得到了广泛应用,例如GFS和GPFS等。同时,数据容量、性能和共享的需求使得这一阶段的分布式文件系统的规模更大、结构更复杂。

(4)2000年以后,随着SAN和NAS两种体系结构逐渐成熟,研究人员开始考虑如何将两种体系结构结合起来,以充分利用两者的优势。这一阶段的代表有IBM的Storage Tank,Cluster的Lustre,Panasas的PanFS,蓝鲸文件系统(blue whale file system, BWFS)等。在这个阶段,各种应用对存储系统也提出了更多的需求:①大容量,数据量比以往任何时期更多,生成速度更快;②高性能,数据访问需要更高的带宽;③高可用性,不仅要保证数据的高可用性,还要保证服务的高可用性;④可扩展性,应用在不断变化,系统规模也在不断变化,这就要求系统提供很好的扩展性,并在容量、性能、管理等方面都能适应应用的变化;⑤可管理性,随着数据量的飞速增长,存储的规模越来越庞大,存储系统本身也越来越复杂,这给系统的管理、运行带来了很高的维护成本;⑥按需服务,能够按照应用需求的不同提供不同的服务,如不同的应用、不同的客户端环境、不同的性能等。

3.2.3.2 分布式文件系统在能源行业中的应用

现代电力行业的发展已经迎来了历史上前所未有的考验与机遇。输配电、发电、信息化、数字化技术的进步与计算机在电力系统中的合理使用加快了电力行业的信息化建设,但同时也加剧了电力业务中数据资源的爆炸性增长。目前,电力业务中的数据已经完全达到了海量数据的范畴,传统的集中式存储系统与存储设计已经难以解决数据增长所带来的存储压力问题,更是难以满足业务处理响应时间的需求。分布式文件系统为海量数据的存储提供了新的方案。

电力业务中的分布式文件系统所处的网络环境更为稳健,系统来自外部攻击的可能性更小,不需要在系统结点上提供太多不必要的安全保障措施,从而极大地缓解了系统压力。然而,由于电力公司分布范围广泛,而且各个结点性能差距也比较大,数据存储在不同的结点上面,对系统提供的服务质量也会产生比较大的差异。另外,机器的宕机或者离线,都会造成数据丢失或者服务能力下降,因此分布式存储系统的首要目标就是保证数据的可靠性。在满足可靠性与基本功能的基础上,电力业务中的分布式文件系统还应该满足以下两个基本内容:

(1)系统数据转发。由于国家电力公司内各部门或者不同区域单位存在因为工作进展对比而进行的数据互传,所以需要分布式存储系统才能保证完成数据转发,从而满足用户需求。

(2)系统定位存储。由于电力业务被划分为省/地/县三级机构,而且各级机构大多仅关心本单位所辖区域的数据信息,所以在电力业务的海量数据存储系统中,其不同区域内计量点在进行数据存储时,应该具备本地化或者近地化存储功能。

3.2.3.3 主流分布式文件系统

分布式文件系统的存储资源非本地直连而是通过网络连接,可划分为NFS、AFS、cluster file system(集群文件系统)、parallel file system(并行文件系统)。其中,集群文件系统是由多个服务器结点组成的DFS,例如ISILON、LoongStore、Lustre、GlusterFS、GFS、HDFS。在并行文件系统中,所有客户端可以同时并发读写同一个文件,并且支持并行应用(如MPI),其典型系统包括GPFS、StorNext、BWFS、GFS、Panasas。

1)NFS(www.xing528.com)

NFS是个分布式的客户机/服务器文件系统。它的实质在于用户间计算机的共享,用户可以连接到共享计算机并像访问本地硬盘一样访问共享计算机上的文件。管理员可以建立远程系统上文件的访问,以至于用户感觉不到他们是在访问远程文件。NFS是个到处可用和广泛实现的开放式系统,其结构如图3-9所示。

图3-9 NFS架构

拥有实际的物理磁盘并且通过NFS将这个磁盘共享的主机称为NFS文件服务器,通过NFS访问远程文件系统的主机称为NFS客户机。一台NFS客户机可以利用许多NFS服务器提供的服务。相反,一台NFS服务器可以与多台NFS客户机共享它的磁盘。一台共享了部分磁盘的NFS服务器也可以是另一台NFS服务器的客户机。

客户使用其本地操作系统提供的系统调用访问文件系统。但是,本地UNIX文件系统接口已被VFS的接口代替。VFS接口上的操作或被传送到本地文件系统,或被传送到一个称为NFS客户的单独组件,该组件负责处理对存储在远程服务器上的文件的访问。在NFS中,所有客户/服务器通信都是通过RPC完成。NFS客户通过服务器的RPC实现对NFS文件系统的操作。VFS接口所提供的操作可以不同于NFS客户所提供的操作。VFS的整体思路是隐藏不同文件系统之间的差异。

在服务器端,可以看到相似的组织方式。NFS服务器负责处理输入的客户请求。RPC存根对请求进行解编,NFS服务器将它们转化成常规的VFS文件操作,随后这些操作被送到VFS层。VFS的工作是负责实现真实文件所在的本地文件系统。

NFS发展多年,简单而成熟,并且Linux直接在内核予以支持,使用方便。但是随着技术的发展和应用的需求,NFS暴露出很多缺点:可扩展性差,难以应用于大量存储节点和客户端的集群式系统;文件服务器的定位对客户端非透明,维护困难;缓存管理机制采用定期刷新机制,可能会发生文件不一致性问题;不支持数据复制、负载均衡等分布式文件系统的高级特性,容易出现系统的性能瓶颈;NFS服务器的更换会迫使系统暂停服务;对于异地服务的支持能力不强。综上所述,NFS对于追求海量数据吞吐量、存在成千上万个客户端和存储节点的互联网应用已不再适用。

2)AFS

AFS是美国卡内基梅隆大学开发的一种分布式文件系统,主要功能是管理分布在网络不同结点上的文件。它提供给用户的只是一个完全透明的、永远唯一的逻辑路径,AFS的这种功能往往被用于用户的home目录,以使得用户的home目录唯一,而且避免了数据的不一致性。

AFS基于客户端/服务器结构,服务器是一台机器或者是运行在一台机器上的进程,用来为其他的机器提供专门的服务。客户端是一台机器或在其工作过程中使用服务器提供服务的进程,客户端和服务器的功能区别并不总是局限性的。AFS将网络中的机器分成文件服务器和客户端两种基本的类型,并向它们指派各式各样的任务。

(1)单元(cell)。是AFS一个独立的维护站点,通常代表一个组织的计算资源。一个存储节点在同一时间内只能属于一个站点,而一个单元可以管理数个存储节点。

(2)卷(volume)。是一个AFS目录的逻辑存储单元,可以把它理解为AFS的cell之下的一个文件目录。AFS系统负责维护一个单元中存储的各个结点上的卷内容保持一致。

(3)挂载点(mount point)。关联目录和卷的机制。

(4)复制(replication)。隐藏在一个单元之后的卷可能在多个存储节点上维护着备份,但是对用户是不可见的。当一个存储节点出现故障时,另一个备份卷会接替工作。

(5)缓存和回调(caching and callback)。AFS依靠客户端的大量缓存来提高访问速度。当多个客户端缓存的文件被修改时,必须通过回调来通知其他客户端更新。

AFS的技术成熟,具有较强的安全性,并且支持单一、共享的名字空间,同时良好的客户端缓存管理极大地提高了文件操作的速度。但是其也存在一些问题:①消息模型,AFS作为早期的分布式文件系统是基于消息传递(message-based)模型的,为典型的C/S模式,客户端需要经过文件服务器才能访问存储设备,维护文件共享语义的开销往往很大;②性能方面,它使用本地文件系统来缓存最近被访问的文件块,却需要一些附加的极为耗时的操作,因此要访问一个AFS文件比访问一个本地文件多花一倍的时间;③吞吐能力不足,AFS设计时考虑得更多的是数据的可靠性和文件系统的安全性,并没有为提高数据吞吐能力做优化,也没有良好地实现负载均衡;④容错性较差,由于采用有状态模型,因此在服务器崩溃、网络失效或者发生其他一些错误时,都可能产生意料不到的后果;⑤写操作慢, AFS为读操作做优化,写操作却很复杂,读快写慢的文件系统不能提供好的读、写并发能力;⑥不能提供良好的异地服务能力,不能很好地控制热点信息的分布。

3)集群文件系统

集群文件系统的典型代表为HDFS(Hadoop distributed file system),它最初是作为Apache Nutch搜索引擎项目的基础架构而开发的,是Apache Hadoop核心项目的一部分。HDFS被设计成适合运行在低廉硬件上的分布式文件系统,具有高度容错性,能提供高吞吐量的数据访问,非常适合大规模数据集上的应用。另外,HDFS放宽了一部分POSIX约束,以实现流式读取文件系统数据的目的。HDFS架构如图3-10所示。

图3-10 HDFS架构

(1)主节点(NameNode)。它是分布式文件系统中的管理者,是一个运行在单独机器上的软件,负责管理文件系统命名空间,维护系统内的所有文件和目录,但是只有表示数据节点(DataNode)和块文件映射的元数据经过NameNode,而实际的I/O事务并不经过NameNode,当外部节点发送请求要求创建文件时,NameNode以块标识和该块第一个副本的DataNode IP地址作为响应,并同时通知其他将要接收该块副本的DataNode。

(2)数据节点(DataNode)。DataNode也是一个运行在单独机器上的软件,通常以机架的形式进行组织,并且机架通过一台交换机将所有系统连接起来,DataNode主要用于响应来自HDFS结点的读写请求和NameNode对块的创建、删除和复制命令。

(3)文件写入。从图3-11可知,HDFS写文件过程为:客户端(client)调用create()来创建文件;Distributed File System用RPC调用元数据结点,在文件系统的命名空间中创建一个新的文件;元数据结点首先确定文件原来不存在,并且客户端有创建文件的权限,然后创建新文件;Distributed File System向客户端返回一个DFS输出流(Output Stream)对象用于写数据,同时,该对象中封装了一个DFS Output Stream对象,客户端通过DFS Output Stream对象管理DataNode和NameNode之间的通信;客户端开始写入数据,DFS Output Stream将数据分成块,写入Dataqueue;Dataqueue由Data Streamer读取,并通知元数据节点分配数据结点,用来存储数据块(每块默认复制3块)。分配的数据节点放在一个传递途径(pipeline)里;Data Streamer将数据块写入pipeline中的第一个数据节点,然后第一个数据节点将数据块发送给第二个数据节点,第二个数据节点将数据发送给第三个数据节点;DFS Output Stream为发出去的数据块保存了ack queue,等待pipeline中的数据结点告知数据已经写入成功;如果数据节点在写入的过程中失败,则关闭pipeline;当客户端结束写入数据,则调用stream的close函数。

图3-11 HDFS写文件过程

(4)文件读取。从图3-12可知,HDFS读文件过程为:客户端用File System的open ()函数打开文件;Distributed File System用RPC调用元数据节点,得到文件的数据块信息;对于每一个数据块,元数据结点返回保存数据块的数据节点的地址;Distributed File System返回一个FSData输入流(Input Stream)对象给客户端,并用于读取数据,同时, FSData Input Stream封装Distributed File System对象用于管理DataNode和NameNode的I/O;客户端调用stream的read()函数开始读取数据;DFS Input Stream连接保存此文件第一个数据块的最近的数据节点;Data从数据节点读到客户端(client),当此数据块读取完毕时,DFS Input Stream关闭和此数据节点的连接,然后连接此文件下一个数据块的最近的数据节点;当客户端读取完毕数据的时候,调用FSData Input Stream的close函数;在读取数据的过程中,如果客户端在与数据节点通信过程中出现错误,则尝试连接包含此数据块的下一个数据节点;失败的数据节点将被记录,以后不再连接。

图3-12 HDFS读文件过程

综上所述,HDFS可以运行在廉价的商用机器集群上处理超大文件,并且能够流式地访问数据。但是其最大的缺点是不适合低延迟数据访问,无法高效存储大量小文件。

4)并行文件系统

为对并行文件系统做进一步了解,在此对GFS(Google file system)做详细介绍。GFS是Google公司为了存储海量搜索数据而设计的一个可扩展的分布式文件系统,可用于大型的、分布式的、对大量数据进行访问的应用。同时它可运行于廉价的普通硬件上,并通过容错功能为大量的用户提供总体性能较高的服务。GFS架构如图3-13所示。

图3-13 GFS架构

在图3-13中,Client是应用程序的访问接口;Master(主服务器)是管理节点,在逻辑上只有一个,保存系统的元数据,负责整个文件系统的管理;Chunk Server(数据库服务器)负责具体的存储工作,数据以文件的形式存储在Chunk Server上。在Client和Master之间只有控制流,没有数据流,此设计大大降低了Master的负载。另外,在Client与Chunk Server之间直接传输数据流,同时由于文件被分成多个Chunk进行分布式存储,因此Client可以同时并行访问多个Chunk Server,从而提高系统的I/O并行度。

GFS采用中心服务器模式可以方便地增加Chunk Server,消除元数据的不一致性,快捷地进行负载均衡。同时GFS不进行数据缓存(没有系统cache),因此不存在数据的大量重复读写,并且无须考虑cache中的数据与Chunk Server中的数据的一致性问题。但是, GFS只能具有一个主服务器,系统的最大存储容量和正常工作时间受制于主服务器的容量和正常工作时间。同时,因为主服务器要将所有的元数据进行编制,几乎所有的动作和请求都经过主服务器,这对主服务器的性能提出了更高的要求。