《google文件系统》由会员分享，可在线阅读，更多相关《google文件系统（12页珍藏版）》请在金锄头文库上搜索。
1、GoogleGoogle 文件系统文件系统Google 文件系统 GFS 是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，但可以提供容错功能。它可以给大量的用户提供总体性能较高的服务。 1、设计概览 （1）设计想定 GFS 与过去的分布式文件系统有很多相同的目标，但 GFS 的设计受到了当前及预期的应用方面的工作量及技术环境的驱动，这反映了它与早期的文件系统明显不同的设想。这就需要对传统的选择进行重新检验并进行完全不同的设计观点的探索。 GFS 与以往的文件系统的不同的观点如下： 1、部件错误不再被当作异常，而是将其作为常见的情况加以处理
2、。因为文件系统由成百上千个用于存储的机器构成，而这些机器是由廉价的普通部件组成并被大量的客户机访问。部件的数量和质量使得一些机器随时都有可能无法工作并且有一部分还可能无法恢复。所以实时地监控、错误检测、容错、自动恢复对系统来说必不可少。2、按照传统的标准，文件都非常大。长度达几个 GB 的文件是很平常的。每个文件通常包含很多应用对象。当经常要处理快速增长的、包含数以万计的对象、长度达 TB 的数据集时，我们很难管理成千上万的 KB 规模的文件块，即使底层文件系统提供支持。因此，设计中操作的参数、块的大小必须要重新考虑。对大型的文件的管理一定要能做到高效，对小型的文件也必须支持，但不必优化。 3
3、、大部分文件的更新是通过添加新数据完成的，而不是改变已存在的数据。在一个文件中随机的操作在实践中几乎不存在。一旦写完，文件就只可读，很多数据都有这些特性。一些数据可能组成一个大仓库以供数据分析程序扫描。有些是运行中的程序连续产生的数据流。有些是档案性质的数据，有些是在某个机器上产生、在另外一个机器上处理的中间数据。由于这些对大型文件的访问方式，添加操作成为性能优化和原子性保证的焦点。而在客户机中缓存数据块则失去了吸引力。 4、工作量主要由两种读操作构成：对大量数据的流方式的读操作和对少量数据的随机方式的读操作。在前一种读操作中，可能要读几百 KB，通常达 1MB 和更多。来自同一个客户的连续操
4、作通常会读文件的一个连续的区域。随机的读操作通常在一个随机的偏移处读几个 KB。性能敏感的应用程序通常将对少量数据的读操作进行分类并进行批处理以使得读操作稳定地向前推进，而不要让它来来回回的读。 5、工作量还包含许多对大量数据进行的、连续的、向文件添加数据的写操作。所写的数据的规模和读相似。一旦写完，文件很少改动。在随机位置对少量数据的写操作也支持，但不必非常高效。 6、系统必须高效地实现定义完好的大量客户同时向同一个文件的添加操作的语义。 （2）系统接口 GFS 提供了一个相似地文件系统界面，虽然它没有向 POSIX 那样实现标准的 API。文件在目录中按层次组织起来并由路径名标识。 （3）
5、体系结构： 一个 GFS 集群由一个 master 和大量的 chunkserver 构成，并被许多客户（Client）访问。如图 1 所示。Master 和 chunkserver 通常是运行用户层服务进程的 Linux 机器。只要资源和可靠性允许，chunkserver 和 client 可以运行在同一个机器上。 文件被分成固定大小的块。每个块由一个不变的、全局唯一的 64 位的 chunkhandle 标识，chunkhandle 是在块创建时由 master 分配的。ChunkServer 将块当作 Linux 文件存储在本地磁盘并可以读和写由 chunkhandle 和位区间指定的数
6、据。出于可靠性考虑，每一个块被复制到多个 chunkserver 上。默认情况下，保存 3 个副本，但这可以由用户指定。 Master 维护文件系统所以的元数据（metadata） ，包括名字空间、访问控制信息、从文件到块的映射以及块的当前位置。它也控制系统范围的活动，如块租约（lease）管理，孤儿块的垃圾收集，chunkserver 间的块迁移。Master 定期通过 HeartBeat 消息与每一个 chunkserver 通信，给 chunkserver 传递指令并收集它的状态。 与每个应用相联的 GFS 客户代码实现了文件系统的 API 并与 master和 chunkserver
7、通信以代表应用程序读和写数据。客户与 master 的交换只限于对元数据（metadata）的操作，所有数据方面的通信都直接和 chunkserver 联系。 客户和 chunkserver 都不缓存文件数据。因为用户缓存的益处微乎其微，这是由于数据太多或工作集太大而无法缓存。不缓存数据简化了客户程序和整个系统，因为不必考虑缓存的一致性问题。但用户缓存元数据（metadata） 。Chunkserver 也不必缓存文件，因为块时作为本地文件存储的。 （4）单 master。 只有一个 master 也极大的简化了设计并使得 master 可以根据全局情况作出先进的块放置和复制决定。但是我们必须
8、要将 master 对读和写的参与减至最少，这样它才不会成为系统的瓶颈。Client 从来不会从 master 读和写文件数据。Client 只是询问 master 它应该和哪个 chunkserver 联系。Client 在一段限定的时间内将这些信息缓存，在后续的操作中 Client 直接和 chunkserver 交互。 以图 1 解释一下一个简单的读操作的交互。 1、client 使用固定的块大小将应用程序指定的文件名和字节偏移转换成文件的一个块索引（chunk index） 。 2、给 master 发送一个包含文件名和块索引的请求。 3、master 回应对应的 chunk hand
9、le 和副本的位置（多个副本） 。 4、client 以文件名和块索引为键缓存这些信息。 （handle 和副本的位置） 。 5、Client 向其中一个副本发送一个请求，很可能是最近的一个副本。请求指定了 chunk handle（chunkserver 以 chunk handle 标识chunk）和块内的一个字节区间。 6、除非缓存的信息不再有效（cache for a limited time）或文件被重新打开，否则以后对同一个块的读操作不再需要 client 和master 间的交互。 通常 Client 可以在一个请求中询问多个 chunk 的地址，而 master也可以很快回应这
10、些请求。 （5）块规模： 块规模是设计中的一个关键参数。我们选择的是 64MB，这比一般的文件系统的块规模要大的多。每个块的副本作为一个普通的 Linux文件存储，在需要的时候可以扩展。 块规模较大的好处有： 1、减少 client 和 master 之间的交互。因为读写同一个块只是要在开始时向 master 请求块位置信息。对于读写大型文件这种减少尤为重要。即使对于访问少量数据的随机读操作也可以很方便的为一个规模达几个 TB 的工作集缓缓存块位置信息。 2、Client 在一个给定的块上很可能执行多个操作，和一个chunkserver 保持较长时间的 TCP 连接可以减少网络负载。 3、这减
11、少了 master 上保存的元数据（metadata）的规模，从而使得可以将 metadata 放在内存中。这又会带来一些别的好处。 不利的一面： 一个小文件可能只包含一个块，如果很多 Client 访问改文件的话，存储这些块的 chunkserver 将成为访问的热点。但在实际应用中，应用程序通常顺序地读包含多个块的文件，所以这不是一个主要问题。 （6）元数据（metadata）： master 存储了三中类型的 metadata：文件的名字空间和块的名字空间，从文件到块的映射，块的副本的位置。所有的 metadata 都放在内存中。前两种类型的 metadata 通过向操作日志登记修改而保
12、持不变，操作日志存储在 master 的本地磁盘并在几个远程机器上留有副本。使用日志使得我们可以很简单地、可靠地更新 master 的状态，即使在 master 崩溃的情况下也不会有不一致的问题。相反，mater在每次启动以及当有 chuankserver 加入的时候询问每个chunkserver 的所拥有的块的情况。 A、内存数据结构： 因为 metadata 存储在内存中，所以 master 的操作很快。进一步，master 可以轻易而且高效地定期在后台扫描它的整个状态。这种定期地扫描被用于实现块垃圾收集、chunkserver 出现故障时的副本复制、为平衡负载和磁盘空间而进行的块迁移。
13、这种方法的一个潜在的问题就是块的数量也即整个系统的容量是否受限与 master 的内存。实际上，这并不是一个严重的问题。Master为每个 64MB 的块维护的 metadata 不足 64 个字节。除了最后一块，文件所有的块都是满的。类似的，每个文件的名字空间数据也不足64 个字节，因为文件名是以一种事先确定的压缩方式存储的.如果要支持更大的文件系统，那么增加一些内存的方法对于我们将元数据（metadata）保存在内存种所获得的简单性、可靠性、高性能和灵活性来说，这只是一个很小的代价。 B、块位置： master 并不为 chunkserver 所拥有的块的副本的保存一个不变的记录。它在启动
14、时通过简单的查询来获得这些信息。Master 可以保持这些信息的更新，因为它控制所有块的放置并通过 HeartBeat 消息来监控 chunkserver 的状态。 这样做的好处：因为 chunkserver 可能加入或离开集群、改变路径名、崩溃、重启等，一个集群重有成百个 server，这些事件经常发生，这种方法就排除了 master 与 chunkserver 之间的同步问题。 另一个原因是：只有 chunkserver 才能确定它自己到底有哪些块，由于错误，chunkserver 中的一些块可能会很自然的消失，这样在master 中就没有必要为此保存一个不变的记录。 C、操作日志： 操作
15、日志包含了对 metadata 所作的修改的历史记录。它作为逻辑时间线定义了并发操作的执行顺序。文件、块以及它们的版本号都由它们被创建时的逻辑时间而唯一地、永久地被标识。 操作日志是如此的重要，我们必须要将它可靠地保存起来，并且只有在 metadata 的改变固定下来之后才将变化呈现给用户。所以我们将操作日志复制到数个远程的机器上，并且只有在将相应的日志记录写到本地和远程的磁盘上之后才回答用户的请求。 Master 可以用操作日志来恢复它的文件系统的状态。为了将启动时间减至最小，日志就必须要比较小。每当日志的长度增长到超过一定的规模后，master 就要检查它的状态，它可以从本地磁盘装入最近的
16、检查点来恢复状态。 创建一个检查点比较费时，master 的内部状态是以一种在创建一个检查点时并不耽误即将到来的修改操作的方式来组织的。Master 切换到一个新的日子文件并在一个单独的线程中创建检查点。这个新的检查点记录了切换前所有的修改。在一个有数十万文件的集群中用一分钟左右就能完成。创建完后， 将它写入本地和远程的磁盘。 （7）数据完整性 名字空间的修改必须是原子性的，它们只能有 master 处理：名字空间锁保证了操作的原子性和正确性，而 master 的操作日志在全局范围内定义了这些操作的顺序。 文件区间的状态在修改之后依赖于修改的类型，不论操作成功还是失败，也不论是不是并发操作。如果不论从哪个副本上读，所有的客户都看到同样的数据，那么文件的这个区域就是一致的。如果文件的区域是一致的并且用户可以看到修改操作所写的数据，那么它就是已定义的。如果修改是在没有并发写操作的影响下完成的，那么受影响的区域是已定义的，所有的 client 都能看到写的内容。成功的并发写操作是未定义但却是一致的。失败的修改将使区间处于不一致的状态。 Write 操作在应用程序指定的偏移处写入数据
