谷歌文件系统GFS.ppt

垃圾收集 分布式垃圾收集有一定的复杂性，GFS用一种高效的方式处理。 确定对块数据的引用 确定块数据的副本信息 主服务器不认知的副本被确认为是垃圾文件 文件被删除后，GFS不立即回收磁盘空间 磁盘空间等到垃圾收集程序在文件和数据块级的检查中收回 这种办法更简单，可靠。 END 谷歌文件系统(GFS) Motivation 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(高度可用的带宽比低延迟更加重要 ) 文件以数据块的形式存储 数据块大小固定，每个数据块拥有句柄。 利用副本技术保证可靠性 每个数据块至少在3个块服务器上存储副本。 每个数据块作为本地文件存储在Linux文件系统中。 主服务器维护所有文件系统的元数据 每个GFS簇只有一个主服务器。 利用周期性的心跳信息更新服务器 GFS的设计思想 GFS的设计思想：集中+分布 缓存 无论是客户端还是Chunk服务器都不需要缓存文件数据。大部分程序要么以流的方式读取一个巨大文件，要么工作集太大根本无法被缓存。 无需考虑缓存相关的问题也简化了客户端和整个系统的设计和实现。 GFS的体系结构 GFS存储的文件都被分割成固定大小 的Chunk),64位，linux，根据指定的 Chunk标志和字节范围来读写块数据 Master逻辑上只有一个， 客户端和Master节点的通 信只获取元数据(名字空 间，访问控制信息，文件 和Chunk的映射信息，当 前Chunk的位置信息等) GFS的体系结构 什么是主服务器？ 在独立的主机上运行的一个进程 存储的元数据信息： 文件命名空间 文件到数据块的映射信息 数据块的位置信息 访问控制信息 数据块版本号 GFS的体系结构 chunk文件数据块：64MB的大数据块 优点： 减少master上保存的元数据的规模，使得可以将元数据metadata放在内存中。 Client在一个给定块上很可能执行多个操作，和一个块服务器保持较长时间的TCP连接可以减少网络负载。 在client中缓存更多的块位置信息。 缺点： 一个文件可能只包含一个块，如果很多client访问该文件，存储块的块服务器可能会成为访问热点。 GFS的体系结构 块位置信息 Master并不为块服务器的所有块的副本保存一个不变的记录。 Master在启动时或者在有新的client加入这个簇时通过简单的查询获取这些信息。 Master可以保持这些信息的更新，因为它控制所有块的放置并通过心跳消息（heartbeat）来监控。 GFS的体系结构 内存数据结构 master的操作很快，所以master可以轻易而且高效地定期在后台扫描它的整个状态 块垃圾收集 为平衡负载和磁盘空间而进行的块迁移 块服务器出现故障时的副本复制 整个系统的容量受限于master的内存 若要支持更大的文件系统，那么增加一些内存的方法对于我们将元数据保存在内存中所获得的简单性、可靠性、高性能和灵活性来说，只是一个很小的代价。 GFS的体系结构 主服务器和块服务器之间的通信 定期地获取状态信息 块服务器是否关闭？ 块服务器上是否有硬盘损坏？ 是否有副本出错？ 块服务维护哪些块的副本？ 主服务器发送命令给块服务器： 删除已存在的块。 创建新的块。 GFS的体系结构 操作日志 操作日志包含了对metadata所作的修改的历史记录，被复制在多个远程块服务器上。 它可以从本地磁盘装入最近的检查点来恢复状态。 它作为逻辑时间基线定义了并发操作的执行顺序。 文件、块以及它们的版本号都由它们被创