Google文件系统GFS.ppt

Google文件系统GFS
Google设计GFS的动机
为了满足Google迅速增长的数据处理需求,需要一个支持海量存储的文件系统
购置昂贵的分布式文件系统与硬件?
Google设计GFS的动机
为什么不使用当时现存的文件系统?
Google所面临的问题与众不同
不同的工作负载,不同的设计优先级(廉价、不可靠的硬件)
需要设计与Google应用和负载相符的文件系统
GFS的假设与目标
硬件出错是正常而非异常
系统应当由大量廉价、易损的硬件组成
必须保持文件系统整体的可靠性
主要负载是流数据读写
主要用于程序处理批量数据,而非与用户的交互或随机读写
数据写主要是“追加写”,“插入写”非常少
需要存储大尺寸的文件
存储的文件尺寸可能是GB或TB量级,而且应当能支持存储成千上万的大尺寸文件
GFS设计原则
组件失效被认为是常态事件,而不是意外事件。
能应付对大型/超大型文件处理。
绝大部分文件的修改是采用在文件尾部追加数据,而不是覆盖原有数据的方式。
应用程序和文件系统API的协同设计提高了整个系统的灵活性。
支持大量用户同时访问。
系统交互
设计GFS系统时,一个重要的原则是最小化所有操作和Master节点的交互。
租约和变更顺序
数据流
原子的记录追加
快照
租约和变更顺序
变更是一个会改变Chunk 内容或者元数据的操作,比如写入操作或者记录追加操作。变更操作会在Chunk 的所有副本上执行。我们使用租约(lease)机制来保持多个副本间变更顺序的一致性。Master 节点为Chunk 的一个副本建立一个租约,我们把这个副本叫做主Chunk。主Chunk 对Chunk 的所有更改操作进行序列化。所有的副本都遵从这个序列进行修改操作。因此,修改操作全局的顺序首先Master 节点选择的租约的顺序决定,然后由租约中主Chunk 分配的序列号决定。
设计租约机制的目的是为了最小化Master节点的管理负担。
租约和变更顺序
客户机向Master 节点询问哪一个Chunk 服务器持有当前的租约,以及其它副本的位置。
Master节点将主Chunk 的标识符以及其它副本的位置返回给客户机。客户机缓存这些数据以便后续的操作。
客户机把数据推送到所有的副本上。客户机可以以任意的顺序推送数据。Chunk 服务器接收到数据并保存在它的内部LRU 缓存中,一直到数据被使用或者过期交换出去。
当所有的副本都确认接收到了数据,客户机发送写请求到主Chunk 服务器。
主Chunk 把写请求传递到所有的二级副本。每个二级副本依照主Chunk 分配的序列号以相同的顺序执行这些操作。
所有的二级副本回复主Chunk,它们已经完成了操作。
主Chunk 服务器回复客户机。任何副本产生的任何错误都会返回给客户机。
数据流
为了提高网络效率,采取了把数据流和控制流分开的措施。
在控制流从客户机到主Chunk、然后再到所有二级副本的同时,数据以管道的方式,顺序的沿着一个精心选择的Chunk 服务器链推送。
目标是充分利用每台机器的带宽,避免网络瓶颈和高延时的连接,最小化推送所有数据的延时。
数据流
为了充分利用每台机器的带宽,数据沿着一个Chunk 服务器链顺序的推送。
为了尽可能的避免出现网络瓶颈和高延迟的链接,每台机器都尽量的在网络拓扑中选择一台还没有接收到数据的、离自己最近的机器作为目标推送数据。
利用基于TCP连接的、管道式数据推送方式来最小化延迟。