分布式文件系统GFS

发布时间 2023-05-23 15:13:28作者: 好人~

0.简介

文件系统应该具有的接口:

  • 基本接口:创建(Create)、删除(Delete)、打开(Open)、关闭(Close)、读取(Read)、写入(Write)
    对于打开和关闭我们可以把它理解成读取与写入的前置和后置动作,在GFS中不必太多关注它。

  • 拓展的接口:生成快照(Snapshot)、修改(Update)、追加(Append)。GFS不支持修改,这样的设计原因就是追加操作更易保证一致性。

1.GFS整体架构

FS中有三种节点:GFS client,GFS master,GFS chunkserver。

  • GFS client:向应用提供接口,与应用交互。
  • GFS master:维护元数据,统一管理chunk位置与租约。元数据:文件位置等信息
  • GFS chunkserver:存储数据的节点,每个chunkserver中有很多包含数据的chunk

GFS整体架构图:

GFS整体架构描述:

2.GFS的存储设计:chunk

chunk:考虑到文件可能非常大,并且大小不均。GFS没有选择直接以文件为单位进行存储,而是把文件分为一个个chunk来存储。GFS把每个chunk设为64MB

64MB这个值是偏大的。为什么GFS会这么设计呢?:

  • 使用GFS的系统需要存储的文件都偏大(几GB),所以较大的chunk可以有效减少系统内部的寻址和交互次数,即找一个chunk是需要时间的,较大的chunk可以减少查找次数。

  • 大的chunk意味着client可能在一个chunk上执行多次操作,这可以复用TCP连接,节省网络开销;

  • 更大的chunk可以减少chunk数量,从而节省元数据存储开销,相当于节省了系统内最珍贵的内存资源,这对GFS来讲是非常关键的。

3.GFS的master设计

GFS中将管理元数据节点设计为一个单点,元数据的服务尽可能简单,来保证单个中心节点也能支持整个系统的服务。GFS设计了单个master节点,用来存储整个文件系统的三类元数据:

  • 所有文件和chunk的namespace【持久化】,即所有文件的文件名和每个chunk的编号。

  • 文件到chunk的映射【持久化】,即一个文件名到chunk编号的对应关系。

  • 每个chunk的位置【不持久化】,即每个chunk编号到具体chunkserver中位置的映射。
    不做持久化的原因:因为master在重启的时候,可以从各个chunkserver处收集chunk的位置信息,并且master宕机不经常发生,所以不需要将此信息持久化在master中。

GFS读取一个文件的基本逻辑:文件名→获取文件对应的所有chunk名→获取所有chunk的位置→依次到对应的chunkserver中读取chunk。

GFS采用了一系列措施来确保master不会成为整个系统的瓶颈,这些措施主要体现为减轻master的压力:

  • GFS所有的数据流都不经过master,而是直接由client和chunkserver交互。GFS把控制流和数据流分离,只有控制流才会经过master。
  • GFS的client会缓存master中的元数据,在大部分情况下,都无需访问master;
  • GFS还希望可以把所有的元数据都装在master的内存中,从而让元数据服务特别的高效。
  • 为了避免master的内存成为系统的瓶颈,从而让元数据服务特别的高效。所以GFS采用了一些手段来节省master的内存,包括增大chunk的大小以节省chunk的数量、对元数据进行定制化的压缩等。

4.GFS的高可用设计