GOOGLE文件系统

tanjiesymbol

                    GOOGLE文件系统
                  （翻译稿  谭杰  
tanjiesymbol@126.com
）
2.1 gfs的前提
1.系统由许多便宜的容易失效的组件构成。其必须进程性的自我监控，侦测，容错，并能从组件故障中快速的恢复。
2.系统会存储适当数量的大文件。如几百万文件，一般是100M或更大。好几G的文件也是常见的，并且能进行有效管理。小文件也需要支持，但是不会做优化。
3.系统的工作量由两部分组成：一个是大规模的流读操作；另一个是小规模的随即读操作。大规模流读操作通常单个操作会读几百KB，1MB甚至更多的数据。同一个client的后续的操作通常是读一个文件的连续的部分。小规模的随机读操作一般在指定的位移上读几个KB。性能敏感的应用程序经常对读操作批量处理并排序以便能够稳定的扫描一个文件而非来回扫描同一个文件。
4.工作量也包括许多大规模的连续的将数据追加到文件后面的写操作。这种写操作的规模通常比读操作小。小规模的随机写操作也能支持，但是不会需要有太高的效率。
5.系统必须为多个client并发追加到同一个文件后面的情况实现一个定义的很好的语义。文件通常用作生产者消费者队列或者多路归并。几百个生产者（每台机器有一个在运行）会并发的追加到同一个文件中。以最小的同步开销实现原子性是非常关键的。文件可能会被在后来或者同时被消费者读到。
6.稳定的带宽比低时延要重要的多。大部分目标应用更重视批量的高速的处理数据，而很少的应用需要对单个读或写操作有响应时间的要求
2.2 接口
   GFS提供了熟悉的文件系统接口，尽管它并没有提供诸如POSIX这样的标准API。文件被按层次在目录中组织起来，并用路径名标识出来。我们支持创建，删除，打开，关闭，读，写文件这样的通常操作。
   除此之外，GFS还提供快照和记录追加操作。快照以一个较小的代价创建一个文件或目录树的拷贝。记录追加允许多个clien往同一个文件同时追加数据并保证单个client追加操作的原子性。它有助于实现多路归并和生产者消费者队列，这样多个client可以在不加附件锁的情况下同时追加数据。我们发现这些类型的文件对构建分布式系统有无比珍贵的价值。
2.3 架构
   GFS集群由单个master和多个chunkserver构成，并能被多个client访问。其中的每一部分一般都是运行用户级别服务进程的linux机器。很容易将chunkserver和client放在同一台机器上面跑，只要机器资源允许并且可以接受由此带来的可靠性的降低。
   文件分成固定大小的块（chunk）。每一个块由永远不变并且全局性的唯一的64bit的chunk handle标识，这些chunk handle由master在创建块的时候分配。
   chunkserver以linux文件的形式在本地磁盘上面存储块（chunk），并通过指定块句柄（chunk handle）和字节范围来进行读写块数据的操作。为了可靠性考虑，每一个块都会在多个chunkserver上进行复制。我们默认存储三份复制数据，不过用户可以为文件命名空间上不同区域指定不同的复制级别。
   master维护所有的文件系统元数据。包括命名空间，访问权限信息，文件到块的映射关系，块的当前位置。同时还控制系统范围内的活动，诸如块的租借管理，孤儿块的回收和chunkserver之间块的迁移。master定期和每个chunkserver进行心跳消息的交互，发送指令并收集chunkserver的状态。
   GFS client 代码链接到应用程序中，其实现文件系统API并同master和chunkserver通讯来为应用程序进行读写操作。client会为元数据的操作同master进行交互，但是所有数据的通讯都是直接和chunkserver交互。我们不提供POSIX API 因此也就不会hook到linux的vnode层。
   client和chunkserver都不会缓存文件数据。client缓存数据的意义非常小，因为大多数应用流方式读取巨大的文件或者有太大的工作集需要缓存。没有缓存反倒可以避免缓存一致性问题，简化client和整个系统。（不过client确实会缓存元数据）。chunkservers不需要缓存文件数据因为块（chunks）是以本地文件的方式存储的，因此linux的缓冲区会将频繁访问的数据缓存在内存中。
  
2.4 单个master
  只使用单个master极大的简化了我们的设计，单个master可以利用全局数据制定完善的块放置和复制决策。但是必须将master涉及到的读写操作降到最低，以避免使它成为瓶颈。client不会从master读或写文件数据。client会向master询问应该向哪个chunkserver联系。它在一个有限的时间内缓存这个信息，并在接下来的操作中直接和chunkserver交互。
   让我们解释一下图1中所示的一个简单的读操作的交互过程。首先，client利用固定的块大小将应用程序指定的文件名和字节偏移量转换成文件中的块索引号。然后，它向master发送一个包含文件名和块索引号的请求。master的回应包含对应的块索引号和复制数据的位置。client使用文件名和块索引号作为主键缓存这个信息。
   client接着会发送请求给其中的一个复制品，通常是最近的一个。请求中包含了块句柄（chunk handle）和块中的字节范围。在缓存的信息过期或者文件重新打开之前，对同一个块的读操作不再需要client-master之间的交互。事实上，client一般会在同一个请求中询问多个块，master可以将被请求的块之后紧跟着的块信息包含在回应数据中。这些额外的信息可以不花费额外代价的情况下避免后续的client-master交互。
2.5 块大小
    块大小是一个关键的设计参数。我们选择64MB，这比典型的文件系统块大小要大的多。每个块的复制品存储在chunkserver上的普通的linux文件中，并只有在必要的时候才进行扩展。懒惰空间分配避免了由于内部碎片导致的空间浪费，perhaps the greatest objection against such a large chunksize.
   较大的块大小有几个重要的优点。第一，由于读写都在同一个块操作只需要一次初始请求向master询问块位置信息，因此降低了client和master交互的次数。这种交互的降低对我们的工作就更有利了，因为我们的应用大多数情况下是连续的读写大文件。即使是小型的随即读操作，client也可以方便的将多个T的工作集的所有块位置信息缓存在起来。第二，块大小较大的话，client就可以在选定的块上进行较多的操作，这样可以降低保持与chunkserver长TCP连接的网络开销。第三，降低了master上元数据的大小。这就允许我们把所有的元数据存储在内存数，这一点来带的其他有点我们会在2.6.1节中讨论。
    另一方面，即使是 懒惰空间分配的大块大小也有其缺点。一个小文件由少数几个块组成，甚至就由一个块组成。如果许多client都要访问这样的一个文件，这存储这些块的chunkserver会成为“热点”。实际情况中，热点不会成为一个主要的问题，因为我们的应用程序大部分情况下都是连续的读多个块的文件。
   但是，当GFS最开始用在批队列(batch-queue)系统时，热点确实成为一个主要问题：一个执行程序作为含单个块的文件写到GFS中，并却同时在几百个client上执行起来。少数几个存储了这个执行程序的chunkserver被数百个同时的请求撑爆了。我们通过用较高的复制因子存储这样的执行程序并却错开批队列应用程序的方法解决了这个问题。潜在的长期解决方案是允许client从其他clinet读数据。
2.6 元数据
  master存储三种主要的元数据：文件和块的命名空间，文件到块的映射关系和每个块的复制品的位置信息。所有的元数据都存储在master的内存中。前两种（命名空间和文件到块映射关系）也会被logging mutations永久的保存在master本地磁盘上的操作日志中，并被复制到远程的机器上。使用日志可以使我们简单、可靠的更新master状态，并且在master崩溃的时候没有不一致的情况。master不会持久的保存块的位置信息，而是在启动的时候或者chunkserver加入到集群的时候询问chunkserver它们的块信息。
2.6.1 内存中的数据结构
   由于元数据存储在内存中，因此master的操作都非常块。并且master可以简单高效的在后台定期扫描整个状态。定期扫描用来实现块垃圾回收，负载均衡用到块迁移，chunkserver的磁盘空间检查，4.3和4.4节会进一步讨论。
   内存存储方式的一个隐忧是系统的规模会受master内存容量的限制。实际情况下这不是一个严重的限制。master为每个64MB的块维护一个少于64字节的元数据。大部分文件包含多个块因此大部分块都是满的，只有每一个文件最后的块是部分满的。类似的，典型的文件命名空间中每个文件需要少于64字节的数据，因为对文件名进行使用前缀压缩。
   如果有必要支持更大的文件系统，相对与内存存储元数据带来的简单，可靠，高性能和灵活性来说，增加内存的代价是非常小的。
2.6.2 块位置信息

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/18578/showart_1190568.html