只知道HDFS和GFS?你其实并不懂分布式文件系统

作者介绍
张轲,目前任职于杭州大树网络技术有限公司,担任首席架构师,负责系统整体业务架构以及基础架构 。
 
一、概述 
分布式文件系统是分布式领域的一个基础应用,其中最著名的毫无疑问是 HDFS/GFS。如今该领域已经趋向于成熟,但了解它的设计要点和思想,对我们将来面临类似场景/问题时,具有借鉴意义 。
 
并且,分布式文件系统并非只有 HDFS/GFS 这一种形态,在它之外,还有其他形态各异、各有千秋的产品形态,对它们的了解,也对扩展我们的视野有所俾益 。
 
本文试图分析和思考,在分布式文件系统领域,我们要解决哪些问题、有些什么样的方案、以及各自的选择依据 。
 
二、过去的样子 
在几十年以前,分布式文件系统就已经出现了,以 Sun 在 1984 年开发的“Network File System (NFS)”为代表,那时候解决的主要问题,是网络形态的磁盘,把磁盘从主机中独立出来 。
 
这样不仅可以获得更大的容量,而且还可以随时切换主机,还可以实现数据共享、备份、容灾等,因为数据是电脑中最重要的资产 。NFS 的数据通信图如下:
 

只知道HDFS和GFS?你其实并不懂分布式文件系统

文章插图
 
 
部署在主机上的客户端,通过 TCP/IP 协议把文件命令转发到远程文件 Server 上执行,整个过程对主机用户透明 。
 
到了互联网时代,流量和数据快速增长,分布式文件系统所要解决的主要场景变了,开始需要非常大的磁盘空间,这在磁盘体系上垂直扩容是无法达到的,必须要分布式,同时分布式架构下,主机都是可靠性不是非常好的普通服务器,因此容错、高可用、持久化、伸缩性等指标,就成为必须要考量的特性 。
 
三、对分布式文件系统的要求 
对一个分布式文件系统而言,有一些特性是必须要满足的,否则就无法有竞争力 。主要如下:
 
  • 应该符合 POSIX 的文件接口标准,使该系统易于使用,同时对于用户的遗留系统也无需改造;
  • 对用户透明,能够像使用本地文件系统那样直接使用;
  • 持久化,保证数据不会丢失;
  • 具有伸缩性,当数据压力逐渐增长时能顺利扩容;
  • 具有可靠的安全机制,保证数据安全;
  • 数据一致性,只要文件内容不发生变化,什么时候去读,得到的内容应该都是一样的 。
 
除此之外,还有些特性是分布式加分项,具体如下:
 
  • 支持的空间越大越好;
  • 支持的并发访问请求越多越好;
  • 性能越快越好;
  • 硬件资源的利用率越高越合理,就越好 。
 
四、架构模型 
从业务模型和逻辑架构上,分布式文件系统需要这几类组件:
 
  • 存储组件:负责存储文件数据,它要保证文件的持久化、副本间数据一致、数据块的分配 / 合并等等;
  • 管理组件:负责 meta 信息,即文件数据的元信息,包括文件存放在哪台服务器上、文件大小、权限等,除此之外,还要负责对存储组件的管理,包括存储组件所在的服务器是否正常存活、是否需要数据迁移等;
  • 接口组件:提供接口服务给应用使用,形态包括 SDK(JAVA/C/C++ 等)、CLI 命令行终端、以及支持 FUSE 挂载机制 。
 
而在部署架构上,有着“中心化”和“无中心化”两种路线分歧,即是否把“管理组件”作为分布式文件系统的中心管理节点 。两种路线都有很优秀的产品,下面分别介绍它们的区别 。
 
1、有中心节点
 
以 GFS 为代表,中心节点负责文件定位、维护文件 meta 信息、故障检测、数据迁移等管理控制的职能,下图是 GFS 的架构图:
 
只知道HDFS和GFS?你其实并不懂分布式文件系统

文章插图
GFS架构
 
该图中 GFS master 即为 GFS 的中心节点,GF chunkserver 为 GFS 的存储节点 。其操作路径如下:
 
  • Client 向中心节点请求“查询某个文件的某部分数据”;
  • 中心节点返回文件所在的位置 (哪台 chunkserver 上的哪个文件) 以及字节区间信息;
  • Client 根据中心节点返回的信息,向对应的 chunk server 直接发送数据读取的请求;
  • chunk server 返回数据 。
 
在这种方案里,一般中心节点并不参与真正的数据读写,而是将文件 meta 信息返回给 Client 之后,即由 Client 与数据节点直接通信 。其主要目的是降低中心节点的负载,防止其成为瓶颈 。这种有中心节点的方案,在各种存储类系统中得到了广泛应用,因为中心节点易控制、功能强大 。


推荐阅读