Google 文件系统——GFS

[惘忆丶]

GFS 也就是 google File System，Google公司为了存储海量搜索数据而设计的专用文件系统。它是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，并提供容错功能。它可以给大量的用户提供总体性能较高的服务。 GFS与过去的分布式文件系统有很多相同的目标,但GFS的设计受到了当前及预期的应用方面的工作量及技术环境的驱动,这反映了它与早期的文件系统明显不同的设想。这就需要对传统的选择进行重新检验并进行完全不同的设计观点的探索。 GFS提供了一个相似地文件系统界面,虽然它没有向POSIX那样实现标准的API。文件在目录中按层次组织起来并由路径名标识。 一个GFS集群由一个master和大量的chunkserver构成,并被许多客户(Client)访问。Master和chunkserver通常是运行用户层服务进程的Linux机器。只要资源和可靠性允许,chunkserver和client可以运行在同一个机器上。 GFS的新颖之处并不在于它采用了多么令人惊讶的新技术，而在于它采用廉价的商用计算机集群构建分布式文件系统，在降低成本的同时经受了实际应用的考验。只 有一个master也极大的简化了设计并使得master可以根据全局情况作出精密的块放置和复制决定。 块规模是设计中的一个关键参数。Google选择的是64MB，这比一般的文件系统的块规模要大的多。每个块的副本作为一个普通的Linux文件存储，在需要的时候可以扩展。 master 存储了三种类型的metadata：文件的名字空间和块的名字空间，从文件到块的映射，块的副本的位置。所有的metadata都放在内存中。前两种类型 的metadata通过向操作日志登记修改而保持不变，操作日志存储在master的本地磁盘并在几个远程机器上留有副本。使用日志使得我们可以很简单地、可靠地更新master的状态，即使在master崩溃的情况下也不会有不一致的问题。相反，master在每次启动以及当有 chunkserver加入的时候询问每个chunkserver的所拥有的块的情况。 名字空间的修改必须是原子性的，它们只能有master处理：名字空间锁保证了操作的原子性和正确性，而master的操作日志在全局范围内定义了这些操作的顺序。 虽然 GFS 的设计目标与许多传统的分布式文件系统有很多相同之处，但是，GFS 和早期的分布式文件系统的设想都有明显的不同。为了更好的完善GFS，人们重新审视了传统文件系统在设计上的折衷选择，衍生出了完全不同的设计思路。首先，组件失效被认为是常态事件，而不是意外事件。其次，以通常的标准衡量，我们的文件非常巨大。第三，绝大部分文件的修改是采用在文件尾部追加数据，而不是覆盖原有数据的方式。第四，应用程序和文件系统 API 的协同设计提高了整个系统的灵活性。在程序的实现当中，使用 GFS 的应用程序可以利用一些简单技术实现这个宽松的一致性模型，这些技术也用来实现一些其它的目标功能，包括：尽量采用追加写入而不是覆盖，Checkpoint，自验证的写入操作，自标识的记录。在实际应用中，我们所有的应用程序对文件的写入操作都是尽量采用数据追加方式，而不是覆盖方式。 这三大论文让我感触颇多，加深了我对Google的了解，MapReduce,Bigtable,Google Flie System这三大“工具”的发展进步让Google有了如今的样子，我们不仅想起了对这些工具的进步作出贡献的伟人们，我们应该向他们致敬。