6.824-lecture3

GFS

The Google File System

为什么读这个paper

• 文件系统使用mr

• 6.824的主题在论文中体现

• 简单且表现良好的交易一致性

• 为之后的设计提供了思路

• 优秀的系统论文-app的细节，包或网络性能，错误容忍，一致性

• 影响

  • 很多文件系统使用GFS ()

    GFS (e.g., Bigtable, Spanner @ Google)
        HDFS (Hadoop Distributed File System) based on GFS
    

什么是一致性

• 一个没有差错的情况
• 重要的，但是很难做到的当数据是重复的
• 尤其当application是并行进行的
• 当一个数据读写交替进行
• 当多个应用来读取写数据
• 由于数据的重复，一个地方的数据变化，必须让其他的复制也变化数据
• 很明显我们会遇到很多问题
  • 读可能得到过期的数据

强一致性

• read 返回的是最后一次写的数据
• 写操作的强一致性是容易的
• 强一致性性能很差
• 弱一致性性能好，但是经常读到过期的消息
• 弱一致性是复杂的对于排查错误

对于正确的情况是什么做出来很多的权衡

• 这叫一致性模型

理想的一致性模型

• 让我们回到单机情况`
  • 如果一个重复的文件系统表现的像一个没有重复的文件系统
• 如果一个app写，之后的读者会观察到这次写
• 如果两个app并行的写同一个文件
• 在单机中这是不允许的，会导致错误，加锁使得串行

得到理想一致性的挑战

• 并行：数据存放在不同硬盘里
• 机器故障：任何操作都会导致
• 网络故障-可能无法得到每个机器
• 为什么这些困很难？
  • client和server的通信效率是很差的
  • 协议会很复杂
  • 很难在系统层面正确的编写
  • 大部分分布式系统不保证理想的一致性
  • GFS就是之一

GFS目标

• 有很多机器，错误是很正常的
• 必须是容错的
• 假设一个机器每年崩溃一次
• 1000台机器。每天坏3次
• 高性能：会有并行的读写行为
• map reduce会存储和读取结果在gfs中
• 不是临时，而是实时数据
• 有效利用网络来减少带宽
• 这些都是一致性的困难所在

设计

• master 存储目录，文件，open/read/write 但是不是POSIX的
• 100个linux chunks服务器
• 存储64mb的文件快，linux常见的块
• 每块重复三次
• 问题：3份数据除了可以保证高可用，还有什么好处？
  • 热数据的负载均衡
• 问题：为啥存储每个文件的复制在raid磁盘中
  • raid不是商品？
  • 我们想要整个机器的容错，不只是存储部分
• 问题：分快为啥要这么大？
  • 摊销overhead,避免在master那的状态信息庞大
• GFS master知道目录架构
• 对于目录，一个64mb的文件快，需要64bytes的信息，将他们放在内存中
• master拥有私有的可恢复的数据库为元数据磁盘操作日志
• 影子master更新跟在master之后，可以取代master

client read:

• 给master发送文件名和块索引
• master 回复拥有这个快的服务器
• 回复包括chunk的版本
• clients 的cache信息
• 去的最近的块server
• 如果找不到，再次联系主节点

写

• 对当前文件的随机client写
• client 问masterchunk位置
• master回复chunk server version 和谁是primary primary拥有60s的延迟
• client根据网络拓扑来计算重复的链路
• client发送数据给第一个复制，这促使其他流水线网络的使用，分布式的负载
• 数据复制
  • 主要是记录序列数和写
  • 告诉其他复制来写
  • 一旦做完了，告诉client
• 如果中途，其他clinet要对同一个地方写？
  • client得到一个client1后面的sequenced，重写数据
  • client2可能先写数据，之后client来了重写数据
  • 所有的复制都有一样的数据（一致性），但是读写中间是不保证的c1 c2中
• client增加
  • 类似，结果保证一致性，过程不保证

record append

• client 记录增加
• client要求主节点chunk 位置
• client 将数据push进replica 但是没有offset
• client 联系primary当数据在所有块中
  • primary 有序列数
  • primary检查时候后append是合适的对于chunk,如果不行，等待
  • primary得到append的offset
  • primary是局部变化的
  • primary推请求给replicas
  • 当中途失败-写数据过程中，
  • primary监测到错误，告诉client再次尝试
• client重复在联系主节点后
  • 主节点可能崩溃
  • 一个复制已经有一个gap在byte序列，所以不嫩那个仅仅append到另一个可用的offset 在所有复制中
  • primary 和 secondaries执行写
  • primary回复给client在收到来自replicas的ack后

Housekeeping

Master 能够选出新的primary 如果master不能更新lease

主节点 重复块如果复制挂掉了

主节点再次平衡重复数

失败

• 块是很容易复制的
• 失败后让client复制记录
• master down gfs不可用
• 影子主节点可以提供只读的操作，但是会返回过期数据
• 为什么不能写操作
  • 裂脑效应

GFS得到了理想的一致性吗？

• 两个方面：目录和文件
• 目录：是的但是
  • 强一致性
  • 但是 主节点不是高可用的，也不是水平扩展的
• 文件：不总是
  • 原子的append数据改变
    • 数据可以被两个offset复制，尽管其他复制可能会有一个洞在offset上
  • 非原子的append数据改变
    • 几个clients的数据的混杂的
    • 如果你介意，使用原子apeend 或者临时文件 或者原子的命名
  • 一个不幸的client可能会得到过期的数据
    • 一个错误会导致块的不一致
      • 主要的块服务器更新快
      • 但是失败了，因此数据过期
    • 一个client访问一个还没更新的chunk
    • 当client 更新lease 他马上会得到新的版本

作者说稍微的不一致性不会给服务造成大问题

• 大部分的文件操作是append-onlly的更新
• application可以使用uid 在一个append记录，来检测重复
• app可以使用临时文件和原子的重命名

表现

• 大的聚合通过读 3copy 125 mb/sec 在 聚合时候
• 接近饱和的网络
• 写给不同的文件低于可能的最大值
• 作者批评他们的网络栈
• 他导致了时延，当chunk传播他们的复制时

总结

• 案例研究，容错，一致性 专门为了mr应用
• 什么应用在gfs运行良好？
• 大的序列的读写
• append
• 大的吞吐
• 需要容错

谁工作的不好在GFS

• 主节点容错
• 小文件 不能平衡overhaed
• 不能容忍过期消息
• append可能是重复的