Case Study GFSEvolution on Fastforward.docxVIP

Case Study GFS：Evolution on Fast-forward(译) 译者：phylips@bmy 2011-8 在Google的早期开发阶段，最初的想法并没有包含一个构建新的文件系统的计划。工作依然是通过公司最早版本的爬虫和索引系统来完成，但是，事情对于核心工程师们很快变得明朗起来，除了构建一个新的系统外他们别无选择，于是GFS(Google File System)就诞生了。 首先，由于Google的目标是要通过使用很多廉价的商品化硬件来构建一个大规模存储网络。因此它必须要假设组件失败是一种常态—这就意味着常规性的监控，错误检测，容错，自动恢复必须作为系统内完整的一部分。而且，即使是Google最早期的一些估算，该文件系统的吞吐率需求在任何人看来都是非常可观的—处理multi-gigabyte级别的文件，数据集可能包含数TB的数据及数百万个对象。很明显，这意味着必须要重新审视关于IO操作及块大小的传统假设。同时还需要关注可扩展性。这肯定是一个需要全然不同的扩展性的文件系统。当然，在早期的那些日子里，没有人能说出到底需要什么样的扩展性。但是很快他们就会明白。 ?虽然已过了近十年，但是Google那令人叹为观止的数据存储以及不断增长的应用仍然是建立在GFS之上。在这个过程中，该文件系统进行过很多变更—同时那些使用GFS的应用程序也不断进行着各种改变—这使得一切成为可能。 ?为了探索某些关键的初始设计决定以及从那时起所进行的一些改进的缘由，ACM邀请了Sean QUINLAN：来揭开那些处于不断变更中的文件系统需求以及那些不断演化的思想的神秘面纱。在很多年中，Sean QUINLAN：一直是GFS的技术领导人，目前已是Google的首席工程师，因此他是一个引导我们透视GFS的不二人选。为避免局限于Google的视野，ACM又邀请了Kirk MCKUSICK：来推动这个讨论。他因为在BSD Unix上的工作，包括Berkeley FFS(Fast File System)的原始设计而为人熟知。 ?这个讨论以初始GFS实现中的单master设计决定作为开端。乍看，单个的中央Master会成为带宽瓶颈—或者，更糟的是可能产生单点失败—但是实际上呢，对于这个决定，Google的工程师们有他们自己的设计考虑。 MCKUSICK： 原始的GFS架构中有一个很有趣也很重要的设计决定就是基于一个单master。能否解释一下是什么原因导致了这个决定？ ?QUINLAN： 采用单master的决定实际上是最初的几个决定中的一个，最主要的是为了简化总体的设计。也就是说，直接建立一个分布式的master当时看来很困难而且会花太多时间。而且，通过这种单master策略，工程师也可以简化很多问题。这就有一个中央位置可以用来控制relication，垃圾回收和很多其他行为，这比在一个分布式的环境上更简单。因此，最后决定将这些集中到一台机器上。 ?MCKUSICK： 那是不是主要是因为这样就可以在一个尽量短的时间内解决很多问题。 ?QUINLAN： 是的。曾经参与GFS的一些工程师后来继续去实现BigTable，一个分布式的存储系统，这个系统就花了好多年。这种将最初的GFS建立在单master上的决定大大加快了其实现进度。 而且，考察了面临的使用场景之后，当时看起来单master的设计也不会引起大的问题。当时所考虑的规模大概是在数百TB数据以及数百万文件数。事实上，这个系统一开始工作的很好。 ?MCKUSICK： 但是，之后呢？ ?QUINLAN： 随着底层存储大小的增长，一些问题开始暴露出来。当从数百TB上升到PB级别，再到数10PB……这会导致master需要维护的元数据数量产生了相应规模的增长。而且，那些扫描元数据的操作也是随数据量线性增长的。这种需要master所做的工作大幅增长，所需要存储的数据量也随之增长。 另外，这对于客户端也会是一个瓶颈，即使客户端本身只产生很少的元数据操作—比如，客户端进行一个open操作时会与master通信。当有成千上万个客户端同时与master通信时，假设master每秒只能处理几千个操作，那么客户端就不能在一秒内产生这么多请求。而且需要注意的是有很多像MapReduce这样的应用程序，可能有上千个task，每个都可能打开一些文件。很明显，master需要花很长时间去处理这些请求，会承受很大的压力。 ?MCKUSICK： 现在，在当前的GFS模式里，一个GFS cell有一个master，对吗？ ?QUINLAN：是的。 ?MCKUSICK： 历史上，你们曾经是一个数据中心一个GFS cell，是吗？ ?QUINLAN： 那是最初的目标，但是那样无法进行更大的扩展—一部分是由于受单master设计的限制