2024谷歌Google ⽂件系统说明.docx

Google文件系统

我们设计并实现了Google文件系统，这是一个可扩展的分布式文件系统，适用于大型分布式

数据密集型应用程序。它提供容错功能，同时在廉价的商用硬件上运行，并且能够

为大量客户提供高总体性能。

虽然与以前的分布式文件系统有许多相同的目标，但我们的设计是由对应用程序工作负载和技术环境（当前和预期）的观察所驱动的，这些观察反映了显著的

偏离了一些早期的文件系统假设。这

促使我们重新审视传统的选择并探索截然不同的设计点。

文件系统已成功满足我们的存储需求。它在Google内部被广泛部署为存储?台

用于生成和处理我们服务所使用的数据，以及需要的研究和开发工作

大型数据集。迄今为止最大的集群在数千个磁盘上提供数百TB的存储空间超过一千台机器，并且同时访问

受到数百位客户的青睐。

在本文中，我们介绍了文件系统接口扩展旨在支持分布式应用程序，讨论许多

我们设计的各个方面，并报告测量结果

微基准测试和实际应用。

类别和主题描述

D[4]:3分布式文件系统

一般条款

设计、可靠性、性能、测量

关键词

容错、可扩展性、数据存储、集群存储

可以通过以下地址联系作者：

{sanjay,hgobioff,shuntak}@。

引言

我们设计并实施了Google文件系统(GFS)，以满足Google的快速增长的需求

数据处理需求。GFS具有许多相同的目标与以前的分布式文件系统（如性能）一样，可扩展性、可靠性和可用性。然而，其设计

我们对当前和预期的应用工作负载和技术环境进行了关键观察，这些观察结果与之前的一些预测有明显不同。

文件系统设计假设。我们重新审视了传统的选择，并探索了完全不同的观点。设计空间。

首先，部件故障是常态，而不是例外。文件系统由数百个甚至

数以千计的存储机器由廉价的商品部件建造而成，并由相当数量的

客户端机器。组件的数量和质量几乎保证了某些组件无法正常工作

任何时候，有些将无法从当前的故障中恢复。我们已经看到由应用程序引起的问题

错误、操作系统错误、人为错误和故障

磁盘、内存、连接器、网络和电源。因此，持续监控、错误检测、故障

宽容和自动恢复必须是不可或缺的系统。

其次，按照传统标准，文件非常大。多GB

文件很常见。每个文件通常包含许多应用程序对象，例如Web文档。当我们定期

处理快速增长的许多TB数据集，包括

数十亿个对象，即使文件系统能够管理数十亿个大约KB大小的文件，也是很困难的。

支持它。因此，设计假设和参数

诸如I/O操作和块大小等都必须重新审视。

第三，大多数文件都会因附加新数据而发生变化

而不是覆盖现有数据。随机写入

一个文件实际上不存在。一旦写入，文件只能读取，而且通常只能按顺序读取。各种

数据具有这些特征。有些数据可能构成大量数据分析程序扫描的存储库。一些

可能是运行应用程序不断生成的数据流。有些可能是档案数据。有些可能是在一台机器上生成并处理的中间结果

在另一个之上，无论是同时还是稍后。鉴于

这种对大文件的访问模式，附加操作成为性能优化和原子性保证的重点，

而在客户端缓存数据块则失去了吸引力。第四，共同设计应用程序和文件系统

API通过提高我们的灵活性使整个系统受益。

例如，我们放宽了GFS的一致性模型，从而大大简化了文件系统，而不会给应用程序带来沉重的负担。我们还引入了原子追加操作，以便多个客户端可以同时向文件追加数据，而无需在它们之间进行额外的同步。这些将在后面的

界面

GFS提供了熟悉的文件系统接口，尽管它没有实现POSIX等标准API。文件按层次结构组织在目录中，并通过路径名标识。我们支持创建、删除、打开、关闭、读取和写入文件的常见操作。

纸。

目前已部署了多个GFS集群用于不同用途。最大的集群拥有超过1000个存储节点、超过300TB的磁盘存储，并且数百个客户端在不同机器上持续频繁访问。

设计概述

此外，GFS具有快照和记录附加操作。快照以低成本创建文件或目录树的副本。记录附加允许多个客户端同时将数据附加到同一文件，同时保证每个客户端附加的原子性。它对于实现多路合并结果和生产者?消费者队列非常有用，许多客户端可以同时附加到这些队列而无需额外的锁定。我们发现这些类型的文件在构建大型分布式应用程序中非常有用。快照和记录附加将分别在第3.4节和第3.3节中进一步讨论。

假设在设计满足我们需

求的文件系统时，我们一直遵循既有挑战又有机遇的假设。我们之前提到了一些关键观察结果，现在更详细地阐述我们的假设。

·系统由许多经常发生故障的廉价商品组件构成。系统必须不断自我监控，并定期检测、容忍和快速恢复组件故障。

架构GFS集群由一个

主服务器和多个块服务器组成，由多个客户端访问，如图1所