文档介绍：谷歌文件系统(GFS)
Motivation
Google needed a good distributed file system
首先,组件失效不再被认为是意外,而是被看做正常的现象。
Redundant storage of massive amounts of data oncheap and puters
“Modest” number of HUGE files
其次,按照传统的标准来看,Google的文件非常巨大。
Each is 100MB or larger; multi-GB files typical
Files are write-once, mostly appended to
第三,在Google大部分文件的修改,不是覆盖原有数据,而是在文件尾追加新数据。
Assumptions
ponent failure rates(这个系统由许多廉价易损的普通组件组成)
ponents 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的内存
若要支持更大的文件系统,那么增加一些内存的方法对于我们将元数据保存在内存中所获得的简单性、可靠性、高性能和灵活性来说,只是一个很小的代价。