Google_File_System_中文版.docx

The Google File System中文版译者：alex[出处链接]整理：cxw摘要III分类和主题描述III常用术语III关键词III1. 简介12.设计概述12.1设计预期12.2 接口22.3 架构22.4 单一Master节点32.5 Chunk尺寸42.6 元数据42.6.1 内存中的数据结构52.6.2 Chunk位置信息52.6.3 操作日志52.7 一致性模型62.7.1 GFS一致性保障机制62.7.2 程序的实现83. 系统交互83.1 租约（lease）和变更顺序83.2 数据流103.3 原子的记录追加103.4 快照114. Master节点的操作124.1 名称空间管理和锁124.2 副本的位置134.3 创建，重新复制，重新负载均衡134.4 垃圾回收144.4.1 机制144.4.2 讨论144.5 过期失效的副本检测155. 容错和诊断155.1 高可用性155.1.1 快速恢复155.1.2 Chunk复制165.1.3 Master服务器的复制165.2 数据完整性175.3 诊断工具176. 度量186.1 小规模基准测试186.1.1 读取186.1.2 写入196.1.3 记录追加196.2 实际应用中的集群196.2.1 存储206.2.2 元数据206.2.3 读写速率216.2.4 Master服务器的负载216.2.5 恢复时间216.3 工作负荷分析(Workload Breakdown)226.3.1 方法论和注意事项226.3.2 Chunk服务器工作负荷226.3.3 记录追加 vs. 写操作246.3.4 Master的工作负荷247. 经验258. 相关工作269. 结束语27致谢27参考28摘要我们设计并实现了Google GFS文件系统，一个面向大规模数据密集型应用的、可伸缩的分布式文件系统。GFS虽然运行在廉价的普遍硬件设备上，但是它依然了提供灾难冗余的能力，为大量客户机提供了高性能的服务。虽然GFS的设计目标与许多传统的分布式文件系统有很多相同之处，但是，我们的设计还是以我们对自己的应用的负载情况和技术环境的分析为基础的，不管现在还是将来，GFS和早期的分布式文件系统的设想都有明显的不同。所以我们重新审视了传统文件系统在设计上的折衷选择，衍生出了完全不同的设计思路。GFS完全满足了我们对存储的需求。GFS作为存储平台已经被广泛的部署在Google内部，存储我们的服务产生和处理的数据，同时还用于那些需要大规模数据集的研究和开发工作。目前为止，最大的一个集群利用数千台机器的数千个硬盘，提供了数百TB的存储空间，同时为数百个客户机服务。在本论文中，我们展示了能够支持分布式应用的文件系统接口的扩展，讨论我们设计的许多方面，最后列出了小规模性能测试以及真实生产系统中性能相关数据。?分类和主题描述D [4]: 3—D分布文件系统常用术语设计，可靠性，性能，测量关键词容错，可伸缩性，数据存储，集群存储1. 简介为了满足Google迅速增长的数据处理需求，我们设计并实现了Google文件系统(Google File System – GFS)。GFS与传统的分布式文件系统有着很多相同的设计目标，比如，性能、可伸缩性、可靠性以及可用性。但是，我们的设计还基于我们对我们自己的应用的负载情况和技术环境的观察的影响，不管现在还是将来，GFS和早期文件系统的假设都有明显的不同。所以我们重新审视了传统文件系统在设计上的折衷选择，衍生出了完全不同的设计思路。首先，组件失效被认为是常态事件，而不是意外事件。GFS包括几百甚至几千台普通的廉价设备组装的存储机器，同时被相当数量的客户机访问。GFS组件的数量和质量导致在事实上，任何给定时间内都有可能发生某些组件无法工作，某些组件无法从它们目前的失效状态中恢复。我们遇到过各种各样的问题，比如应用程序bug、操作系统的bug、人为失误，甚至还有硬盘、内存、连接器、网络以及电源失效等造成的问题。所以，持续的监控、错误侦测、灾难冗余以及自动恢复的机制必须集成在GFS中。其次，以通常的标准衡量，我们的文件非常巨大。数GB的文件非常普遍。每个文件通常都包含许多应用程序对象，比如web文档。当我们经常需要处理快速增长的、并且由数亿个对象构成的、数以TB的数据集时，采用管理数亿个KB大小的小文件的方式是非常不明智的，尽管有些文件系统支持这样的管理方式。因此，设计的假设条件和参数，比如I/O操作和Block的尺寸都需要重新考虑。第三，绝大部分文件的修改是采用在文件尾部追加数据，而不是覆盖原有数据的方式。对文件的随机写入操作在实际中几乎不存在。一旦写完之后，对文件的操作就只有读，而且通常是按顺序读。大量的数据符合这些特性，比如：数据分析程序扫描的超大的数