分布式文件系统

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