Google文件系统.docVIP

Google文件系统摘要 我们设计并实现了Google文件系统，一个为数据中心的大规模分布应用设计的可伸缩的分布文件系统。Google文件系统虽然运行在廉价的普遍硬件上，但是可以提供容错能力，为大量客户机提供高性能的服务。 我们的系统与许多以前的分布文件系统拥有许多相同的目标，但我们的设计还受到我们对我们的应用负载和技术环境观察的影响，不管现在还是将来，我们和早期文件系统的假设都有明显的不同。所以我们重新审视了传统的选择，发展了完全不同的设计观点。 Google文件系统成功的满足了我们的存储需求。它作为存储平台被广泛的部署在Google内部，用在我们的服务中产生和处理数据，还用于那些需要大规模数据集的研究和开发。目前为止最大的集群利用数千台机器内的数千个硬盘，提供了数百T的存储空间，同时为数百个客户机服务。 在这篇论文中，我们展现如果用文件系统接口扩展设计去支撑分布应用，讨论我们设计的许多方面，最后报告在小规模性能测试以及真实世界中系统的性能测试结果。 1. 简介 我们设计并实现了Google文件系统(Google File System - GFS)，用来满足Google迅速增长的数据处理需求。GFS与过去的分布文件系统拥有许多相同的目标，例如性能，可伸缩性，可靠性以及可用性。然而，它的设计还受到我们对我们的应用负载和技术环境观察的影响，不管现在还是将来，我们和早期文件系统的假设都有明显的不同。所以我们重新审视了传统的选择，采取了完全不同的设计观点。 首先，组件失效不再被认为是意外，而是被看做正常的现象。这个文件系统包括几百甚至几千台普通廉价部件构成的存储机器，又被相应数量的客户机访问。组件的数量和质量几乎保证，在任何给定时间，某些组件无法工作，而某些组件无法从他们的目前的失效状态恢复。我们发现过，应用程序bug造成的问题，操作系统bug造成的问题，人为原因造成的问题，甚至硬盘、内存、连接器、网络以及电源失效造成的问题。所以，常量监视器，错误侦测，容错以及自动恢复系统必须集成在系统中。 其次，按照传统的标准来看，我们的文件非常巨大。数G的文件非常寻常。每个文件通常包含许多应用程序对象，比如web文档。传统情况下快速增长的数据集在容量达到数T，对象数达到数亿的时候，即使文件系统支持，处理数据集的方式也就是笨拙地管理数亿KB尺寸的小文件。所以，设计预期和参数，例如I/O操作和块尺寸都要重新考虑。 第三，在Google大部分文件的修改，不是覆盖原有数据，而是在文件尾追加新数据。对文件的随机写是几乎不存在的。一般写入后，文件就只会被读，而且通常是按顺序读。很多种数据都有这些特性。有些数据构成数据仓库供数据分析程序扫描。有些数据是运行的程序连续生成的数据流。有些是存档的数据。有些数据是在一台机器生成，在另外一台机器处理的中间数据。对于这类巨大文件的访问模式，客户端对数据块缓存失去了意义，追加操作成为性能优化和原子性保证的焦点。 第四，应用程序和文件系统API的协同设计提高了整个系统的灵活性。例如，我们放松了对GFS一致性模型的要求，这样不用加重应用程序的负担，就大大的简化了文件系统的设计。我们还引入了原子性的追加操作，这样多个客户端同时进行追加的时候，就不需要额外的同步操作了。论文后面还会对这些问题的细节进行讨论。 为了不同的应用，Google已经部署了许多GFS集群。最大的一个，拥有超过1000个存储节点，超过300T的硬盘空间，被不同机器上的数百个客户端连续不断的频繁访问着。 2.设计概述 2.1设计预期 在设计我们需要的文件系统时，我们用既有机会又有挑战的设计预期来指导我们的工作。前面我们提到了一些关键的信息，这里我们讲更细节的描述我们的设计预期。 这个系统由许多廉价易损的普通组件组成。它必须持续监视自己的状态，它必须在组件失效作为一种常态的情况下，迅速地侦测、承担并恢复那些组件失效。 这个系统保存一定数量的大文件。我们预期有几百万文件，尺寸通常是100MB或者以上。数GB的文件也很寻常，而且被有效的管理。小文件必须支持，但是不需要去优化。 负载中主要包含两种读操作：大规模的流式读取和小规模随机读取。大规模的流式读取通常一次操作就读取数百K数据，更常见的是一次性读取1MB甚至等多。同一个客户机的连续操作通常是对一个文件的某个区域进行连续读取。小规模的随机读取通常是在随机的位置读取几个KB。对性能有所要求的程序通常把小规模的读批量处理并且排序，这样就不需要对文件进行时前时后的读取，提高了对文件读取的顺序性。 负载中还包括许多大规模的顺序的写操作，追加数据到文件尾部。一般来说这些写操作跟大规模读的尺寸类似。数据一旦被写入，文件就几乎不会被修改了。系统对文件的随机位置写入操作是支持的，但是不必有效率。 系统必须高效的实现良好定义的多客