分布式系统课件谷歌文件系统gfs

1、第8章谷歌文件系统(GFS)AssumptionsGoogle 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 typicalFiles are write-once,

2、 mostly appended to第三，在Google大部分文件的修改，不是覆盖原有数据，而是在文件尾追加新数据。 AssumptionsHigh component failure rates(这个系统由许多廉价易损的普通组件组成 )Inexpensive commodity components fail oftenLarge streaming reads(大规模的流式读取和小规模随机读取 )High sustained throughput favored over low latency(高度可用的带宽比低延迟更加重要 )GFS设计思想Files stored as chunks

3、Fixed size (64MB)Reliability through replicationEach chunk replicated across 3+ chunkserversSingle master to coordinate access, keep metadataSimple centralized managementNo data cachingLittle benefit due to large data sets, streaming readsFamiliar interface, but customize the APISimplify the problem

4、; focus on Google appsAdd snapshot and record append operationsGFS的体系结构一个主服务器，存储元数据并进行相关的控制。多个块服务器 ，存储数据块（chunk），每个块64MB，用64位的全局统一ID标识。多个客户访问存储在块服务器上的文件。GFS的体系结构GFS的体系结构主服务器存储的元数据信息：文件命名空间文件到数据块的映射信息数据块的位置信息访问控制信息数据块版本号以上信息均放在主存中，速度非常快。管理数据块租约，垃圾收集，及数据块迁移通过心跳信息周期性与块服务器通信主服务器上的元数据： 文件和Chunk的命名空间（dire

5、ctory hierarchy）、文件和Chunk的对应关系、每个Chunk副本的存放地点。前两种类型的元数据（命名空间、文件和Chunk的对应关系）同时也会以记录变更日志的方式记录在操作系统的系统日志文件中，日志文件存储在本地磁盘上，同时日志会被复制到其它的远程Master服务器上。GFS的体系结构GFS的体系结构块位置信息Master在启动时或者定期轮询获取块位置信息。Master通过控制所有块的放置并通过心跳消息（heartbeat）来监控，保持这些信息的更新。Master为什么不固定存储块位置信息呢？GFS的体系结构操作日志操作日志包含了对metadata所作的修改的历史记录，被复制在

6、多个远程块服务器上。它可以从本地磁盘装入最近的检查点来恢复状态。它作为逻辑时间基线定义了并发操作的执行顺序。文件、块以及它们的版本号都由它们被创建时的逻辑时间而唯一地、永久地被标识。 Master可以用操作日志来恢复它的文件系统的状态。GFS的体系结构主服务器和块服务器之间的通信定期地获取状态信息:块服务器是否关闭？块服务器上是否有硬盘损坏？是否有副本出错？块服务维护哪些块的副本？主服务器发送命令给块服务器：删除已存在的块。创建新的块。GFS的体系结构Client与主服务器、块服务器的服务请求：Client 从主服务器检索元数据（metadata）。在client和块服务器之间读/写数据流。单

7、个主服务器并不会成为瓶颈，因为它在读/写操作中的工作量很小。GFS的体系结构块服务器文件以固定数据块的形式存储。每个数据块拥有一个64位的句柄。每个数据块作为本地文件存储在Linux文件系统中。每个数据块至少在3个块服务器上存储副本。GFS的体系结构文件数据块：64MB的大数据块优点：它减少了客户端和Master节点通讯的需求。Client在一个给定块上很可能执行多个操作，和一个块服务器保持较长时间的TCP连接可以减少网络负载。减少master上保存元数据的数量，使得可以将metadata放在内存中。缺点：一个文件可能只包含一个块，如果很多client访问该文件，存储块的块服务器可能会成为访问

8、热点。GFS的读操作GFS的读操作计算数据块位置信息：（假设：文件位置在201，359，161字节处）块大小=64MB64MB=1024*1024*64bytes =67,108,864bytes201，359，161bytes=67,108,864 * 3 + 32,569 bytes所以，client的位置索引是4.GFS的读操作GFS的读操作应用程序发出读请求。Client将请求转换为（文件名、块位置），然后发送给主服务器。主服务器返回数据块的指引信息和副本位置信息。Client选择其中一个位置信息，并给那个块服务器发送请求。 块服务器返回请求的数据。Client将数据传送给应用程序。租

9、约和变更顺序变更是一个会改变Chunk内容或者元数据的操作，比如写入操作或者记录追加操作。变更操作会在Chunk的所有副本上执行。使用租约（lease）机制来保持多个副本间变更顺序的一致性。主服务器为chunk的一个副本建立租约，这个副本称为主chunk，主Chunk对Chunk的所有更改操作进行序列化。所有的副本都遵从这个序列进行修改操作。租约和变更顺序租约和变更顺序租约和变更顺序租约和变更顺序租约和变更顺序GFS客户端发送请求到主服务器；主服务器返回块的句柄和副本的位置信息；客户端将写数据发送给所有副本服务器；数据存储在副本服务器的缓存中；客户发送写命令到主副本服务器；主副本服务器给出写的

10、次序；主副本服务器将该次序发送给二级副本服务器；二级副本管理器响应主副本服务器；主服务器响应客户端。租约和变更顺序APPEND算法谷歌文件系统中非常重要的操作：把多个主机的结果合并到一个文件中。将文件组织成生产者消费者队列。Clients可以并发读。Clients可以并发写。Clients可以并发地执行添加操作。应用程序提出添加操作的请求。GFS client 解释该请求，然后发向主服务器。主服务器返回块句柄和副本位置。Client将要写入的数据推入各个副本。Primary检查添加操作是否会导致该块超过最大的规模。如果超过：将该块扩充到最大规模，其它副本做同样的事，同时通知client该操作需

11、要在下一个块上重新尝试。如果记录满足最大规模，primary将数据添加到它的副本上，并告诉其它的副本在同样的偏移处写数据，最后primary向client报告写操作成功。 APPEND算法 一致性模型GFS支持宽松的一致性模型。文件命名空间的修改（例如，文件创建）是原子性的。它们仅由Master节点的控制：命名空间锁提供了原子性和正确性的保障；Master节点的操作日志定义了这些操作在全局的顺序。 一致性模型并发的修改将导致一致性问题。不同的client对同一组数据(region)执行修改。修改内容(region)一致的（consistent）：所有的client读取的数据一致，而不管数据是从

12、哪个块服务器读取的。修改内容已定义（defined）：如果修改数据是一致的，且client能够看到写入操作全部的内容。一致性模型对数据块和副本执行相同顺序的添加操作。利用数据块版本号来检测陈旧的副本。记录追加操作致使多步的修改操作能单独的添加到文件尾。 容错恢复：不管如何终止服务，master和数据块服务器都会在几秒钟内恢复状态和运行。数据块备份 ：每个数据块都会被备份放到不同机架上的多个服务器上。master备份：为确保可靠性，master的状态、操作记录和检查点都在多台机器上进行了备份。一个操作只有在数据块服务器硬盘上刷新并被记录在master和其备份的上之后才算是成功的。如果master

13、或是硬盘失败，系统监视器会发现并通过改变域名启动一个备份机，而客户机并不会发现master的改变。 数据完整性各个块服务器利用校检和独立地验证它的副本的完整性。一个数据块被分为64kb大小的小块，每个小块有一个32bit的校检和。读取时，块服务器先验证数据块的校检和，然后将数据返回给请求者。遇到读取错误，错误被报告给请求者。主服务器重读数据块。数据块的创建、复制、平衡数据块的创建希望在低于平均硬盘使用率的Chunk服务器上存储新的副本。希望限制在每个Chunk服务器上”最近”的Chunk创建操作的次数。希望把Chunk的副本分布在多个机架之间。Master节点选择优先级最高的Chunk，然后命令某个Chunk服务器直接从可用的副本”克隆”一个副本出来。Master服务器周期性地对副本进行重新负载均衡。 垃圾收集惰性垃圾收集策略 当一个文件被应用程序删除时，Master节点象对待其它修改操作一样，立刻把删除操作以日志的方式记