产业气象站@只知道HDFS和GFS?你其实并不懂分布式文件系统

张轲 , 目前任职于杭州大树网络技术有限公司 , 担任首席架构师 , 负责系统整体业务架构以及基础架构 。
一、概述
分布式文件系统是分布式领域的一个基础应用 , 其中最著名的毫无疑问是HDFS/GFS 。 如今该领域已经趋向于成熟 , 但了解它的设计要点和思想 , 对我们将来面临类似场景/问题时 , 具有借鉴意义 。
并且 , 分布式文件系统并非只有HDFS/GFS这一种形态 , 在它之外 , 还有其他形态各异、各有千秋的产品形态 , 对它们的了解 , 也对扩展我们的视野有所俾益 。
本文试图分析和思考 , 在分布式文件系统领域 , 我们要解决哪些问题、有些什么样的方案、以及各自的选择依据 。
二、过去的样子
在几十年以前 , 分布式文件系统就已经出现了 , 以Sun在1984年开发的“NetworkFileSystem(NFS)”为代表 , 那时候解决的主要问题 , 是网络形态的磁盘 , 把磁盘从主机中独立出来 。
这样不仅可以获得更大的容量 , 而且还可以随时切换主机 , 还可以实现数据共享、备份、容灾等 , 因为数据是电脑中最重要的资产 。 NFS的数据通信图如下:
产业气象站@只知道HDFS和GFS?你其实并不懂分布式文件系统
文章图片
部署在主机上的客户端 , 通过TCP/IP协议把文件命令转发到远程文件Server上执行 , 整个过程对主机用户透明 。
到了互联网时代 , 流量和数据快速增长 , 分布式文件系统所要解决的主要场景变了 , 开始需要非常大的磁盘空间 , 这在磁盘体系上垂直扩容是无法达到的 , 必须要分布式 , 同时分布式架构下 , 主机都是可靠性不是非常好的普通服务器 , 因此容错、高可用、持久化、伸缩性等指标 , 就成为必须要考量的特性 。
三、对分布式文件系统的要求
对一个分布式文件系统而言 , 有一些特性是必须要满足的 , 否则就无法有竞争力 。 主要如下:
应该符合POSIX的文件接口标准 , 使该系统易于使用 , 同时对于用户的遗留系统也无需改造;对用户透明 , 能够像使用本地文件系统那样直接使用;持久化 , 保证数据不会丢失;具有伸缩性 , 当数据压力逐渐增长时能顺利扩容;具有可靠的安全机制 , 保证数据安全;数据一致性 , 只要文件内容不发生变化 , 什么时候去读 , 得到的内容应该都是一样的 。除此之外 , 还有些特性是分布式加分项 , 具体如下:
支持的空间越大越好;支持的并发访问请求越多越好;性能越快越好;硬件资源的利用率越高越合理 , 就越好 。四、架构模型
从业务模型和逻辑架构上 , 分布式文件系统需要这几类组件:
存储组件:负责存储文件数据 , 它要保证文件的持久化、副本间数据一致、数据块的分配/合并等等;管理组件:负责meta信息 , 即文件数据的元信息 , 包括文件存放在哪台服务器上、文件大小、权限等 , 除此之外 , 还要负责对存储组件的管理 , 包括存储组件所在的服务器是否正常存活、是否需要数据迁移等;接口组件:提供接口服务给应用使用 , 形态包括SDK(Java/C/C++等)、CLI命令行终端、以及支持FUSE挂载机制 。而在部署架构上 , 有着“中心化”和“无中心化”两种路线分歧 , 即是否把“管理组件”作为分布式文件系统的中心管理节点 。 两种路线都有很优秀的产品 , 下面分别介绍它们的区别 。
1、有中心节点
以GFS为代表 , 中心节点负责文件定位、维护文件meta信息、故障检测、数据迁移等管理控制的职能 , 下图是GFS的架构图:
产业气象站@只知道HDFS和GFS?你其实并不懂分布式文件系统
文章图片
GFS架构
该图中GFSmaster即为GFS的中心节点 , GFchunkserver为GFS的存储节点 。 其操作路径如下:
Client向中心节点请求“查询某个文件的某部分数据”;中心节点返回文件所在的位置(哪台chunkserver上的哪个文件)以及字节区间信息;Client根据中心节点返回的信息 , 向对应的chunkserver直接发送数据读取的请求;chunkserver返回数据 。在这种方案里 , 一般中心节点并不参与真正的数据读写 , 而是将文件meta信息返回给Client之后 , 即由Client与数据节点直接通信 。 其主要目的是降低中心节点的负载 , 防止其成为瓶颈 。 这种有中心节点的方案 , 在各种存储类系统中得到了广泛应用 , 因为中心节点易控制、功能强大 。


推荐阅读