谷歌文件系统GFS.ppt

谷歌文件系统GFS.ppt

《谷歌文件系统GFS.ppt》由会员分享，可在线阅读，更多相关《谷歌文件系统GFS.ppt（33页珍藏版）》请在冰豆网上搜索。

谷歌文件系统（GFS）,Motivation,Googleneededagooddistributedfilesystem首先，组件失效不再被认为是意外，而是被看做正常的现象。

Redundantstorageofmassiveamountsofdataoncheapandunreliablecomputers“Modest”numberofHUGEfiles其次，按照传统的标准来看，Google的文件非常巨大。

Eachis100MBorlarger;multi-GBfilestypicalFilesarewrite-once,mostlyappendedto第三，在Google大部分文件的修改，不是覆盖原有数据，而是在文件尾追加新数据。

Assumptions,Highcomponentfailurerates（这个系统由许多廉价易损的普通组件组成）InexpensivecommoditycomponentsfailoftenLargestreamingreads（大规模的流式读取和小规模随机读取）Highsustainedthroughputfavoredoverlowlatency（高度可用的带宽比低延迟更加重要）,文件以数据块的形式存储数据块大小固定，每个数据块拥有句柄。

利用副本技术保证可靠性每个数据块至少在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所作的修改的历史记录，被复制在多个远程块服务器上。

它可以从本地磁盘装入最近的检查点来恢复状态。

它作为逻辑时间基线定义了并发操作的执行顺序。

文件、块以及它们的版本号都由它们被创建时的逻辑时间而唯一地、永久地被标识。

Master可以用操作日志来恢复它的文件系统的状态。

GFS的体系结构,服务请求：

Client从主服务器检索元数据（metadata）。

在client和主服务器之间读/写数据流。

单个主服务器并不会成为瓶颈，因为它在读/写操作中的工作量很小。

GFS的读操作,GFS的读操作,计算数据块位置信息：

（假设：

文件位置在201，359，161字节处）,块大小=64MB64MB=1024*1024*64bytes=67,359,161bytes201，359，161bytes=67,108,864*2+32,569bytes所以，client的位置索引是3.,GFS的读操作,GFS的读操作,应用程序发出读请求。

Client将请求转换为（文件名、块位置），然后发送给主服务器。

主服务器返回数据块的指引信息和副本位置信息。

Client选择其中一个位置信息，并给那个块服务器发送请求。

块服务器返回请求的数据。

Client将数据传送给应用程序。

GFS的互斥操作,互斥：

任何的写或者追加操作数据需要被写到所有的副本上当多个用户请求修改操作时，保证同样的次序。

GFS的互斥操作,GFS的互斥操作,GFS的互斥操作,GFS的互斥操作,GFS的互斥操作,GFS客户端发送请求到主服务器；主服务器返回块的句柄和副本的位置信息；客户端将写数据发送给所有副本服务器；数据存储在副本服务器的缓存中；客户发送写命令到主副本服务器；主副本服务器给出写的次序；主副本服务器将该次序发送给二级副本服务器；二级副本管理器响应主副本服务器；主服务器响应客户端。

添加操作的算法,谷歌文件系统中非常重要的操作：

把多个主机的结果合并到一个文件中。

将文件组织成生产者消费者队列。

Clients可以并发读。

Clients可以并发写。

Clients可以并发地执行添加操作。

应用程序提出添加操作的请求。

GFSclient解释该请求，然后发向主服务器。

主服务器返回块句柄和副本位置。

Client将要写入的数据推入各个副本。

Primary检查添加操作是否会导致该块超过最大的规模。

如果超过：

将该块扩充到最大规模，其它副本做同样的事，同时通知client该操作需要在下一个块上重新尝试。

如果记录满足最大规模，primary将数据添加到它的副本上，并告诉其它的副本在同样的偏移处写数据，最后primary向client报告写操作成功。

APPEND算法,一致性模型,并发的修改将导致一致性问题。

不同的client对同一组数据执行修改。

一致性：

所有的client读取的数据一致。

确定性：

所有的client读取全部的修改过程。

一致性模型,对数据块和副本执行相同顺序的添加操作。

利用数据块版本号来检测陈旧的副本。

记录追加操作致使多步的修改操作能单独的添加到文件尾。

并发读,Clients缓存数据块位置信息。

因为所有的修改操作都是追加，所以可以并发读。

容错,恢复：

不管如何终止服务，MASTER和数据块服务器都会在几秒钟内恢复状态和运行。

数据块备份：

每个数据块都会被备份到放到不同机架上的多个服务器上。

MASTER备份：

为确保可靠性，MASTER的状态、操作记录和检查点都在多台机器上进行了备份。

一个操作只有在数据块服务器硬盘上刷新并被记录在MASTER和其备份的上之后才算是成功的。

如果MASTER或是硬盘失败，系统监视器会发现并通过改变域名启动一个备份机，而客户机并不会发现MASTER的改变。

数据完整性,各个块服务器利用校检和独立地验证它的副本的完整性。

一个数据块被分为64kb大小的小块，每个小块有一个32bit的校检和。

读取时，块服务器先验证数据块的校检和，然后将数据返回给请求者。

遇到读取错误，错误被报告给请求者。

主服务器重读数据块。

创建、复制、平衡数据块,创建副本的原因：

数据块的创建、复制、平衡当主服务器产生新数据块时，如何放置新数据块要考虑一下因素：

放置在磁盘利用率低的数据块服务器控制在一个服务器上的“新创建”次数把数据块放置于不同的机架上。

垃圾收集,分布式垃圾收集有一定的复杂性，GFS用一种高效的方式处理。

确定对块数据的引用确定块数据的副本信息主服务器不认知的副本被确认为是垃圾文件文件被删除后，GFS不立即回收磁盘空间磁盘空间等到垃圾收集程序在文件和数据块级的检查中收回这种办法更简单，可靠。

END,