GFS.ppt

* * * * * * * * * LOGO LOGO GFS Google File System Contents Background 1 GFS Architecture 2 System interactions 3 Master operation 4 measurements 6 Fault tolerance and diagnosis 5 NDSL * Background NDSL * Background GFS 一个适用于大规模分布式数据处理相关应用的，可扩展的分布式文件系统。它基于普通的不算昂贵的硬件设备，实现了容错的设计，并且为大量客户端提供极高的聚合处理性能。 NDSL * Background Google的应用负载和技术环境 集群中的节点失效是一种常态，而不是一种异常。 按照传统标准，文件都是非常巨大的，通常以G字节计。 大部分文件都是只会在文件尾新增加数据，而少见修改已有数据的。 应用程序和文件系统API的协同设计提高了整个系统的灵活性。 NDSL * Background 设计预期 持续监视、错误检测、容错处理、自动恢复 对大文件有效管理同时支持小型文件 读取始终是单向顺序读取 文件超大文件的顺序写入、随即小规模的写入 支持多路合并模式进行操作 高性能的稳定带宽的网络要比低延时更加重要 接口 常见操作 creat、delete、open、close、read、write 特殊操作 snapshot、record append(原子操作) NDSL * GFS Architecture GFS集群由一个单个的master和多个chunkserver（块服务器）组成，还有相应的很多客户端client。 NDSL * GFS Architecture 在GFS下，每一个文件都拆成固定大小的chunk(块)。每一个块都由master根据块创建的时间产生一个全局唯一的以后不会改变的64位的chunk handle标志。 chunkservers在本地磁盘上用Linux文件系统保存这些块，并且根据chunk handle和字节区间，通过LInux文件系统读写这些块的数据。 出于可靠性的考虑，每一个块都会在不同的chunkserver上保存备份。缺省情况下，我们保存3个备份。 Chunkserver NDSL * GFS Architecture Master负责管理所有的文件系统的元数据 文件和chunk的namespace 访问控制信息 文件到chunk的映射关系 当前chunk的位置等等 Master控制系统级别的活动 chunk的分配管理 孤点chunk的垃圾回收机制 chunk在chunkserver之间的移动 Master用心跳信息周期地跟每个chunkserver通信，给他们 以指示并收集他们的状态 单一Master设计必须减小master的读/写操作，以避免它成 为集群瓶颈。 Master NDSL * GFS Architecture Client Client代码包含了google文件系统的API，并且会和master和 chunkserver进行通信。 client和master通信—交互元数据信息 client会缓存从master获取的元数据信息，以便对同一块 的操作不在通过client-master交互。(除非cache过期或 这个文件被再次打开 client和chunkserver通信—交互文件数据 client所有的数据相关的通信是直接和chunkserver进行， 但是不会缓存文件数据。 NDSL * GFS Architecture Read operate Client读取数据的操作顺序： client把应用要读取的文件名和偏移量，根据固定的chunk大小，转换成为文件的chunk index。 向master发送这个包含了文件名和chunkindex的请求。 master返回相关的chunk handle以及对应的位置，client缓存这些信息。 client就向最近的对应位置的chunkserver发起请求，请求包含chunk handle以及一个在这个chunk内需要读取得字节区间。 chunkserver返回给client要读取的chunk data。 NDSL * GFS Architecture Chunksize 是设计的关键参数(64M)。 采用很大的chunksize优点： 它减少了客户端和master的交互。 减少网络管理量。 减少了元数据在master上的大小