e1. 需求

*. 廉价硬件,组件失效是常态

*. 大文件,通常在100MB或者以上,也必须支持小文件,但是不需要针对小文件做专门的优化

*. 大规模的原子性追加写,数据一旦被写入后,文件就很少会被修改

*. 大规模的流式读和小规模的随机读:小规模的随机读取操作合并并排序,之后按顺序批量读取

  1. 架构

    • GFS存储的文件都被分割成固定大小的Chunk。在Chunk创建的时候,Master服务器会给每个Chunk分配一个不变的、全球唯一的64位的Chunk标识。Chunk服务器把Chunk以linux文件的形式保存在本地硬盘上,并且根据指定的Chunk标识和字节范围来读写块数据。出于可靠性的考虑,每个块都会复制到多个块服务器上
    • Master节点管理所有的文件系统元数据。这些元数据包括名字空间、访问控制信息、文件和Chunk的映射信息、以及当前Chunk的位置信息。Master节点还管理着系统范围内的活动,比如:心跳检测、Chunk租约管理的回收、以及Chunk在Chunk服务器之间的迁移
    • 客户端缓存元数据,不缓存Chunk:因为流式读、文件大;Chunk服务器直接使用Linux的文件系统缓存
  2. 设计细节

    • Master服务

      • 逻辑单一,物理2个:极大减少复杂度
      • 为客户端选择最近Chunk副本
      • 提前读:客户端通常会在一次请求中查询多个Chunk信息,Master节点的回应也可能包含了紧跟着这些被请求的Chunk后面的Chunk的信息,以减少两者间的通信次数。
      • 元数据
        • 3种主要类型:文件和Chunk的命名空间、文件和Chunk的对应关系、每个Chunk副本的存放地点
        • 保存于内存:文件名前缀压缩<64B
        • 命名空间、文件和Chunk的对应关系会以记录变更日志的方式记录在操作系统的系统日志文件中,日志会被复制到其它的远程Master服务器上
        • Master服务器不会持久保存Chunk位置信息,在启动或者有新的Chunk服务器加入时,向各个Chunk服务器轮询它们所存储的Chunk的信息
        • Master服务器可以在后台简单而高效的周期性扫描自己保存的全部状态信息。这种周期性的状态扫描也用于实现Chunk垃圾收集、在Chunk服务器失效的时重新复制数据、通过Chunk的迁移实现跨Chunk服务器的负载均衡以及磁盘使用状况统计等功能
        • Master服务器只需要不到64个字节的元数据就能够管理一个64MB的Chunk。由于大多数文件都包含多个Chunk,因此绝大多数Chunk都是满的,除了文件的最后一个Chunk是部分填充的。同样的,每个文件的在命名空间中的数据大小通常在64字节以下,因为保存的文件名是用前缀压缩算法压缩过的
      • Chunk位置信息
        • Master服务器并不保存持久化保存哪个Chunk服务器存有指定Chunk的副本的信息。Master服务器只是在启动的时候轮询Chunk服务器以获取这些信息
        • 最初设计时,我们试图把Chunk的位置信息持久的保存在Master服务器上,但是后来我们发现在启动的时候轮询Chunk服务器,之后定期轮询更新的方式更简单。这种设计简化了在有Chunk服务器加入集群、离开集群、更名、失效、以及重启的时候,Master服务器和Chunk服务器数据同步的问题。在一个拥有数百台服务器的集群中,这类事件会频繁的发生
      • 操作日志
      • Chunk服务
        • Chunk尺寸
          • 64MB >> 文件系统的4096B
          • 优:减少Chunk元数据信息->元数据及其缓存所需内存更小、减少和Master通信次数
          • 缺:产生更多Chunk数量少的文件(例如1个Chunk)->热点文件导致热点Chunk
          • 优化:热点文件使用更多副本、允许客户端从其它客户端读取数据、错开批处理程序启动时间 *