google文件系统gfs总结.ppt

Google 文件系 统 GFS Google 设计 GFS 的动机 ? 为了满足 Google 迅速增长的数据处理需求， 需要一个支持海量存储的文件系统 ? 购置昂贵的分布式文件系统与硬件？ Google 设计 GFS 的动机 ? 为什么不使用当时现存的文件系统？ ? Google 所面临的问题与众不同 不同的工作负载，不同的设计优先级（廉价、不可靠的硬 件） ? 需要设计与 Google 应用和负载相符的文件系统 GFS 的假设与目标 ? 硬件出错是正常而非异常 ? 系统应当由大量廉价、易损的硬件组成 ? 必须保持文件系统整体的可靠性 ? 主要负载是流数据读写 ? 主要用于程序处理批量数据，而非与用户的交互或随机 读写 ? 数据写主要是“追加写”，“插入写”非常少 ? 需要存储大尺寸的文件 ? 存储的文件尺寸可能是 GB 或 TB 量级，而且应当能支持存 储成千上万的大尺寸文件 GFS 设计原则 ? 组件失效被认为是 常态事件 ，而不是 意外事件 。 ? 能应付对 大型 / 超大型 文件处理。 ? 绝大部分文件的修改是采用在 文件尾部 追加数 据，而不是 覆盖 原有数据的方式。 ? 应用程序和文件系统 API 的 协同 设计提高了整 个系统的灵活性。 ? 支持 大量用户 同时访问。 系统交互 设计 GFS 系统时，一个重要的原则是 最小化所有 操作和 Master 节点的交互。 ? 租约和变更顺序 ? 数据流 ? 原子的记录追加 ? 快照 租约和变更顺序 变更是一个会改变 Chunk 内容或者元数据的操作 ，比 如写入操作或者记录追加操作。变更操作会在 Chunk 的所有副本上执行。我们使用 租约（ lease ）机制来 保持多个副本间变更顺序的一致性。 Master 节点为 Chunk 的一个副本建立一个租约，我们把这个副本叫 做主 Chunk 。主 Chunk 对 Chunk 的所有更改操作进行 序列化。所有的副本都遵从这个序列进行修改操作。 因此，修改操作全局的顺序首先 Master 节点选择的 租约的顺序决定，然后由租约中主 Chunk 分配的序列 号决定。 设计租约机制的目的是为了最小化 Master 节点的管理负担。 租约和变更顺序 客户机向 Master 节点询问哪一个 Chunk 服务器持有当前 的租约，以及其它副本的位置。 Master 节点将主 Chunk 的标识符以及其它副本的位置返回 给客户机。客户机缓存这些数据以便后续的操作。 客户机把数据推送到所有的副本上。客户机可以以任意的 顺序推送数据。 Chunk 服务器接收到数据并保存在它的内 部 LRU 缓存中，一直到数据被使用或者过期交换出去。 当所有的副本都确认接收到了数据，客户机发送写请求到 主 Chunk 服务器。 主 Chunk 把写请求传递到所有的二级副本。每个二级副 本依照主 Chunk 分配的序列号以相同的顺序执行这些操 作。 所有的二级副本回复主 Chunk ，它们已经完成了操作。 主 Chunk 服务器回复客户机。任何副本产生的任何错误 都会返回给客户机。 数据流 ? 为了提高网络效率，采取了把 数据流和控制流 分开的措施。 ? 在控制流从客户机到主 Chunk 、然后再到所有二 级副本的同时，数据以管道的方式，顺序的沿 着一个精心选择的 Chunk 服务器链推送。 ? 目标是充分利用每台机器的带宽，避免网络瓶 颈和高延时的连接，最小化推送所有数据的延 时。 数据流 ? 为了充分利用每台机器的带宽，数据沿着一个 Chunk 服务器链顺序的推送。 ? 为了尽可能的避免出现网络瓶颈和高延迟的链 接，每台机器都尽量的在网络拓扑中选择一台 还没有接收到数据的、离自己最近的机器作为 目标推送数据。 ? 利用基于 TCP 连接的、管道式数据推送方式来 最小化延迟。 数据流 client S3 S1 S2 假设客户机把数据从 Chunk 服务器 S1 推送到 S4 。它把数据推送到 最近的 Chunk 服务器 S1 。 S1 把数据推送到 S2 ，因为 S2 和 S4 中最接近 的机器是 S2 。同样的， S2 把数据传递给 S3 和 S4 之间更近的机器， 依次类推推送下去。我们的网络拓扑非常简单，通过 IP 地址就可 以计算出节点的“距离”。 原子的记录追加 ? 传统方式写入操作 客户程序会指定数据写入的偏移量，对同一个 region 的并行写 入操作不是串行的， region 尾部