谷歌论文GFS中文版

所需积分/C币:22 2018-11-12 12:14:08 2.01MB PDF

我们设计并实现了Google GFS文件系统,一个面向大规模数据密集型应用的、可伸缩的分布式文件系统。GFS虽然运行在廉价的普遍硬件设备上,但是它依然了提供灾难冗余的能力,为大量客户机提供了高性能的服务
2.2接口 的。快照和记录追加操作将在3.4和3.3 GFS提供了一套类似传统文件系统的API接节分别讨论。 口函数,虽然并不是严格按照PsIX等标2.3架构 准API的形式实现的。文件以分层目录的 形式组织,用路径名来标识。我们支持常 个GS集群包含一个单独的 Master节 用的操作,如创建新文件、删除文件、打 (alex译者注:这里的一个单独的 Master节点的含义是GFS系统中只存在 开文件、关闭文件、读和写文件。 个逻辑上的 Master组件。后面我们还会提 另外,GFS提供了快照和记录追加操作。快 到 Master节点复制,因此,为了理解方 照以很低的成本创建一个文件或者目录树 便,我们把 Master节点视为一个逻辑上 的拷贝。记录追加操作允许多个客户端同 的概念,一个逻辑的 Master节点包括两台 时对一个文件进行数据追加操作,同时保物理主机,即两台 Master服务器)、多台 证每个客户端的追加操作都是原子性的 Chunk服务器,并且同时被多个客户端访 问,如图1所示。所有的这些机器通常都 这对」实现多路结果合并,以及”生产者 是普通的 Linux机器,运行着用户级别 消费者”队列非常有用,多个客户端可以 (user- Level)的服务进程。我们可以很容 在不需要额外的同步锁定的情况下,同时 易的把 Chunk服务器和客户端都放在同 对一个文件追加数据。我们发现这些类型 的文件对于构建大型分布应用是非常重要 台机器上,前提是机器资源允许,并且我 们能够接受不可靠的应用程序代码带来的 稳定性降低的风险。 Application file name, chunk index) GFS master /foo/bar GFS client File namespace chunk 2efo chunk handle chunk locations Legend Data messages Instructions to chunkserver Cantrol messages Chunkserver state (chunk handle byte range l GFS cluukserver GFS clunkserver chunk data Linux file system Linux file system Figure 1: GFS Architecture GFS存储的文件都被分割成固定大小的 Master节点管理所有的文件系统元数据 Chuk。在Chuk创建的时候, Master服务这些元数据包括名字空间、访问控制信 器会给每个 Chunk分配一个不变的、全球息、文件和 Chunk的映射信息、以及当前 唯一的64位的 Chunk标识。 Chunk服务器 Chunk的位置信息。 Master节点还管理着 把 Chunk以 linux文件的形式保存在本地系统范围内的活动,比如, Chunk租用管理 硬盘上,并且根据指定的Chnk标识和字(alex译者注:BDB也有关于 lease的描 节范围来读写块数据。出于可靠性的考 述,不知道是否相同)、孤儿 Chunk(alex 虑,每个块都公复制到多个块服务器上。 译者注: orphaned chunks)的回收、以及 缺省情况下,我们使用3个存储复制节 Chunk在 Chunk服务器之间的迁移。 Master 点,不过用户可以为不同的文件命名空间节点使用心跳信息周期地和每个 Chunk服 设定不同的复制级别。 务器通讯,发送指令到各个 Chunk服务器 并接收 Chunk服务器的状态信息。 GFS客户端代码以库的形式被链接到客户程之后客户端发送请求到其中的一个副本 序里。客户端代码实现∫GFS文件系统的处,一般会选择最近的。请求信息包含了 API接口函数、应用程序与 Master节点和 Chunk的标识和字节范围。在对这个 Chunk Chunk服务器通讯、以及对数据进行读写的后续读取操作中,客户端不必再和 操作。客户端和 Master节点的通信只获取 Master节点通讯了,除非缓存的元数据信 元数据,所有的数据操作都是由客户端直息过期或者文件被重新打开。实际上,客 接和 Chunk服务器进行交互的。我们不提户端通常会在一次请求中查询多个 Chunk 供 POSIX标准的API的功能,因此,GFS 信息, Master节点的回应也可能包含了紧 AP调用不需要深入到 Linux vnode级别。跟着这些被请求的 Chunk后面的 Chunk的 信息。在实际应用中,这些额外的信息在 无论是客户端还是 Chunk服务器都不需要没有任何代价的情况下,避免了客户端和 缓存文件数据。客户端缓存数据几乎没有 Master节点未来可能会发生的儿次通讯。 什么用处,因为大部分程序要么以流的方 式读取个巨大文件,要么L作集太大根 2.5 Chunk尺寸 本无法被缓存。无需考虑缓存相关的问题 Chunk的大小是关键的设计参数之。我们 也简化了客户端和整个系统的设计和实 选择了64MB,这个尺寸远远大于一般文件 现。(不过,客户端会缓存元数据。) 系统的B1 ock size。每个 Chunk的副本都 Chunk服务器不需要缓存文件数据的原因以普通 Linux文件的形式保存在 Chunk服 是, Chunk以本地文件的方式保存, Linux务器上,只有在需要的时候才扩大。惰性 操作系统的文件系统缓存会把经常访问的空间分配略避免了因内部悴片造成的空 数据缓存在内存中。 间浪费,内部碎片或许是对选择这么大的 2.4单一 Master节点 Chunk尺寸最具争议一点。 单一的 Master节点的策略大大简化了我们选择较大的 Chunk尺寸有几个重要的优 的设计。单的 Master节点可以通过全局点。首先,它减少了客户端和 Master节点 的信息精确定位 Chunk的位置以及进行复通讯的需求,因为只需要一次和 Mater节 刮决策。另外,我们必须减少对 Master 点的通信就可以获取 Chunk的位置信息 节点的读写,避免 Master节点成为系统的之后就可以对同一个 Chunk进行多次的读 瓶颈。客户端并不通过 Master节点读写文写操作。这种方式对降低我们的工作负载 件数据。反之,客户端向 Master节点询问米说效果显著,因为我们的应用程序通常 它应该联系的 Chunk服务器。客户端将这是连续读写大文件。即使是小规模的随机 些元数据信息缓存一段时间,后续的操作读取,采用较大的 Chunk尺寸也带来明显 将直接和 Chunk服务器进行数据读写操 的好处,客户端可以轻松的缓存一个数TB 作。 的工作数据集所有的 Chunk位置信息。其 次,采用较大的 Chunk尺寸,客户端能够 我们利用图1解释一下一次简单读取的流对一个块进行多次操作,这样就可以通过 程。首先,客户端把文件名和程序指定的与Chuk服务器保持较长时间的TCP连接 字节偏栘,根据固定的Chuκ大小,转换来减少网终负载。第三,选用较大的 成文件的 Chunk索引。然后,它把文件名 Chunk尺寸减少了 Master节点需要保存的 和 Chunk索引发送给 Master节点 Master元数据的数量。这就允许我们把元数据全 节点将相应的 Chunk标识和副本的位置信部放在内存中,在2.6.1节我们会讨论元 息发还给客户端。客户端用文件名和 数据全部放在内存中带来的额外的好处。 Chunk索引作为key缓存这些信息 另一方面,即使配合惰性空间分配,采用2.6.1内存中的数据结构 较大的 Chunk尺寸也有其缺陷。小文件包 因为元数据保存在内存中,所以 Master服 含较少的 Chunk,甚至只有一个 Chunk。当 务器的操作速度非常快。并且, Master服 有许多的客户端对同一个小文件进行多次务器可以在后台简单而高效的周期性扌描 的访问时,存储这些 Chunk的 Chunk服务 自己保存的全部状态信息。这种周期性的 器就会变成热点。在灾际应用中,由于我 状态扫描也用于实现 Chunk垃圾收集、在 们的程序通常是连续的读取包含多个 hunk服务器失效的时重新复制数据、通过 Chunk的大文件,热点还不是主要的问题。 hunk的迁移实现跨 Chunk服务器的负载 均衡以及磁盘使用状况统计等功能。4.3 然而,当我们第次把GS用于批处理队 和4.4章节将深入讨论这些行为。 列系统的时候,热点的问题还是产生了: 一个可执行文件在GFS上保存为 single 将元数据全部保存在内存中的方法有潜在 chunk文件,之后这个可执行文件在数百 问题: Chunk的数量以及整个系统的承载能 台机器上同时启动。存放这个可执行文件 力都受限于 Master服务器所拥有的内存大 的几个Chun服务器被数百个客户端的并小。但是在实你应用中,这并不是一个严 发请求访问导致系统局部过载。我们通过重的问题。 Master服务器只需要不到64个 使用更大的复制参数来保存可执行文件 宇节的元数据就能够管理个64MB的 以及错廾批处理队列系统程序的启动时间 Chunl。由于大多数文件都包含多个 的方法解决了这个问题。一个可能的长效 Chunk,因此绝大多数 Chunk都是满的,除 解决方案是,在这种的情况下,允许客户 ∫文件的最后一个 Chunk是部分填充的。 端从其它客户端读取数据 同样的,每个文件的在命名空间中的数据 2.6元数据 大小通常在64字节以下,因为保存的文 件名是用前缀压缩算法压缩过的 Master服务器(alex译者注:注意逻辑 的 Master节点和物理的 Master服务器的 即便是需要支持更大的文件系统,为 区别。后续我们谈的是每个 Master服务器 Master服务器增加额外内存的费用是很少 的行为,如存储、内存等等,因此我们将 的,而通过增加有限的费用,我们就能够 全部使用物理名称)存储3种主要类型的把元数据全部保存在内存里,增强了系统 元数据,包括:文件和 Chunk的命名空 的简洁性、可靠性、高性能和灵活性。 间、文件和 Chunk的对应关系、每个 Chunk 副本的存放地点。所有的元数据都保存在 2.6.2 Chunk位置信息 Master服务器的内存中。前两种类型的元 Master服务器并不保存持久化保存哪个 数据(命名空间、文件和 Chunk的对应关 Chunk服务器存有指定 Chunk的副本的信 系)同时也会以记录变更日志的方式记录息。 Master服务器只是在启动的时候轮询 在操作系统的系统日志文件中,日志文件 hunk服务器以获取这些信息。 Master服 存储在本地磁盘上,同时日志会被复制到务器能够保证它持有的信息始终是最新 其它的远程 Master服务器上。采用保存变 的,因为它控制了所有的 Chunk位置的分 更日志的方式,我们能够简单可靠的更新 配,而且通过周期性的心跳信息监控 Master服务器的状态,并且不用担心 Chunk服务器的状态。 Master服务器崩溃导致数据不一致的风 险。 Master服务器不会持久保存 Chunk位最初设计时,我们试图把 Chunk的位置信 置信息。 Master服务器在启动时,或者有息持久的保存在 Master服务器上,但是后 新的 Chunk服务器加入时,向各个 Chunk来我们发现在启动的时候轮询 Chunk服务 服务器轮询它们所存储的 Chunk的信息。 器,之后定期轮询更新的方式更简单。这 种设计简化了在有 Chunk服务器加入集 作的日志量尽量的少)。 Master服务器在 群、离开集群、更名、失效、以及重启的忐增长到一定量时对系统状态做一次 时侯, Master服务器和 Chunk服务器数据 Checkpoint(alex译者注: Checkpoint是 同步的问题。在一个拥有数百台服务器的种行为,一种对数据库状态作一次快照 集群中,这类事件会频繁的发生。 的行为),将所有的状态数据写入个 Checkpoint文件(alex译者注:并删除 可以从另外一个角度去理解这个设计决 之前的日志文件)。在灾难恢复的时候, 策:只有 Chunk服务器才能最终确定一个 Master服务器就通过从伭盘上读取这个 Chunk是否在它的硬盘上。我们从没有考虑 Checkpoint文件,以及重演 Checkpoint之 过在 Master服务器上维护一个这些信息后的有艰个日志文件就能够恢复系统。 的全局视图,因为Chuk服务器的错误可 Checkpoint文件以压缩B-树形势的数据结 能会导致 Chunk自动消失(比如,硬盘损坏 构存储,可以直接映射到内存,在用于命 了或者无法访问了),亦或者操作人员可能名空间查询时无需额外的解析。这大大提 会重命名一个 Chunk服务器 高了恢复速度,增强了可用性。 2.6.3操作日志 操作日志包含了关键的元数据变更历史记 由于创建一个 Checkpoint文件需要一定的 录。这对GFS非常重要。这不仅仅是因为 时间,所以 Master服务器的内部状态被组 操作口志是元数据唯·的持久化存储记 织为一和式,这种格式要确保在 录,它也作为判断同步操作顺序的逻辑时 Checkpoint过程中不会阻塞正在进行的修 间基线(a1ex译者注:也就是通过逻辑日 改操作。 Master服务器使用独立的线程切 志的序号作为操作发生的逻辑时间,类似 换到新的日忐文件和创建新的 Checkpoint 于事务系统中的LSN)。文件和 Chunk,连文件。新的 Checkpoint文件包括切换前所 同它们的版本(参考4.5节),都由它们创 有的修改。对于一个包含数百万个文件的 建的逻辑时间唯一的、永久的标识。 集群,创建个 Checkpoint文件需要1分 钟左右的时间。创建完成后, Checkpoint 文件会被写入在本地和远程的硬盘里。 操作日志非常重要,我们必确保日志文 件的完整,确保只有在元数据的变化被持 久化后,日志才对客户端是可见的。否 Master服务器恢复只需要最新的 則,即使 Chunk本身没有出现任何问题, Checkpoint文件和后续的日志文件。旧的 我们仍有可能丢失整个文件系统,或者丢 Checkpoint文件和日志文件可以被删除, 失客户端最近的操作。所以,我们会把日 但是为了应对灾难性的放障(alex译者 志复制到多台远程机器,并且只有把相应 注: catastrophes,数据备份相关文档中 的日志记录写入到本地以及远程机器的硬 经常会遇到这个词,表示一种超出预期范 盘后,才会响应客户端的操作请求 围的灾难性事件),我们通常会多保存 Master服务器会收集多个日志记录后批量 些历史文件。 Checkpoint失败不会对正确 处理,以减少写入憾盘和复制对系统整体 性产生任何影响,因为恢复功能的代码可 性能的景响。 以检测并跳过没有完成的 Checkpoint文 件 Master服务器在灾难恢复时,通过重演操 作日忐把文件系统恢复到最近的状态。为 2.7一致性模型 了缩短 Master启动的时间,我们必须使日GFS支持一个宽松的一致性模型,这个模型 志足够小(alex译者注:即重演系统操能够很好的支撑我们的高度分布的应用, 同时还保持了相对简单且容易实现的优 文件命名空间的修改(例如,文件创建) 点。本节我们讨论GFS的一致性的保障机是原子性的。它们仅由 Master节点的控 制,以及对应用程序的意义。我们也着重制:命名空间锁提供∫原子性和正确性 描述了GFS如何管理这些一致性保障机 (4.1章)的保障; Master节点的操作日 制,但是实现的细节将在本论文的其它部志定义了这些操作在全局的顺序(2.6.3 分讨论。 章) 2.7.1GFS一致性保障机制 写 记录追力 牛行成功已定义 已定义 井行成功致但是末定义 部分不致 失败 不一数 表1操作后的文件状态 数据修改后文件 region(alex译者注: 应用程序没有必要再去细分未定义 regIon region这个词用中文非常难以表达,我认的不同类型 为应该是修改操作所涉及的文件中的某个 范围)的状态取决于操作的类型、成功与数据修改操作分为写入或者记录追加两 合、以及是否步修改。表1总结了各种种。写入操作把数据写在应用程序指定的 操作的结果。如果所有客户端,无论从哪 文件偏移位置上。即使有多个修改操作并 个副本读取,读到的数据都样,那么我行执行时,记录追加操作至少可以把数据 们认为文件 region是“一致的”:如果原子性的追加到文件中一次,但是偏移位 对文件的数据修改之后, region是一致 置是由GFS选择的(3.3章)(alex译者 的,并且客户端能够看到写入操作全部的 注:这句话有点费解,其含义是所有的追 内容,那么这个 reglon是“已定义 加写入都会成功,但是有可能被执行了多 的”。当一个数据修改操作成功执行,并次,而且每次追加的文件偏移量由GF自 且没有受到同时执行的其它写入操作的干 己计算)。(相比而言,通常说的追加操 扰,那么影响的 region就是已定义的(隐作写的偏移位置是文件的尾部。)GFs返回 含了一敛性):所有的客户端都可以看到给客户端一个偏移量,表小了包含了写入 写入的内容。并行修改操作成功完成之 记录的、已定义的 reglon的起点。另 后, reglon处于致的、木定义的状态 夕,GS可能会在文件中间插入填充数据或 所有的客户端看到同样的数据,但是无法者重复记录。这些数据占据的文件 region 读到任何一次写入操作写入的数据。通常被认定是不一致的,这些数据通常比用户 情况下,文件 region内包含了来自多个修数据小的多。 改操作的、混杂的数据片段。失败的修改 操作导致一个 region处于不一致状态(同 时也是未定义的):不同的客户在不同的 时间会看到不同的数据。后面我们将描述 经过了一系列的成功的修改操作之后,GFS 确保被修改的文件 region是已定义的,并 应用如何区分已定义和未定义的 region 且包含最后一次修改操作写入的数据。GFS 通过以下措施确保上述行为:(a)对 Chunk的所有副本的修改操作顺序一致 使用GFS的应用程序可以利用一些简单技 (3.1章),(b)使用 Chunk的版本号来术实现这个宽松的一致性模型,这些技术 检测副本是否因为它所在的 Chunk服务器也用来实现一些其它的目标功能,包括 宕机(4.5章)而错过了修改操作而导致量采用追加写入而不是覆盖, 其失效。失效的副本不会再进行任何修改 checkpoint,自验证的写入操作,自标识 操作, Master服务器也不再返回这个 的记录。 Chunk副本的位置信息给客户端。它们会被 垃圾收集系统尽快回收 在实际应用中,我们所有的应用程序对文 件的写入操作都是尽量采用数据追加方 由于 Chunk位置信总会被客户端缓存,所式,而不是覆盖方式。种典型的应用, 以在信息刷新前,客户端有可能从一个失应用程序从头到尾写入数据,生成了一个 效的副本读取了数据。在缓存的超时时间 文件。写入所有数据之后,应用程序自动 和文件下一次被打开的时间之间存在一个将文件改名为一个永久保存的文件名,或 时间窗,文件再次被打开后会清除缓存中者周期性的作 Checkpoint,记录成功写入 与该文件有关的所有Cunk位置信息。而了多少数据。 Checkpoint文件可以包含程 且,由于我们的文件大多数都是只进行追序级别的校验和。 Readers仅校验并处理上 加操作的,所以,一个失效的副本通常返个 Checkpoint之后产生的文件 reglon,这 回一个提前结束的Chuk而不是过期的数些文件 regIonl的状态一定是凵定义的。这 据。当一个 Reader(alex译者注:本文 个方法满足了我们一致性和并发处理的要 中将用到两个专有名词, Reader和 求。追加写入比随机位置写入更加有效 Writer,分别表示执行GFs读取和写入操率,对应程序的失败处理更具有弹性。 作的程序)重新尝试并联络 Master服务器 Checkpoint可以让 Writer以渐进的方式重 寸,它就会立刻得到最新的 Chunk位置信 新开始,并且可以防止 Reader处理已经被 成功写入,但是从应用程序的角度来看还 并未完成的数据 即使在修改操作成功执行很长时间之后, 我们再来分析另一种典型的应用。许多应 组件的失效也可能损坏或者删除数据。GFS用程序并行的追加数据到同个文件,比 通过 Master服务器和所有 Chunk服务器的 如进行结果的合并或者是一个生产者-消费 定期“握手”来找到失效的 Chunk服务 者队列。记录追加方式的“至少一次追 器,并且使用 Check来校验数据是否损加”的特性保证了Wier的输出 坏(5.2章)。一旦发现问题,数据要尽快 Readers使用下面的方法来处理偶然性的填 利用有效的副木进行恢复(4.3章)。只 充数据和重复内容。 Writers在每条写入的 有当一个 Chunk的所有副本在GFS检测到 记录中都包含了额外的信息,例如 错误并采取应对措施之前全部丢失,这个 Checksum,用来验证它的有效性。 Reader Chunk才会不可逆转的丢失。在一般情况下 可以利用 Checksum识别和拋弃额外的填充 的反应时间(alex译者注:指 数据和记录片段。如果应用不能容忍偶尔 Master节点检测到错误并采取应对措施) 的重复内容(比如,如果这些重复数据触发 是几分钟。即使在这种情况下, Chunk也只了非幂等操作),可以用记录的唯一标识符 是不可用了,而不是损坏了:应用程序会 来过滤它们,这些唯一标识符通常用于命 收到明确的错误信息而不是损坏的数据。 名程序中处理的实体对象,例如web文 档。这些记录I/0功能(alex译者注: 2.7.2程序的实现 These functionalities for record I/0)(除」剔除重复数据)都包含在我们 的程序共享的库中,并且适用于 Google内 Chunk的所有更改操作进行序列化。所有的 部的其它的文件接口实现。所以,相同序副本都遵从这个序列进行修改操作。因 列的记录,加上一些偶尔出现的重复数 此,修改操作全局的顺序首先由 Master节 据,都被分发到 Reader了 选择的租约的顺序决定,然后由租约中 主 Chunk分配的序列号决定 3.系统交互 我们在设计这个系统时,一个重要的原则 设计租约机制的目的是为了最小化 Master 是最小化所有操作和 Master节点的交互。 节点的管理负担。租约的初始超时改置为 60秒。不过,只要 Chunk被修改了,主 带着这样的设计理念,我们现在描述一下 lunk就可以中请更长的租期,通常会得 客户机、 Master服务器和 Chunk服务器如 到 Master节点的确认并收到租约延长的时 何进行交互,以实现数据修改操作、原子 间。这些租约延长请求和批准的信息通常 的记录追加操作以及快照功能 都是附加在 Master节点和 Chunk服务器 3.1租约(1ease)和变更顺序 之间的心跳消息中来传递。有时 Master节 (alex译者注:1eae是数据库中的一个点会试图提前取消租约(例如, Master节 术语) 点想取消在一个已经被改名的文件上的修 改操作)。即使 Master节点和主 Chunk失 去联系,它仍然可以安全地在旧的租约到 变更是个会改变 Chunk内容或者元数据 期后和另外一个 Chunk副本签订新的租 的操作,比如写入操作或者记录追加操 约 作。变更操作会在 Chunk的所有副本上执 行。我们使用租约(1ease)札制来保持 多个副本间变更顺序的一致性。 Master节 在图2中,我们依据步骤编号,展现写入 点为 Chunk的个副本建立个租约,我 们把这个副本叫做主 Chunk。主 Chunk对 操作的控制流程 steD 1 Client Master Secondary Replica a Primary Replica d Control Secondary Data Replica b Figure 2: Write Control and Data Flow 1.客户机向 Master节点询问哪一个 用去理会哪个 Chunk服务器保存 Chunk服务器持有当前的租约,以 了主 Chunk。3.2章节会进步讨 及其它副本的位置。如果没有一个 论这点。 Chunk持有租约, Master节点就选 4.当所有的副本都确认接收到了数 择其中一个副木建立一个租约(这 据,客户机发送写请求到主Cunk 个步骤在图上没有显示) 服务器。这个请求标识了早前推送 Master节点将主 Chunk的标识符 到所有副本的数据。主 Chunk为接 以及其它副本(又称为 secondary 攸到的所有操作分配连续的序列 副本、二级副本)的位置返回给客 号,这些操作可能来自不同的客户 户机。客户机缓存这些数据以使 机,序列号保让了操作顺序执行。 后续的操作。只有在主 Chunk不可 它以序列号的顺序把操作应用到它 用,或者主 Chunk回复信息表明它 自己的本地状态中(alex译者 已不再持有租约的时候,客户机才 注:也就是在本地执行这些操 需要重新跟 Master节点联系 作,这句话按字面翻译有点费 3.客户机把数据推送到所有的副木 解,也许应该翻译为“它顺序执 上:。客户机可以以仟意的顺序推送 行这些操作,并更新自己的状 数据。 Chunk服务器接收到数据并 态”) 休存在它的内部LRU缓存中,一直 5.主 Chunk把写请求传递到所有的二 到数据被使用或者过期交换出 级副本。每个二级副本依照主 去。由于数据沇的网络传输负载非 Chunk分配的序列号以相同的顺序 常高,通过分离数据流和控制流, 执行这些操作。 我们可以基于网络拓扑情况对数据 6.所有的二级副本回复主 Chunk,它 流进行规划,提高系统性能,而不 们己经完成了操作

...展开详情

评论 下载该资源后可以进行评论 1

three_man 拜读一下。 多谢
2019-11-19
回复
img

关注 私信 TA的资源

上传资源赚积分,得勋章
最新资源