08 谷歌文件系统GFS.ppt

END * 第8章谷歌文件系统(GFS) Assumptions Google needed a good distributed file system 首先，组件失效不再被认为是意外，而是被看做正常的现象。 Redundant storage of massive amounts of data oncheap and unreliable computers “Modest” number of HUGE files 其次，按照传统的标准来看，Google的文件非常巨大。 Each is 100MB or larger; multi-GB files typical Files are write-once, mostly appended to 第三，在Google大部分文件的修改，不是覆盖原有数据，而是在文件尾追加新数据。 Assumptions High component failure rates(这个系统由许多廉价易损的普通组件组成 ) Inexpensive commodity components fail often Large streaming reads(大规模的流式读取和小规模随机读取 ) High sustained throughput favored over low latency(高度可用的带宽比低延迟更加重要 ) GFS设计思想 Files stored as chunks Fixed size (64MB) Reliability through replication Each chunk replicated across 3+ chunkservers Single master to coordinate access, keep metadata Simple centralized management No data caching Little benefit due to large data sets, streaming reads Familiar interface, but customize the API Simplify the problem; focus on Google apps Add snapshot and record append operations GFS的体系结构 GFS的体系结构 主服务器 存储的元数据信息： 文件命名空间 文件到数据块的映射信息 数据块的位置信息 访问控制信息 数据块版本号 管理数据块租约，垃圾收集，及数据块迁移 通过心跳信息周期性与块服务器通信 GFS的体系结构 块服务器 文件以固定数据块的形式存储 每个数据块拥有一个64位的句柄。 每个数据块作为本地文件存储在Linux文件系统中。 每个数据块至少在3个块服务器上存储副本。 GFS的体系结构 文件数据块：64MB的大数据块 优点： 减少master上保存的元数据的规模，使得可以将metadata放在内存中。 Client在一个给定块上很可能执行多个操作，和一个块服务器保持较长时间的TCP连接可以减少网络负载。 在client中缓存更多的块位置信息。 缺点： 一个文件可能只包含一个块，如果很多client访问该文件，存储块的块服务器可能会成为访问热点。 GFS的体系结构 块位置信息 Master并不为块服务器的所有块的副本保存一个不变的记录。 Master在启动时或者在有新的client加入这个簇时通过简单的查询获取这些信息。 Master可以保持这些信息的更新，因为它控制所有块的放置并通过心跳消息（heartbeat）来监控。 GFS的体系结构 主服务器和块服务器之间的通信定期地获取状态信息: 块服务器是否关闭？ 块服务器上是否有硬盘损坏？ 是否有副本出错？ 块服务维护哪些块的副本？ 主服务器发送命令给块服务器： 删除已存在的块。 创建新的块。 GFS的体系结构 操作日志 操作日志包含了对metadata所作的修改的历史记录，被复制在多个远程块服务器上。 它可以从本地磁盘装入最近的检查点来恢复状态。 它作为逻辑时间基线定义了并发操作的执行顺序。 文件、块以及它们的版本号都由它们被创建时的逻辑时间而唯一地、永久地被标识。 Master可以用操作日志来恢复它的文件系统的状态。 GFS的体系结构 服务请求： Client 从主服务器检索元数据（metadata）。 在client和主服务器之间读/写数据流。 单个主服务器并不会成为瓶颈，因为它在读/写操作中的工作量很小。 GFS的读操作 GFS的读操作 计算数据块位置信息：（假设：文件位置在201，359，161字节处） 块大小=64MB 64MB=1024*1024*6