imtoken安卓版app软件|gfs是什么意思

作者： imtoken安卓版app软件

2024-03-13 23:14:21

三分钟带你弄懂GFS（Google File System）_gfs可以帮助google解决数据存储中的?-CSDN博客

三分钟带你弄懂GFS（Google File System）

最新推荐文章于 2022-10-27 15:45:52 发布

大湧

最新推荐文章于 2022-10-27 15:45:52 发布

阅读量4.5k

点赞数

分类专栏：

大话Hadoop

文章标签：

分布式

hadoop

gfs

本文链接：https://blog.csdn.net/HugeBrian/article/details/119357226

版权

大话Hadoop

专栏收录该内容

1 篇文章

0 订阅

订阅专栏

提示：预计阅读时间三分钟，该文章仅对GFS做了一的简略介绍，细节方面建议阅读原文。

文章目录

前言一、GFS是什么？1.1 简单介绍1.2 我们为什么需要阅读GFS的论文？1.3 GFS论文对业界有什么影响？

二、GFS尝试解决那些问题？三、GFS的架构（The big picture）是什么？1.单主模式2.元数据（Metadata）3.GFS的一致性保证其他要素：原子操作（Atomic Operations）块副本（Chunk replicas）

四、我从GFS中学到了什么？五、GFS的缺点是什么？References

前言

GFS是学习分布式系统的启蒙文章，可能小伙伴们见到三十几页的中文版论文会望而却步，或者见到15页的英文原版会因为语言问题而say no,那么今天我就用一篇三分钟的小文章带你初尝GFS的味道！原版和中文译文版的GFS论文分享链接放在文末，有需要的老铁们可以自行下载。

提示：以下是本篇文章正文内容，下面案例可供参考

一、GFS是什么？

1.1 简单介绍

这个问题说大也大，说小也小。GFS是Google File System的缩写，字面意义上就是Google的文件系统，技术层面上来讲，GFS是Google在2003年前后创建的可扩展分布式文件系统，用来满足 Google 不断扩展的数据处理需求。GFS 为大型网络和连接的节点提供容错、可靠性、可扩展性、可用性和性能。GFS 由多个由低成本商品硬件组件构建的存储系统组成。它经过优化以适应 Google 的不同数据使用和存储需求，例如其搜索引擎会生成大量必须存储的数据。在我看来这个系统最大的亮点有两个，一个是使用集群的概念，将硬件设施连接起来共同进行文件存储任务；另外一个是充分利用了现成服务器的优势，同时最大限度地减少了硬件弱点。

1.2 我们为什么需要阅读GFS的论文？

对学习分布式系统有莫大的帮助，因为这个系统的技术架构中吸纳了很多我们在分布式系统中反复提到的几个主题：并发性，容错，复制和一致性。GFS是当时一个在现实世界中完成构建并使用的系统，例如Google的MapReduce和BigTable这两个应用程序都搭建在这个系统上。这足以证明在当时那个年代中GFS是一个成功的分布式文件系统。这篇文章在技术层面写的其实不是很晦涩难懂，同时并不需要太多的前置知识就可以对GFS系统有一个很好地了解，因为作者从应用程序级别到网络级别的各种考虑细节都展示了出来。

1.3 GFS论文对业界有什么影响？

GFS比99%的用于学术研究的分布式系统都来的大，同时使用规模也更大。因为这是一个搭载了Google的应用程序的一个较为成熟的文件系统；由于Google的成功使用，导致行业内各大公司进行模仿使用，国内的TFS，BFS等其本质都借鉴了GFS的成功经验，也可以看成对GFS的一种致敬。展现了弱一致性（weak consistency）的成功使用。展现了sigle-master（单主）的成功使用。毫不夸张的说，在分布式这个领域，GFS是一个开天辟地的举措，所以是一篇值得拜读的文章。

二、GFS尝试解决那些问题？

因为Google的业务的发展，导致其内部的许多服务需要一个大规模、高性能的统一存储系统。对这个系统有四个要求：

全球化。这意味着任何客户端都可以访问（读写）任何文件，允许在不同的应用程序之间共享数据。支持在多台机器上自动分片大文件。这可以通过允许对每个文件快进行并行处理来提高性能，并且还可以处理无法放入单个磁盘的大文件。支持故障自动恢复。针对大文件的顺序访问以及最常见的读取和追加操作进行了优化。

特别的，作者对持续的高带宽（high sustained bandwidth）进行了GFS的优化，因为目标的应用程序需要以较高的速率批量处理数据，但是对于低延迟并不是必要的（因为GFS是典型的应用于内部服务的，而不是面向客户端的）。

三、GFS的架构（The big picture）是什么？

接下来让我们看看GFS的架构图。对此，作者总共做了三个主要的设计选择：1）选择仅使用一个主服务器（单主模式）2）选择仅将一些元数据存储在非易失性存储中，3）选择弱一致性保证。 GFS由单个主服务器和多个数据块服务器组成，并由多个客户端访问。文件被分成固定大小的64MB数据块。每一个数据块都有一个不可变且全局唯一的快处理程序，由主控服务器在创建块的时候分配的。默认情况下，每个文件块都会被复制到3个不同的块服务器上。

1.单主模式

主服务器维护所有文件系统元数据。这包括从文件到块的映射、块位置等。主节点还定期向块服务器发送 HeartBeat 消息以向其提供指令并收集其状态（图 1）。优点：极大地简化了 GFS 设计，因为单一主机可以使用全局知识做出复杂的块放置和复制决策。缺点： 1.单点故障。需要定期的将关键元数据检查点放到非易失性存储中。 2.可能是系统的性能瓶颈点。必须尽量减少主服务器参与读写的操作。

对于第二点，在架构图中我们可以发现，客户端从来不通过主服务器进行读取和写入文件数据。客户端会先询问主服务器他应该联系哪个块服务器，在限定的时间内缓存此信息（指应该联系的块服务器的信息），并直接与块服务器交互以进行读写操作。

2.元数据（Metadata）

元数据存储在主内存中，而数据存储在块服务器中。这使得主服务器操作非常快，并且还允许主服务器在后台通过其整个状态有效地执行定期扫描。周期性扫描用于实现块垃圾收集、块迁移等。

主服务器存储以下三种元数据：

文件和 Chunk 的命名空间。文件和 Chunk 的对应关系。每个 Chunk 副本的存放地点。

请注意，前两种类型的元数据通过将更改记录存储到主服务器本地磁盘上的操作日志中来保持持久性，并定期复制到远程机器。但是，主服务器不会持久存储块位置信息。相反，它会在主服务器启动时以及当有块服务器加入集群时询问每个块服务器关于它的块数据。这是因为块服务器是块位置和主要状态信息的权威数据源。

3.GFS的一致性保证

GFS提供了一种宽松的一致性模型，也可以称之为你弱一致性模型，它适用于Google的高度分布式应用程序，但是实现起来相对来说简单和高效。论文中作者描述了文件区域的两种状态。

如果所有客户端，无论从哪个副本读取，读到的数据都一样，那么我们认为文件 region 是“一致的”；如果对文件的数据修改之后，region 是一致的，并且客户端能够看到写入操作全部的内容，那么这个 region是“已定义的”。

其他要素：

原子操作（Atomic Operations）

GFS提供了一些原子操作。文件命名，空间修改例如文件创建都是原子性的，并且由主服务器专门处理。命名空间锁（Namespace locking）保证了原子性，主服务器的操作日志定义了这些操作的全局顺序。

与常规的写入操作或者最佳操作相比，GFS提供了记录追加操作，即使存在并发冲突的情况下，也能够保证要追加的数据至少以原子操作的方式执行一次，但以GFS选择的偏移量（offset）。GFS将会返回这个追加数据的偏移量给客户端。

块副本（Chunk replicas）

为了保证经过一系列的成功的mutations之后，文件区域（region）包括最后一次mutation的数据，GFS做了以下两个操作：1）通过指定一个主副本，以同样的顺序对块副本做mutation;2)使用块版本号来检测由于在块服务器关闭时错过了mutations而变得过时的任何副本。

过时的副本永远不会涉及到一个mutation或给客户端请求块位置。他们是最早被收集的垃圾。

四、我从GFS中学到了什么？

1.弱一致性在实际应用中也是可行的，但是需要搭配某种形式的应用程序级检查机制。 2. 分布式文件系统作为基础设施对于很多数据密集型应用程序非常有用。这也就印证了随着数据规模的日益扩大，为什么所有的大厂都会自研一套分布式文件系统了。 3. 如果我们将主服务器中的元数据与块服务器中的存储分开，并最小化客户端对主服务器的调用，那么单个主服务器模式是可行的。 4. 我们可以使用文件分块来实现并行操作。 5. 我们可以使用主副本块服务器对所有的副本的写入操作进行排序。

五、GFS的缺点是什么？

随着这么多年的发展，GFS早就进行了多次的更新换代，那么从现状考虑，当时的GFS的缺点是什么呢？

随着数据量的不断增加，原先的单主模式集群表现不如一开始那么好了。这很好理解，虽然GFS已经从设计层面减少了主服务器的操作压力，但是量变引起质变，随着数据量发生数量级层次的变化，主服务器的工作量也会大幅增加，保存所有信息所需要的存储量也在增加，所以对于大数据状态下的分布式系统，单主模式是注定要被淘汰的。GFS使用的一致性模型在现在的运用中可能过于宽松了，因为这是一种弱一致性模型，在并行量增加的时候出错的概率会大大增加。当时的系统缺少自动转移到主副本（master replica）的操作。工程师过去不得不手动执行主状态的负载检查点和故障转移。这是缓慢和低效的。所以将此过程自动化是必要的。

希望我的文章对大家理解GFS有一定帮助。

References

[1] Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung (2003). The Google File System. https://pdos.csail.mit.edu/6.824/papers/gfs.pdf

[2] GFS: Evolution on Fast-forward (2009) https://queue.acm.org/detail.cfm?id=1594206

优惠劵

大湧

关注

踩

觉得还不错?

一键收藏

知道了

三分钟带你弄懂GFS（Google File System）

提示：预计阅读时间三分钟，该文章仅对GFS做了一的简略介绍，细节方面建议阅读原文。文章目录前言一、GFS是什么？1.1 简单介绍1.2 我们为什么需要阅读GFS的论文？1.3 2003年至今，GFS论文对世界的影响二、GFS尝试解决那些问题？1.引入库2.读入数据总结前言GFS是学习分布式系统的启蒙文章，可能小伙伴们见到三十几页的中文版论文会望而却步，或者见到15页的英文原版会因为语言问题而say no,那么今天我就用一篇三分钟的小文章带你初尝GFS的味道！原版和中文译文版的GFS论文分享链接放在

复制链接

扫一扫

专栏目录

GFS简单介绍

weixin_45509275的博客

08-22

2119

GFS (google file system)

为什么要GFS？

GFS（Google file system）是能储存海量数据的大型分布式文件系统。因为数据量大，不可能单机储存，所以需要将文件分割成很多数据块chunk来进行分布式储存。这样利用很多廉价的机器就可以存储大量的数据。

GFS基本结构——GFS master、GFS chunkServer、client

GFS master（主服务器）、GFS chunkServer（数据块服务器）、client（客户端）三者可简单理解为图书馆关系。clie

GFS、MapReduce和BigTable：Google的三种大数据处理系统

大数据基础学习

06-26

4148

Google 在搜索引擎上所获得的巨大成功，很大程度上是由于采用了先进的大数据管理和处理技术。Google 的搜索引擎是针对搜索引擎所面临的日益膨胀的海量数据存储问题，以及在此之上的海量数据处理问题而设计的。

众所周知，Google 存储着世界上最庞大的信息量（数千亿个网页、数百亿张图片）。但是，Google 并未拥有任何超级计算机来处理各种数据和搜索，也未使用 EMC 磁盘阵列等高端存储设备来...

1 条评论

您还未登录，请先

后发表或查看评论

Google 引爆大数据时代的三篇论文-《GFS》、《BigTable》、《MapReduce》

果汁华的博客

02-08

5736

大数据起源于-谷歌，于2003年起发布一系列论文（大数据三驾马车）:

1. 《The Google File System 》

2. 《MapReduce: Simplified Data Processing onLarge Clusters》

3.《Bigtable: A Distributed Storage System for Structured Data》

1 、GFS

GFS 是一个大型的分布式文件系统，为 Google 大数据处理系统提供海量存储，并且与 Ma...

GFS(Google File System)架构

02-27

GFS的架构，体现了很多经典的设计实践：

• 简化系统角色，单点master降低系统复杂度

• 不管是文件还是服务，均通过“冗余+故障自动转移”保证高可用

• 由于存在单点master，GFS将“降低与单点master的交互”作为性能优化核心

• 通过写日志，原子修改，checksum，快速监控快速恢复等方式保证可靠性与完整性

• 通过串行化保证多个副本数据的一致性

• 控制流与数据流分离，提高性能

The Google File System中文版.docx

08-20

The Google File System中文版.docx

Google+File+System中文版

12-20

我们设计并实现了Google GFS文件系统，一个面向大规模数据密集型应用的、可伸缩的分布式文件系统。GFS虽然运行在廉价的普遍硬件设备上，但是它依然了提供灾难冗余的能力，为大量客户机提供了高性能的服务。

The Google File System中文版

10-05

The Google File System中文版，google分布式文件系统中文翻译

GlusterFS 分布式文件系统

不要因为走的太远而忘了为什么出发

11-16

2413

目录引言一、文件系统简介1. 组成2. 作用3. 文件系统的挂载使用二、GFS 分布式文件系统概述1. GFS 简介2. GFS 的特点3. GFS 专业术语4. 模块化堆栈式架构5. GFS 工作流程6. 各服务器详解三、GFS 卷类型1. 分布式卷（Distribute volume）1.2 分布式卷示例原理1.3 分布式卷特点1.4 创建分布式卷2. 条带卷（Stripe volume）2.1 条带卷示例原理2.2 条带卷特点2.3创建条带卷3. 复制卷（Replica volume）3.1 复制卷

GFS分布式文件系统---------值的拥有的可扩展的分布式文件系统，大企业用了都说好

ljj的学习笔记

03-06

1977

一、GlusterFS简介

开源的分布式文件系统

由存储服务器、客户端以及NFS/Samba 存储网关组成

无元数据服务器

FS：文件系统

文件系统组成：

1、文件系统接口

2、对对像管理的软件集合

3、对象及属性

二、GlusterFS特点

扩展性和高性能

高可用性

全局统一命名空间

弹性卷管理

基于标准协议

三、GlusterFS术语

1、Brick（块存储服务器）实际存储用户数据的服务器

2、Volume本地文件系统的"分区"

3、FUSE用户空间的文件系统（类别EXT4），”这是一个伪文件系统“，用

分布式文件系统(GFS和HDFS)概述

Tyler_Zx的博客

11-24

1万+

前言

背景意义

分布式存储相关概念

分布式存储系统的分类

CAP理论

复制副本

一致性

GFS架构

租约（lease）和变更顺序

容错机制

前言

因为我有一门分布式的课，老师要求我们选择一个课题做汇报，有GFS、Hadoop、Bigtable、MapReduce、C...

【分布式系统】GFS(Google File System )详解

Yaoman753的博客

03-28

8729

GFS

是什么？

GFS是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，并提供容错功能。它可以给大量的用户提供总体性能较高的服务。

为什么要用GFS?

大量数据的存储会面临很多的难点：

大数据下需要良好的表现就需要分片和容错。在具体操作过程中，涉及到容错一般使用副本来解决，然而副本的使用会面临不一致问题。如果有一致性的要求，就会导致表现降低。

所谓的一致性，就是在集群中表现的像与一台机器或一个副本进行交互那样

因为GFS不但是一个理论成熟的框架结构

GFS.rar_.gfs_Google File System_gfs_google GFS

09-22

Google File System 的英文文档，Google所有应用的基础。

云存储-Google的云存储技术细节 GFS

02-22

3454

云存储和云计算的出现是在信息海量存储和处理的需求下产生的，所以是否是真正的云，首先要解决存储和计算的问题。

一：云存储

采用类似Key/value模式和Schema Free列表模式属于抽象化的数据模型，在转向商业应用的实际过程中，需要解决目前的流行系统所能够完成的可能性问题；

PC机可以Linux,Windows,Mac,但是后两者都难以承担作为廉价集群的任务，更适合作为用户

Google 文件系统

m0_59369922的博客

10-27

1107

作为云计算的一篇读书笔记，记录了Google文件系统的一些架构和原理。

云计算（1.1）Google云计算三大核心技术 - 分布式文件系统GFS

key_768的博客

02-17

5872

前言

Google云计算有三大核心技术：分布式文件系统GFS、

分布式处理模型MapReduce、分布式结构化表Bigtable

GFS

Google File System(GFS)

存储海量数据的分布式文件系统

GFS是基于数据块存储的大型分布式文件存储系统

分布式存储系统

分布式存储系统，是将数据分散存储在多台独立的设备上

传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系...

Google大数据技术栈

weixin_45607075的博客

09-19

756

Google大数据技术栈

1.数据存储层

GFS[GGL03]:Google文件系统（Google File System)是一个分布式文件系统，具有良好的容错性、扩展性和可用性，尤其是容错性表现突出，这使得GFS可构建在大量普通廉价机器上，进而容易进行”scale out“（横向扩展），相比于传统的”scale up“（向上扩展）方案中采用的大型机或小型机等，大大降低了成本。

BigTable[...

GFS：Google文件系统

qq_27639777的博客

08-22

1138

文章目录摘要分类和主题描述通用术语关键词1. 简介2. 设计概览2.1 假设2.2 接口2.3 架构2.4 单一Master2.5 块大小2.6 元数据2.6.1 内存数据结构2.6.2 块位置2.6.3 操作日志2.7 一致性模型2.7.1 GFS的一致性保证2.7.2 对应用的影响3. 系统交互3.1 租约和变化顺序3.2 数据流3.3 原子的记录追加3.4 快照4. master操作4.1 ...

Google——Google File System（GFS）

硅谷之路9：深入浅出理解GFS - 知乎

硅谷之路9：深入浅出理解GFS - 知乎首发于BitTiger.io切换模式写文章登录/注册硅谷之路9：深入浅出理解GFSMingche Su软件工程师/大数据1. GFS是什么GFS，顾名思义就是谷歌文件系统，和Big Table，Map Reduce并称谷歌三驾马车。大部分谷歌服务的基石（Search, Cloud Drive, Gmail etc.）。2. GFS 为什么这么火提供了容错机制，使得分布式文件系统可以在廉价机器上运行自动负载均衡把当时的一个技术难题解决方案免费公布出来3. GFS 怎么实现的要了解GFS我们先来看看普通的Linux文件系统怎么工作的。如果我们要存一个大文件怎么办呢GFS也是同样的原理，只是把MetaData放Master Server，然后Chunk都放到ChunkServer里面值得一提的是这里Master只保存了Chunk在各个服务器的地址，这样做的优点是4.GFS容错机制之前我们说了GFS的容错机制很棒，具体是怎么实现的呢。简单的说就是读数据时检查checksum如果数据损坏的话呢，Chunk Server就找Master恢复数据同时发送心跳检查Chunk Server是否运行正常。如果有服务器挂掉的话就向Master申请恢复5. 核心读写操作好了，我们构建这么一个庞大的系统最后不就是要读和写嘛，现在我们看看GFS是如何读写的。读数据时Client先向Master要到Chunk信息，然后去ChunkServer取数据写文件的时候呢，也是先找到Master Server要到信息，然后找到距离最近的Chunk Server。由其带领其他ChunkServer一起写数据。如果图中有任何一步出现错误则中止写入，返回错误。查看完整视频：http://www.bittiger.io/classpage/QPQAy2DFkqLwHBS4K整理作者：Xinxin Huang, 更多精彩内容，请扫描下面二维码，关注微信公众账号“论码农的自我修养”编辑于 2016-04-14 11:34Google File System文件系统谷歌 (Google)赞同 583 条评论分享喜欢收藏申请转载文章被以下专栏收录BitTiger.io来自硅谷的终身学

GFS（Google 文件系统）_百度百科

Google 文件系统）_百度百科网页新闻贴吧知道网盘图片视频地图文库资讯采购百科百度首页登录注册进入词条全站搜索帮助首页秒懂百科特色百科知识专题加入百科百科团队权威合作下载百科APP个人中心GFS是一个多义词，请在下列义项上选择浏览（共2个义项）添加义项收藏查看我的收藏0有用+10GFS播报讨论上传视频Google 文件系统GFS是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，并提供容错功能。它可以给大量的用户提供总体性能较高的服务。目录1设计概览2GFS架构3系统交互4MASTER操作5容错和诊断6测量GFS 也就是 google File System，Google公司为了存储海量搜索数据而设计的专用文件系统。设计概览播报编辑⑴设计想定 GFS与过去的分布式文件系统有很多相同的目标，但GFS的设计受到了当前及预期的应用方面的工作量及技术环境的驱动，这反映了它与早期的文件系统明显不同的设想。这就需要对传统的选择进行重新检验并进行完全不同的设计观点的探索。GFS与以往的文件系统的不同的观点如下：⒈ 部件错误不再被当作异常，而是将其作为常见的情况加以处理。因为文件系统由成百上千个用于存储的机器构成，而这些机器是由廉价的普通部件组成并被大量的客户机访问。部件的数量和质量使得一些机器随时都有可能无法工作并且有一部分还可能无法恢复。所以实时地监控、错误检测、容错、自动恢复对系统来说必不可少。⒉按照传统的标准，文件都非常大。长度达几个GB的文件是很平常的。每个文件通常包含很多应用对象。当经常要处理快速增长的、包含数以万计的对象、长度达TB的数据集时，我们很难管理成千上万的KB规模的文件块，即使底层文件系统提供支持。因此，设计中操作的参数、块的大小必须要重新考虑。对大型的文件的管理一定要能做到高效，对小型的文件也必须支持，但不必优化。⒊大部分文件的更新是通过添加新数据完成的，而不是改变已存在的数据。在一个文件中随机的操作在实践中几乎不存在。一旦写完，文件就只可读，很多数据都有这些特性。一些数据可能组成一个大仓库以供数据分析程序扫描。有些是运行中的程序连续产生的数据流。有些是档案性质的数据，有些是在某个机器上产生、在另外一个机器上处理的中间数据。由于这些对大型文件的访问方式，添加操作成为性能优化和原子性保证的焦点。而在客户机中缓存数据块则失去了吸引力。⒋工作量主要由两种读操作构成：对大量数据的流方式的读操作和对少量数据的随机方式的读操作。在前一种读操作中，可能要读几百KB，通常达 1MB和更多。来自同一个客户的连续操作通常会读文件的一个连续的区域。随机的读操作通常在一个随机的偏移处读几个KB。性能敏感的应用程序通常将对少量数据的读操作进行分类并进行批处理以使得读操作稳定地向前推进，而不要让它来反反复复地读。⒌工作量还包含许多对大量数据进行的、连续的、向文件添加数据的写操作。所写的数据的规模和读相似。一旦写完，文件很少改动。在随机位置对少量数据的写操作也支持，但不必非常高效。⒍系统必须高效地实现定义完好的大量客户同时向同一个文件的添加操作的语义。7.高可持续带宽比低延迟更重要⑵系统接口 GFS提供了一个相似地文件系统界面，虽然它没有像POSⅨ那样实现标准的API。文件在目录中按层次组织起来并由路径名标识。⑶体系结构一个GFS集群由一个master和大量的chunkserver构成，并被许多客户（Client）访问。如图1所示。Master和 chunkserver通常是运行用户层服务进程的Linux机器。只要资源和可靠性允许，chunkserver和client可以运行在同一个机器上。文件被分成固定大小的块。每个块由一个不变的、全局唯一的64位的chunk－handle标识，chunk－handle是在块创建时由 master分配的。ChunkServer将块当作Linux文件存储在本地磁盘并可以读和写由chunk－handle和位区间指定的数据。出于可靠性考虑，每一个块被复制到多个chunkserver上。默认情况下，保存3个副本，但这可以由用户指定。Master维护文件系统所有的元数据（metadata），包括名字空间、访问控制信息、从文件到块的映射以及块的当前位置。它也控制系统范围的活动，如块租约（lease）管理，孤儿块的垃圾收集，chunkserver间的块迁移。Master定期通过HeartBeat消息与每一个 chunkserver通信，给chunkserver传递指令并收集它的状态。与每个应用相联的GFS客户代码实现了文件系统的API并与master和chunkserver通信以代表应用程序读和写数据。客户与master的交换只限于对元数据（metadata）的操作，所有数据方面的通信都直接和chunkserver联系。客户和chunkserver都不缓存文件数据。因为用户缓存的益处微乎其微，这是由于数据太多或工作集太大而无法缓存。不缓存数据简化了客户程序和整个系统，因为不必考虑缓存的一致性问题。但用户缓存元数据（metadata）。Chunkserver也不必缓存文件，因为块是作为本地文件存储的。GFS架构播报编辑GFS的新颖之处并不在于它采用了多么令人惊讶的新技术，而在于它采用廉价的商用计算机集群构建分布式文件系统，在降低成本的同时经受了实际应用的考验。如上图所示，一个GFS包括一个主服务器（master）和多个块服务器（chunk server），这样一个GFS能够同时为多个客户端应用程序（Application）提供文件服务。文件被划分为固定的块，由主服务器安排存放到块服务器的本地硬盘上。主服务器会记录存放位置等数据，并负责维护和管理文件系统，包括块的租用、垃圾块的回收以及块在不同块服务器之间的迁移。此外，主服务器还周期性地与每个块服务器通过消息交互，以监视运行状态或下达命令。应用程序通过与主服务器和块服务器的交互来实现对应用数据的读写，应用与主服务器之间的交互仅限于元数据，也就是一些控制数据，其他的数据操作都是直接与块服务器交互的。这种控制与业务相分离的架构，在互联网产品方案上较为广泛，也较为成功。⑷单master 只有一个master也极大的简化了设计并使得master可以根据全局情况作出精密的块放置和复制决定。但是我们必须要将master对读和写的参与减至最少，这样它才不会成为系统的瓶颈。Client从来不会从master读和写文件数据。Client只是询问master它应该和哪个 chunkserver联系。Client在一段限定的时间内将这些信息缓存，在后续的操作中Client直接和chunkserver交互。以图1解释一下一个简单的读操作的交互。⒈client使用固定的块大小将应用程序指定的文件名和字节偏移转换成文件的一个块索引（chunk index）。⒉给master发送一个包含文件名和块索引的请求。⒊master回应对应的chunk handle和副本的位置（多个副本）。⒋client以文件名和块索引为键缓存这些信息。（handle和副本的位置）。⒌Client 向其中一个副本发送一个请求，很可能是最近的一个副本。请求指定了chunk handle（chunkserver以chunk handle标识chunk）和块内的一个字节区间。⒍除非缓存的信息不再有效（cache for a limited time）或文件被重新打开，否则以后对同一个块的读操作不再需要client和master间的交互。通常Client可以在一个请求中询问多个chunk的地址，而master也可以很快回应这些请求。⑸块规模块规模是设计中的一个关键参数。我们选择的是64MB，这比一般的文件系统的块规模要大的多。每个块的副本作为一个普通的Linux文件存储，在需要的时候可以扩展。块规模较大的好处有：⒈减少client和master之间的交互。因为读写同一个块只是要在开始时向master请求块位置信息。对于读写大型文件这种减少尤为重要。即使对于访问少量数据的随机读操作也可以很方便的为一个规模达几个TB的工作集缓缓存块位置信息。⒉Client在一个给定的块上很可能执行多个操作，和一个chunkserver保持较长时间的TCP连接可以减少网络负载。⒊这减少了master上保存的元数据（metadata）的规模，从而使得可以将metadata放在内存中。这又会带来一些别的好处。不利的一面：一个小文件可能只包含一个块，如果很多Client访问该文件的话，存储这些块的chunkserver将成为访问的热点。但在实际应用中，应用程序通常顺序地读包含多个块的文件，所以这不是一个主要问题。⑹元数据（metadata） master 存储了三种类型的metadata：文件的名字空间和块的名字空间，从文件到块的映射，块的副本的位置。所有的metadata都放在内存中。前两种类型的metadata通过向操作日志登记修改而保持不变，操作日志存储在master的本地磁盘并在几个远程机器上留有副本。使用日志使得我们可以很简单地、可靠地更新master的状态，即使在master崩溃的情况下也不会有不一致的问题。相反，master在每次启动以及当有 chunkserver加入的时候询问每个chunkserver的所拥有的块的情况。A、内存数据结构：因为metadata存储在内存中，所以master的操作很快。进一步，master可以轻易而且高效地定期在后台扫描它的整个状态。这种定期地扫描被用于实现块垃圾收集、chunkserver出现故障时的副本复制、为平衡负载和磁盘空间而进行的块迁移。这种方法的一个潜在的问题就是块的数量也即整个系统的容量是否受限与master的内存。实际上，这并不是一个严重的问题。Master为每个 64MB的块维护的metadata不足64个字节。除了最后一块，文件所有的块都是满的。类似的，每个文件的名字空间数据也不足64个字节，因为文件名是以一种事先确定的压缩方式存储的.如果要支持更大的文件系统，那么增加一些内存的方法对于我们将元数据（metadata）保存在内存中所获得的简单性、可靠性、高性能和灵活性来说，这只是一个很小的代价。B、块位置：master并不为chunkserver所拥有的块的副本的保存一个不变的记录。它在启动时通过简单的查询来获得这些信息。Master可以保持这些信息的更新，因为它控制所有块的放置并通过HeartBeat消息来监控chunkserver的状态。这样做的好处：因为chunkserver可能加入或离开集群、改变路径名、崩溃、重启等，一个集群中有成百个server，这些事件经常发生，这种方法就排除了master与chunkserver之间的同步问题。另一个原因是：只有chunkserver才能确定它自己到底有哪些块，由于错误，chunkserver中的一些块可能会很自然的消失，这样在master中就没有必要为此保存一个不变的记录。C、操作日志：操作日志包含了对metadata所作的修改的历史记录。它作为逻辑时间线定义了并发操作的执行顺序。文件、块以及它们的版本号都由它们被创建时的逻辑时间而唯一地、永久地被标识。操作日志是如此的重要，我们必须要将它可靠地保存起来，并且只有在metadata的改变固定下来之后才将变化呈现给用户。所以我们将操作日志复制到数个远程的机器上，并且只有在将相应的日志记录写到本地和远程的磁盘上之后才回答用户的请求。Master可以用操作日志来恢复它的文件系统的状态。为了将启动时间减至最小，日志就必须要比较小。每当日志的长度增长到超过一定的规模后，master就要检查它的状态，它可以从本地磁盘装入最近的检查点来恢复状态。创建一个检查点比较费时，master的内部状态是以一种在创建一个检查点时并不耽误即将到来的修改操作的方式来组织的。Master切换到一个新的日志文件并在一个单独的线程中创建检查点。这个新的检查点记录了切换前所有的修改。在一个有数十万文件的集群中用一分钟左右就能完成。创建完后，将它写入本地和远程的磁盘。⑺数据完整性名字空间的修改必须是原子性的，它们只能有master处理：名字空间锁保证了操作的原子性和正确性，而master的操作日志在全局范围内定义了这些操作的顺序。文件区间的状态在修改之后依赖于修改的类型，不论操作成功还是失败，也不论是不是并发操作。如果不论从哪个副本上读，所有的客户都看到同样的数据，那么文件的这个区域就是一致的。如果文件的区域是一致的并且用户可以看到修改操作所写的数据，那么它就是已定义的。如果修改是在没有并发写操作的影响下完成的，那么受影响的区域是已定义的，所有的client都能看到写的内容。成功的并发写操作是未定义但却是一致的。失败的修改将使区间处于不一致的状态。Write操作在应用程序指定的偏移处写入数据，而record append操作使得数据（记录）即使在有并发修改操作的情况下也至少原子性的被加到GFS指定的偏移处，偏移地址被返回给用户。在一系列成功的修改操作后，最后的修改操作保证文件区域是已定义的。GFS通过对所有的副本执行同样顺序的修改操作并且使用块版本号检测过时的副本（由于chunkserver退出而导致丢失修改）来做到这一点。因为用户缓存了会位置信息，所以在更新缓存之前有可能从一个过时的副本中读取数据。但这有缓存的截止时间和文件的重新打开而受到限制。在修改操作成功后，部件故障仍可以是数据受到破坏。GFS通过master和chunkserver间定期的handshake，借助校验和来检测对数据的破坏。一旦检测到，就从一个有效的副本尽快重新存储。只有在GFS检测前，所有的副本都失效，这个块才会丢失。系统交互播报编辑⑴租约（lease）和修改顺序⑵数据流我们的目标是充分利用每个机器的网络带宽，避免网络瓶颈和延迟为了有效的利用网络，我们将数据流和控制流分离。数据是以流水线的方式在选定的chunkerserver链上线性的传递的。每个机器的整个对外带宽都被用作传递数据。为避免瓶颈，每个机器在收到数据后，将它收到数据尽快传递给离它最近的机器。⑶原子性的record AppendGFS 提供了一个原子性的添加操作：record append。在传统的写操作中，client指定被写数据的偏移位置，向同一个区间的并发的写操作是不连续的：区间有可能包含来自多个client的数据碎片。在record append中， client只是指定数据。GFS在其选定的偏移出将数据至少原子性的加入文件一次，并将偏移返回给client。在分布式的应用中，不同机器上的许多client可能会同时向一个文件执行添加操作，添加操作被频繁使用。如果用传统的write操作，可能需要额外的、复杂的、开销较大的同步，例如通过分布式锁管理。在我们的工作量中，这些文件通常以多个生产者单个消费者队列的方式或包含从多个不同 client的综合结果。Record append和前面讲的write操作的控制流差不多，只是在primary上多了一些逻辑判断。首先，client将数据发送到文件最后一块的所有副本上。然后向primary发送请求。Primary检查添加操作是否会导致该块超过最大的规模（64M）。如果这样，它将该块扩充到最大规模，并告诉其它副本做同样的事，同时通知client该操作需要在下一个块上重新尝试。如果记录满足最大规模的要求，primary就会将数据添加到它的副本上，并告诉其它的副本在在同样的偏移处写数据，最后primary向client报告写操作成功。如果在任何一个副本上record append操作失败，client将重新尝试该操作。这时候，同一个块的副本可能包含不同的数据，因为有的可能复制了全部的数据，有的可能只复制了部分。GFS不能保证所有的副本每个字节都是一样的。它只保证每个数据作为一个原子单元被写过至少一次。这个是这样得出的：操作要是成功，数据必须在所有的副本上的同样的偏移处被写过。进一步，从这以后，所有的副本至少和记录一样长，所以后续的记录将被指定到更高的偏移处或者一个不同的块上，即使另一个副本成了primary。根据一致性保证，成功的record append操作的区间是已定义的。而受到干扰的区间是不一致的。⑷快照（snapshot）快照操作几乎在瞬间构造一个文件和目录树的副本，同时将正在进行的其他修改操作对它的影响减至最小。我们使用copy-on-write技术来实现snapshot。当master受到一个snapshot请求时，它首先将要snapshot的文件上块上的lease收回。这使得任何一个向这些块写数据的操作都必须和master交互以找到拥有lease的副本。这就给master一个创建这个块的副本的机会。副本被撤销或终止后，master在磁盘上登记执行的操作，然后复制源文件或目录树的metadata以对它的内存状态实施登记的操作。这个新创建的snapshot文件和源文件（其metadata）指向相同的块（chunk）。Snapshot 之后，客户第一次向chunk c写的时候，它发一个请求给master以找到拥有lease的副本。Master注意到chunk c的引用记数比1大，它延迟对用户的响应，选择一个chunk handle C’，然后要求每一有chunk c的副本的chunkserver创建一个块C’。每个chunkserver在本地创建chunk C’避免了网络开销。从这以后和对别的块的操作没有什么区别。MASTER操作播报编辑MASTER执行所有名字空间的操作，除此之外，他还在系统范围管理数据块的复制：决定数据块的放置方案，产生新数据块并将其备份，和其他系统范围的操作协同来确保数据备份的完整性，在所有的数据块服务器之间平衡负载并收回没有使用的存储空间。3.1 名字空间管理和加锁与传统文件系统不同的是，GFS没有与每个目录相关的能列出其所有文件的数据结构，它也不支持别名（unix中的硬连接或符号连接），不管是对文件或是目录。GFS的名字空间逻辑上是从文件元数据到路径名映射的一个查用表。MASTER 在执行某个操作前都要获得一系列锁，例如，它要对/d1/d2…/dn/leaf执行操作，则它必须获得/d1，/d1/d2，…， /d1/d2/…/dn的读锁，/d1/d2…/dn/leaf的读锁或写锁（其中leaf可以使文件也可以是目录）。MASTER操作的并行性和数据的一致性就是通过这些锁来实现的。3.2 备份存储放置策略一个GFS集群文件系统可能是多层分布的。一般情况下是成千上万个文件块服务器分布于不同的机架上，而这些文件块服务器又被分布于不同机架上的客户来访问。因此，不同机架上的两台机器之间的通信可能通过一个或多个交换机。数据块冗余配置策略要达到连个目的：最大的数据可靠性和可用性，最大的网络带宽利用率。因此，如果仅仅把数据的拷贝置于不同的机器上很难满足这两个要求，必须在不同的机架上进行数据备份。这样即使整个机架被毁或是掉线，也能确保数据的正常使用。这也使数据传输，尤其是读数据，可以充分利用带宽，访问到多个机架，而写操作，则不得不涉及到更多的机架。3.3 产生、重复制、重平衡数据块当MASTER产生新的数据块时，如何放置新数据块，要考虑如下几个因素：⑴尽量放置在磁盘利用率低的数据块服务器上，这样，慢慢地各服务器的磁盘利用率就会达到平衡。⑵尽量控制在一个服务器上的“新创建”的次数。⑶由于上一小节讨论的原因，我们需要把数据块放置于不同的机架上。MASTER在可用的数据块备份低于用户设定的数目时需要进行重复制。这种情况源于多种原因：服务器不可用，数据被破坏，磁盘被破坏，或者备份数目被修改。每个被需要重复制的数据块的优先级根据以下几项确定：第一是数目距目标的距离，对于能阻塞用户程序的数据块，我们也提高它的优先级。最后， MASTER按照产生数据块的原则复制数据块，并把它们放到不同的机架内的服务器上。MASTER周期性的平衡各服务器上的负载：它检查 chunk分布和负载平衡，通过这种方式来填充一个新的服务器而不是把其他的内容统统放置到它上面带来大量的写数据。数据块放置的原则与上面讨论的相同，此外，MASTER还决定那些数据块要被移除，原则上他会清除那些空闲空间低于平均值的那些服务器。3.4 垃圾收集在一个文件被删除之后，GFS并不立即收回磁盘空间，而是等到垃圾收集程序在文件和数据块级的的检查中收回。当一个文件被应用程序删除之后，MASTER会立即记录下这些变化，但文件所占用的资源却不会被立即收回，而是重新给文件命了一个隐藏的名字，并附上了删除的时间戳。在MASTER定期检查名字空间时，它删除超过三天（可以设定）的隐藏的文件。在此之前，可以以一个新的名字来读文件，还可以以前的名字恢复。当隐藏的文件在名字空间中被删除以后，它在内存中的元数据即被擦除，这就有效地切断了他和所有数据块的联系。在一个相似的定期的名字空间检查中，MASTER确认孤儿数据块（不属于任何文件）并擦除他的元数据，在和MASTER的心跳信息交换中，每个服务器报告他所拥有的数据块，MASTER返回元数据不在内存的数据块，服务器即可以删除这些数据块。3.5 过时数据的探测在数据更新时如果服务器停机了，那么他所保存的数据备份就会过时。对每个数据块，MASTER设置了一个版本号来区别更新过的数据块和过时的数据块。当MASTER 授权一个新的lease时，他会增加数据块的版本号并会通知更新数据备份。MASTER和备份都会记录下当前的版本号，如果一个备份当时不可用，那么他的版本号不可能提高，当ChunkServer重新启动并向MASTER报告他的数据块集时，MASTER就会发现过时的数据。MASTER在定期的垃圾收集程序中清除过时的备份，在此以前，处于效率考虑，在各客户机应答时，它会认为根本不存在过时的数据。作为另一个安全措施， MASTER在给客户及关于数据块的应答或是另外一个读取数据的服务器数据是都会带上版本信息，在操作前客户机和服务器会验证版本信息以确保得到的是最新的数据。容错和诊断播报编辑4.1 高可靠性⒋1.1 快速恢复不管如何终止服务，MASTER和数据块服务器都会在几秒钟内恢复状态和运行。实际上，我们不对正常终止和不正常终止进行区分，服务器进程都会被切断而终止。客户机和其他的服务器会经历一个小小的中断，然后它们的特定请求超时，重新连接重启的服务器，重新请求。⒋1.2 数据块备份如上文所讨论的，每个数据块都会被备份到放到不同机架上的不同服务器上。对不同的名字空间，用户可以设置不同的备份级别。在数据块服务器掉线或是数据被破坏时，MASTER会按照需要来复制数据块。⒋1.3 MASTER备份为确保可靠性，MASTER的状态、操作记录和检查点都在多台机器上进行了备份。一个操作只有在数据块服务器硬盘上刷新并被记录在MASTER和其备份的上之后才算是成功的。如果MASTER或是硬盘失败，系统监视器会发现并通过改变域名启动它的一个备份机，而客户机则仅仅是使用规范的名称来访问，并不会发现MASTER的改变。4.2 数据完整性每个数据块服务器都利用校验和来检验存储数据的完整性。原因：每个服务器随时都有发生崩溃的可能性，并且在两个服务器间比较数据块也是不现实的，同时，在两台服务器间拷贝数据并不能保证数据的一致性。每个Chunk按64kB的大小分成块，每个块有32位的校验和，校验和和日志存储在一起，和用户数据分开。在读数据时，服务器首先检查与被读内容相关部分的校验和，因此，服务器不会传播错误的数据。如果所检查的内容和校验和不符，服务器就会给数据请求者返回一个错误的信息，并把这个情况报告给MASTER。客户机就会读其他的服务器来获取数据，而MASTER则会从其他的拷贝来复制数据，等到一个新的拷贝完成时，MASTER就会通知报告错误的服务器删除出错的数据块。附加写数据时的校验和计算优化了，因为这是主要的写操作。我们只是更新增加部分的校验和，即使末尾部分的校验和数据已被损坏而我们没有检查出来，新的校验和与数据会不相符，这种冲突在下次使用时将会被检查出来。相反，如果是覆盖现有数据的写，在写以前，我们必须检查第一和最后一个数据块，然后才能执行写操作，最后计算和记录校验和。如果我们在覆盖以前不先检查首位数据块，计算出的校验和则会因为没被覆盖的数据而产生错误。在空闲时间，服务器会检查不活跃的数据块的校验和，这样可以检查出不经常读的数据的错误。一旦错误被检查出来，服务器会拷贝一个正确的数据块来代替错误的。4.3 诊断工具广泛而细致的诊断日志以微小的代价换取了在问题隔离、诊断、性能分析方面起到了重大的作用。GFS服务器用日志来记录显著的事件（例如服务器停机和启动）和远程的应答。远程日志记录机器之间的请求和应答，通过收集不同机器上的日志记录，并对它们进行分析恢复，我们可以完整地重现活动的场景，并用此来进行错误分析。测量播报编辑⒌1 测试环境一台主控机，两台主控机备份，16台数据块服务器，16台客户机。每台机器：2块PⅢ1.4G处理器，2G内存，2块80G5400rpm的硬盘，1块100Mbps全双工网卡19台服务器连接到一个HP2524交换机上，16台客户机连接到另外一台交换机上，两台交换机通过1G的链路相连。新手上路成长任务编辑入门编辑规则本人编辑我有疑问内容质疑在线客服官方贴吧意见反馈投诉建议举报不良信息未通过词条申诉投诉侵权信息封禁查询与解封©2024 Baidu 使用百度前必读 | 百科协议 | 隐私政策 | 百度百科合作平台 | 京ICP证030173号京公网安备110000020000

【MIT 6.824】学习笔记 3: GFS - 知乎

【MIT 6.824】学习笔记 3: GFS - 知乎首发于MIT 6.824 分布式系统切换模式写文章登录/注册【MIT 6.824】学习笔记 3: GFS多颗糖本篇主要学习 The Google File System 这篇大名鼎鼎的论文。分布式存储是构建分布式系统的关键，许多其它分布式应用都建立在分布式存储之上。为什么设计一个分布式存储系统会如此之难？出发点是提高性能，当单机数据量太大时，需要在多台服务器上分片(Sharding)数据；由于多台服务器，系统可能会出现更多的故障。如果你有数千台服务器，也许每天都有机器故障，所以我们需要系统能够自动容错；为了提高容错，需要复制(replication)数据到多台服务器上，一般 2-3 个数据副本；数据的复制会导致数据潜在的不一致；为了提高一致性往往会导致更低的性能，这与我们的初衷恰恰相反！这个循环突出了分布式系统的挑战。GFS 讨论了上述的这些主题：并行性能、容错、复制、一致性，并给出了 Google 在生产环境进行的权衡。GFS 论文的内容直观，容易理解，从硬件到软件都有讨论，是一篇非常优秀的系统论文！GFS 的目标主要设计目标：大型：大容量，需要存放大量的数据集；性能：自动分片(Auto-Sharding)；全局：不只是为一个应用而定制，适用于各种不同的应用；容错：自动容错，不希望每次服务器出了故障，都要手动去修复；还有一些其他的特性，比如：GFS 只能在一个数据中心运行，理论上可以跨机房，但更复杂；面向内部的，不开放销售；面向顺序读写大文件的工作负载(例如前面提到的 MapReduce)；架构如图所示，GFS 集群包括：一个 master 和多个 chunkserver，并且若干 client 会与之交互。主要架构特性：chunk：存储在 GFS 中的文件分为多个 chunk，chunk 大小为 64M，每个 chunk 在创建时 master 会分配一个不可变、全局唯一的 64 位标识符(chunk handle)；默认情况下，一个 chunk 有 3 个副本，分别在不同的 chunkserver 上；master：维护文件系统的 metadata，它知道文件被分割为哪些 chunk、以及这些 chunk 的存储位置；它还负责 chunk 的迁移、重新平衡(rebalancing)和垃圾回收；此外，master 通过心跳与 chunkserver 通信，向其传递指令，并收集状态；client：首先向 master 询问文件 metadata，然后根据 metadata 中的位置信息去对应的 chunkserver 获取数据；chunkserver：存储 chunk，client 和 chunkserver 不会缓存 chunk 数据，防止数据出现不一致；master 节点为了简化设计，GFS 只有一个 master 进行全局管理。master 在内存中存储 3 种 metadata，如下。标记 nv(non-volatile, 非易失) 的数据需要在写入的同时存到磁盘，标记 v 的数据 master 会在启动后查询 chunkserver 集群：namespace(即：目录层次结构)和文件名；(nv)文件名 -> array of chunk handles 的映射；(nv)chunk handles -> 版本号(nv)、list of chunkservers(v)、primary(v)、租约(v)课程特别提到，master 会在本地磁盘存储 log，而不是存到数据库，原因是：数据库的本质是某种 B 树或者 hash table，相比之下，追加 log 会非常高效；而且，通过在 log 中创建一些 checkpoint 点，重建状态也会更快。读文件client 将文件名+offset 转为文件名+ chunk index，向 master 发起请求；master 在内存中的 metadata 查询对应 chunk 所在的 chunk handle + chunk locations 并返回给 client；client 将 master 返回给它的信息缓存起来，用文件名 + chunk index 作为 key；(注意：client 只缓存 metadata，不缓存 chunk 数据)client 会选择网络上最近的 chunkserver 通信(Google 的数据中心中，IP 地址是连续的，所以可以从 IP 地址差异判断网络位置的远近)，并通过 chunk handle + chunk locations 来读取数据；学生提问：如果读取的数据超过了一个 chunk 怎么办？Robert教授：我不知道详细的细节。我的印象是，如果应用程序想要读取超过 64MB 的数据，或者就是 2 个字节，但是却跨越了 chunk 的边界，应用程序会通过一个库来向 GFS 发送 RPC，而这个库会注意到这次读请求会跨越 chunk 边界，因此会将一个读请求拆分成两个读请求再发送到 master 节点。所以，这里可能是向 master 节点发送两次读请求，得到了两个结果，之后再向两个不同的 chunk 服务器读取数据。租约如果每次写文件都请求 master，那么 master 则会成为性能瓶颈，master 找到拥有该 chunk 的 chunkserver，并给其中一个 chunkserver 授予租约，拥有租约的 chunkserver 称为 Primary，其他叫做 Secondary，之后：master 会增加版本号，并将版本号写入磁盘，然后 master 会向 Primary 和Secondary 副本对应的服务器发送消息并告诉它们，谁是 Primary，谁是 Secondary，最新的版本号是什么；在租约有效期内，对该 chunk 的写操作都由 Primary 负责；租约的有效期一般为 60 秒，租约到期后 master 可以自由地授予租约；master 可能会在租约到期前撤销租约(例如：重命名文件时)；在写 chunk 时，Primary 也可以请求延长租约有效期，直至整个写完 chunk；写文件如图，写文件可分为 7 步：client 向 master 询问 Primary 和 Secondary。如果没有 chunkserver 持有租约，master 选择一个授予租约；master 返回 Primary 和 Secondary 的信息，client 缓存这些信息，只有当 Primary 不可达或者租约过期才再次联系 master；client 将追加的记录发送到每一个 chunkserver(不仅仅是 Primary)，chunkserver 先将数据写到 LRU 缓存中(不是硬盘！)；一旦 client 确认每个 chunkserver 都收到数据，client 向 Primary 发送写请求，Primary 可能会收到多个连续的写请求，会先将这些操作的顺序写入本地；Primary 做完写请求后，将写请求和顺序转发给所有的 Secondary，让他们以同样的顺序写数据；Secondary 完成后应答 Primary；Primary 应答 client 成功或失败。如果出现失败，client 会重试，但在重试整个写之前，会先重复步骤 3-7；一致性模型GFS 是宽松的一致性模型(relaxed consistency model)，可以理解是弱一致性的，它并不保证一个 chunk 的所有副本是相同的。如果一个写失败，client 可能会重试：对于写：可能有部分副本成功，而另一部分失败，副本就会不一致。对于 record append：也会重试，但是不是在原来的 offset 上重试，而是在失败的记录后面重试，这样 record append 留下的不一致是永久的不一致，并且会让副本包含重复的数据。如图，先解释图上 defined 和 consistent 两个概念：defined：一个文件区域在经过一系列操作之后，client 可以看到数据变更写入的所有数据；consistent：所有 client 不论从哪个副本中读取同一份文件，得到的结果都是相同的；对于 metadata：metadata 都是由 master 来处理的，读写操作通过锁保护，可以保证一致性。对于文件数据：在没有并发的情况下，写入不会互相干扰，那么则是 defined；在并发的情况下，成功的写入是 consistent 但不是 defined；顺序写和并发写 record append 能够保证是 defined，但是在 defined 的区域之间会夹杂着一些不一致的区域；如果出现写失败，副本之间会不一致；如何处理这种异常情况，取决于应用程序。GFS 并不是强一致性的，如果这里要转变成强一致性的设计，几乎要重新设计系统，需要考虑：可能需要让 Primary 重复探测请求；如果 Primary 要求 Secondary 执行一个操作，Secondary 必须执行而不是返回一个错误；在 Primary 确认所有的 Secondary 都追加成功之前，Secondary 不能将数据返回给读请求；可能有一组操作由 Primary 发送给 Secondary，Primary 在确认所有的 Secondary 收到了请求之前就崩溃了。当 Primary 崩溃了，一个 Secondary 会接任成为新的 Primary；越说越像 paxos 或 raft 算法了。还有其他情况，在此不一一举例了。为什么 Google 最初选择弱一致性呢？教授在课堂上给出一种解释。Robert教授：如果你通过搜索引擎做搜索，20000 个搜索结果中丢失了一条或者搜索结果排序是错误的，没有人会注意到这些。这类系统对于错误的接受能力好过类似于银行这样的系统。当然并不意味着所有的网站数据都可以是错误的。如果你通过广告向别人收费，你最好还是保证相应的数字是对的。快照(snapshot)GFS 通过 snapshot 来创建一个文件或者目录树的备份，它可以用于备份文件或者创建 checkpoint（用于恢复）。GFS 使用写时复制（copy-on-write)来写快照。当 master 收到 snapshot 操作请求后：撤掉即将做快照的 chunk 的租约，准备 snapshot（相当于暂停了所有写操作）；master 将操作记录写入磁盘；master 将源文件和目录树的 metadata 进行复制，新创建的快照文件指向与源文件相同的 chunk；容错性快恢复：master 和 chunkserver 都设计成在几秒钟内恢复状态和重启；chunk 副本：如前面提到的，chunk 复制到多台机器上；master 副本：master 也会被复制来保证可用性，称为 shadow-master；数据完整性 checksum通常一个GFS 集群都有好几百台机器以及几千块硬盘，磁盘损坏是很经常的事情，在数据的读写中经常出现数据损坏。每一个 chunkserver 都是用 checksum 来检查存储数据的完整性。每个 chunk 以 64kb 的块进行划分，每一个块对应一个 32 位的 checksum，存到 chunkserver 的内存中，通过记录用户数据来持久化存储 checksum。对于读操作，在返回给 client 之前，chunkserver 会校验要读取块的 checksum。为什么是 64Kb 呢？我猜测应该是 64Mb/64Kb 好计算吧。FAQ原文：http://nil.csail.mit.edu/6.824/2021/papers/gfs-faq.txtchunk 大小为什么是 64 MB？较大的 chunk 较少了 client 与 master 的通信次数；client 能够对一个块进行多次操作，这样可以通过与 chunkserver 保持较长时间的 TCP 连接来减少网络负载；减少了 metadata 的大小；带来的问题：chunk 越大，可能部分文件只有 1 个 chunk，对该文件的频繁读写可能会造成热点问题。值得一提的是，GFS 的继任者 Colossus 将 chunk 大小下调到了 4MB。为什么是 3 个副本？选择这个数字是为了最大限度地降低一个块坏的概率。一项关于磁盘的研究：https://research.google.com/archive/disk_failures.pdf论文中提到了引用计数——这是什么？引用计数用来实现 copy-on-write 生成快照。当 GFS 创建一个快照时，它并不立即复制 chunk，而是增加 GFS 中 chunk 的引用计数，表示这个 chunk 被快照引用了，等到客户端修改这个 chunk 时，才需要在 chunkserver 中拷贝 chunk 的数据生成新的 chunk，后续的修改操作落到新生成的 chunk 上。总结图来源(权侵删)：https://juicefs.com/blog/cn/posts/distributed-filesystem-comparison/就写到这里吧，本来打算对比下 HDFS、GlusterFS、MooseFS 和最近开源的 JuiceFS 等分布式文件系统，但文章越来越长，精力有限，也超出学习笔记的范畴，只好就此打住。如果你想要继续看分布式文件系统相关分析，留言告诉我。GFS 生涯的前 5-10 年在 Google 表现出色，取得了巨大成功。但 GFS 是在 2000 年出头刚开始构建分布式系统，所以很多东西是非标准的，时间久了便诞生很多问题。最终，Google 公布了 Colossus 项目，作为 Google 下一代分布式文件系统。GFS 最严重的局限性就在于它只有一个 master 节点(这篇文章讨论了这个问题：https://queue.acm.org/detail.cfm?id=1594206)，单个 master 会带来以下问题：随着 GFS 的应用越来越多，文件也越来越多，最后 master 会耗尽内存来存储 metadata；你可以增加内存，但单台计算机的内存始终有上限；master 节点要承载数千个 client 的请求，master 节点的 CPU 每秒只能处理数百个请求，尤其是还要将部分数据写入磁盘——client 的数量会超过单个 master 的能力；弱一致性会导致应用程序很难处理 GFS 奇怪的语义；最后一个问题，master 的故障切换不是自动的，需要人工干预来处理已经永久故障的 master 节点，并更换新的服务器，这需要几十分钟甚至更长的时间来处理。对于某些应用程序来说，这个时间太长了。所以，我们需要一个多副本、多活、高可用、故障自修复的分布式系统！一个自动切到可用副本的复制算法。学过的同学都知道，这将引出了我们的分布式共识算法！ReferenceThe Google File System: https://pdos.csail.mit.edu/6.824/papers/gfs.pdf6.824 课程视频: https://www.bilibili.com/video/BV1e5411E7RMLecture 3 GFS: https://pdos.csail.mit.edu/6.824/notes/l-gfs.txtGoogle File System: https://en.wikipedia.org/wiki/Google_File_System6.824 FAQ: http://nil.csail.mit.edu/6.824/2021/papers/gfs-faq.txt一项关于磁盘的研究: https://research.google.com/archive/disk_failures.pdfGoogle Colossus: http://highscalability.com/blog/2010/9/11/googles-colossus-makes-search-real-time-by-dumping-mapreduce.htmlCase Study: https://queue.acm.org/detail.cfm?id=1594206分布式文件系统架构对比: https://juicefs.com/blog/cn/posts/distributed-filesystem-comparison/Colossus: Successor to the Google File System (GFS): https://www.systutorials.com/colossus-successor-to-google-file-system-gfs/相关阅读【MIT 6.824】学习笔记 1：MapReduce【MIT 6.824】学习笔记 2：RPC and Threads发布于 2021-03-04 08:45分布式系统分布式存储文件系统赞同 33213 条评论分享喜欢收藏申请转载文章被以下专栏收录MIT 6.824 分布式系统MIT 6.824 分布式系统学习

Google File System - 知乎

Google File System - 知乎首发于分布式和存储的那些事切换模式写文章登录/注册Google File System丁凯主业写代码，副业拉皮条，兼职当猎头，欢迎骚扰写在前面最近没什么论文好看，于是乎又翻阅起了分布式存储系统的老祖宗GFS。开始愈发理解之前的领导花总说的：常读常新。之前也阅读过GFS的论文，但总是一带而过，很多问题没有想的特别清楚。于是，趁着这次阅读，将我对于GFS的理解总结下来，希望有所帮助。再次阅读GFS，给我最大的感触是：许多的问题，只能这么做，而且最好就这么做，也充分体会到了简洁优雅的系统设计给我带来的冲击。背景GFS是Google为其内部应用设计的分布式存储系统。Google可能是这个星球上最大的数据工厂了。如何高效可靠地存储如此大规模的数据成为一个很棘手的问题。纵观Google的内部应用，数据访问有以下特点：1. 数据集庞大，数据总量和单个文件都比较大，如应用常常产生数GB大小的单个文件；2. 数据访问特点多为顺序访问，比较常见的场景是数据分析，应用程序会顺序遍历数据文件，产生顺序读行为；3. 多客户端并发追加场景很常见，极少有随机写行为；4. 一次写入，多次读取，例如互联网上的网页存储。GFS是Google针对其数据访问模式而设计的分布式存储系统。特点GFS具备以下特点：高度扩展性，单个GFS集群文件系统可扩展至几千个节点，数PB的容量；高可靠性，GFS运行在普通x86服务器上，但GFS通过多副本等机制保证可靠性；满足POSIX语义，应用程序无需任何修改即可使用GFS。架构GFS系统主要存储文件系统两类数据：文件元数据：包括file system namespace（目录结构、文件元数据等）、文件存储位置信息等；文件数据：文件在磁盘上的存储格式在GFS中，文件被切割为固定大小的Chunk然后分散存储，典型的Chunk大小为64MB。Chunk也是数据复制的基本单位，每个Chunk默认复制三份存放在不同的地方（机架、机器、磁盘）。元数据节点也称为Master。存储系统元数据信息，主要包括namespace、文件chunk信息以及chunk多副本位置信息。Master是系统的中心节点，所有客户端的元数据访问，如列举目录下文件，获取文件属性等操作都是直接访问Master。除此之外，还承担了系统诸多的管理工作，我们会在后面详细说明。数据节点是文件chunk的存储位置。每个数据节点挂载多个磁盘设备并将其格式化为本地文件系统（如XFS）。将客户端写入数据以Chunk为单位存储，存储形式为本地文件。客户端提供类POSIX文件接口，应用程序使用客户端与GFS交互。整个系统的架构特别清晰，功能划分很明确。系统的复杂性在于各种异常处理，而异常又是分布式系统的常态。MasterMaster最主要的两个任务是管理file system Namespace信息和文件的Chunk位置信息。文件系统元数据文件系统的元数据主要是文件系统的目录树，在GFS中存储为B+树。树上的每个叶子节点代表普通文件，而中间节点则代表目录文件。根节点是文件系统的根目录。Master主要存储文件元数据信息，包括：id、文件大小、创建时间、文件的chunk信息等。在论文中说明单个文件的元数据信息不超过64字节。Master会将这些元数据信息进行持久化存储。Master启动时会将所有元数据加载至内存中，优点是元数据操作速度很快，缺点是限制了文件系统的可扩展性，如64GB内存的服务器最多可支持的文件数量约为 64GB/64B = 10亿。但由于GFS应用场景是大文件，所以这个问题对于他们来说并不严重。另外，由于元数据的重要性，Master会将文件元数据持久化存储。每一次元数据的更新操作都会先写日志，再应用到内存的B+树，这样即使出现断电等异常，也不会丢失更新。系统重启时，会重放日志在内存中构建B+树。为了避免日志过大而引发启动缓慢问题，Master会定期进行日志回收，原理是：将当前内存状态冻结并持久化存储到磁盘上，称为Checkpoint；然后，回收该时刻之前的所有日志。若系统此时重启，只需要：1. 将Checkpoint加载入内存；2. 重放Checkpoint点之后的日志即可在内存中重构最新状态。Chunk管理大文件会被切割成Chunk（64MB）存储，每个文件至少存储为一个chunk，于是，小文件的chunk大小就会小于64MB。每个Chunk有全局唯一标识符。文件元数据中存储了file id至chunk映射关系。由于Chunk以多副本方式存储，Master还需要维护Chunk位置信息。Chunk的位置信息ChunkServer周期性汇报，Master只在内存中维护该信息，无需持久化。核心问题数据一致性GFS定义了几种一致性：defined：状态已定义，从客户端角度来看，客户端完全了解已写入集群的数据，例如，客户端串行写入且成功，此时的状态是defined，如下图1； consistent：客户端来看chunk多副本的数据完全一致，但不一定defined，如下图2，一般发生在多客户端并发更新时 unconsistent：多副本数据不一致，如下图3； undefined：数据未定义，如下图4且论文中写明了各种情况下的状态：下面分别从over-write和append两个场景来阐述：串行Over-Writeover-write由客户端指定文件更新offset。当客户端是串行更新时，客户端自己知道写入文件范围以及写入数据内容，且本次写入在数据服务器的多副本上均执行成功。因此，本次写结果对于客户端来说就是明确的，且多副本上数据一致，故而结果是defined。如下图：并行Over-Write并行写入时多个客户端由于写入范围可能交叉而形成交织写。这时候，由于单个客户端无法决定写入顺序（只有主副本才能决定谁先写谁后写），因此，即使写入成功，客户端仍无法确定在并发写入时交叉部分最终写入结果，但是因为写入成功，所以多副本数据必然一致。如下图：图中红色部分代表并发追加的部分，这部分数据由于无法确定谁先谁后执行，因此结果不确定。但由于跟新成功，因此，副本间数据是一致的，这就是consistent but undefined。无论是穿行还是并行over-write，一旦失败，多个chunk副本上的数据可能都不一致了，其次，客户端从不同的副本上读出的数据也不一样（可能某些副本成功而某些副本失败），因此，必然也是undefined，也是inconsistent。append客户端append操作无需指定offset，由chunk主副本根据当前文件大小决定写入offset，在写入成功后将该offset返回给客户端。因此，客户端能够根据offset确切知道写入结果，无论是串行写入还是并发写入，其行为是defined。如下：append失败假设上面的append经历了一次重试，那可能实际chunk的布局如下：由于第一次写失败（错误可能发生在任意一个副本），导致了多副本之间从50至80的数据可能不一致。但接下来重试成功，从80至110之间的数据一致，因此，其状态是interspersed with inconsistent。GFS 租约GFS在chunk多副本之间选择出一个主副本，由主副本来协调客户端的写入，保证多副本之间维持一个全局统一的更新顺序，GFS使用了租约。租约（Lease）是由GFS中心节点Master分配给chunk的某个副本的锁。持有租约的副本方可处理客户端的更新请求，客户端更新数据前会从Master获取该chunk持有租约的副本并向该副本发送更新请求。租约本质上是一种有时间限制的锁：租约的持有者（chunk的某个副本）需要定期向Master申请续约。如果超过租约的期限，那么该租约会被强制收回并重新分配给其他副本。租约中有一个问题值得思考：假如副本A1、A2、A3（A1是主副本），在写的过程中A3掉线，此时还能继续写么？可能解决方案：客户端在重试N次后依然写失败，启动数据恢复，在数据恢复过程中该chunk不可写入，此时需要由应用去处理不可写情况（GFS做法）；master对此种情况时分配一个新的chunk写入，原不可写chunk后续无法被再写入。（QFS的做法？不确定，待调研，此做法可能导致chunk大小不再固定为64MB，可能会带来其他麻烦）降低要求，写入A1、A2即可，后面等master数据恢复将副本3再恢复出来（Oceanbase的做法貌似，待看看代码）。关键流程数据写入客户端向Master查询待写入的chunk的副本信息，Master返回副本列表，第一项为主副本，即当前持有租约的副本；客户端向多副本推送待写入数据，这里的推送是指将数据发送至chunk多副本，chunkserver会缓存这些数据，此时数据并不落盘；客户端向主副本发起Sync请求；主副本将数据写入本地的同时通知其他副本将数据写入各自节点，此时数据方才落盘；主副本等待所有从副本的sync响应；主副本给客户端返回写入成功响应这里需要说明的是客户端的数据吸入被拆成了数据推送和sync两个子命令，这是因为：数据推送过程，客户端可以根据网络拓扑情况进行推送路径优化：客户端可以选择距离自己最近的副本推送数据，然后再由该副本选择下一个距离自己最近的副本进行数据推送，直到数据被扩散至所有副本，由于该过程仅仅是将数据推送给chunkserver并保存在内存缓冲区中，因此，无需保证数据推送顺序；sync是将上面推送的数据落盘，需要保证多副本上数据写入序列的一致性，否则大家各人执行各人的，会出现副本之间数据不一致，该指令必须由主副本来确定数据更新顺序然后将该顺序通知给其他从副本。chunk副本位置GFS中chunk以多副本存储，以提高数据可靠性。因此，副本位置的选取是一个比较关键的问题，一个好的副本位置定义算法满足下面特性：保证足够的可靠性，例如，不能将所有副本存放在同一个磁盘或者物理机器上；保证写入高效性，多副本位置尽量靠近，降低写入延迟，提高读写性能GFS在论文中说明了创建chunk时副本位置的选择算法：选择存储空间利用率最低的节点和磁盘；选择最近一段时间内新建chunk数量较少的节点和磁盘；将多个副本分散在不同的rack上。1和3比较容易理解，2是为了保证一个节点/磁盘不会被频繁新建chunk（新建完接下来就是数据写入了），否则很容易沦为热点，导致磁盘IO和网络带宽被占满，影响效率。SnapshotSnapshot是对系统当前状态进行的一次拍照。用户可以在任意时刻回滚到快照的状态。GFS使用COW技术实现Snapshot。COW原理是如果被Snapshot的文件有更新操作时，就将文件的要被更新的chunk复制一份，然后对复制的chunk进行更新，而原来的chunk作为快照数据被保留，以后要恢复到该快照时，直接将该chunk读出即可。当GFS的Master节点收到Snapshot请求时：回收Snapshot请求覆盖的文件chunks上的租约，这样，接下来客户端要对文件修改时，就必须向Master申请，而此时master就可以对chunk进行复制；Master在日志中记录本次Snapshot操作，然后在内存中执行Snapshot动作，具体是将被Snapshot的文件或目录的元数据复制一份，被复制出的文件与原始文件指向相同的chunk；假如客户端申请更新被Snapshot的文件内容，那么找到需要更新的Chunk，向其多个副本发送拷贝命令，在其本地创建出Chunk的副本Chunk’，之所以本地创建是因为可以避免跨节点之间的数据拷贝，节省网络带宽；客户端收到Master的响应后，表示该Chunk已经COW结束，接下来客户端的更新流程与正常的没有区别。参考http://static.googleusercontent.com/media/research.google.com/es//archive/gfs-sosp2003.pdf编辑于 2017-09-26 20:36分布式存储谷歌 (Google)Google File System赞同 46727 条评论分享喜欢收藏申请转载文章被以下专栏收录分布式和存储的那些事关于分布式

GFS模型：它是什么，特征和重要性| 网络气象

气象en红色

气象

气象现象

摄影

预测

气候学

气候变化

天文学

地质学

节

GFS模型

德国波蒂略

没有评论

人类一直有雄心壮志来了解天气并进行预测。由于技术的发展，有许多不同的计算机模型可以帮助预测几天后的天气状况。今天我们要谈的是 GFS模型。它是最重要的模型之一，并且在整个星球上具有最大的相关性。

因此，我们将专门为您介绍有关GFS模型，其特征和重要性的所有信息。

什么是GFS模型

首字母对应于Global Forecast System。在西班牙语中，它是指全球禁止系统，尽管其他首字母缩写更为人所知。这是一种用于天气预报的数值数学模型。它是由美国国家海洋和大气管理局创建并正在使用的数学模型，每天更新4次。根据从不同的气象变量获得的数据，可以提前16天创建预测。

众所周知，这些预测并不完全可靠，因为可以轻松更改大气动力学。大气的特征和盛行的天气同时取决于许多变量的值。这些变量中的大多数直接受到影响我们星球的太阳辐射量的直接影响。根据太阳辐射的数量和其他变量将从温度和风况开始进行修改。

可以接受的是，GFS模型的预测在7天后不能为我们提供高可靠性。甚至可以说，经过3-4天后，它不再完全准确。大多数国家气象机构和机构都忽略了此模型的大部分结果，尤其是超过10天后的结果。

数值天气预报模型

为了能够预测天气，需要各种数值模型。这些数值模型采用大气变量的值，并通过复杂的方程式可以在不久的将来知道这些变量的状态。地球上最常用的天气预报有4种数值模型：

综合预报系统欧洲中距离天气预报中心。

全球环境多尺度加拿大模型。

海军的作战全球大气预报系统美国武装部队。

全球金融服务部（全球预报系统）。

这些是中期和天气尺度上最常用的气象预报模型。

欧洲GFS模型

一旦我们知道了这种天气预报模型的作用，我们就必须以世界各国不同地区存在的差异为基础。具体来说，您必须查看欧洲GFS模型。而且是这个模型与美利坚合众国政府创造的最高竞争者相比，它具有许多优势。如果我们目前比较这两种模型，那么这场辩论将结束。它们都具有非常好的特性，并且可以非常精确地预测。一家独立工作的公司尚未进行客观测试，以确定这两种模型中的哪一种最能预测天气。

尽管两个模型都不是另一个模型的赢家，但该领域的大多数专家还是选择了欧洲模型。该模型与美国模型之间的主要区别之一是其技术。它具有更复杂，更昂贵的计算机系统，可以使它们以更有效的方式工作。通过这种更先进的技术，可以实现更精确，调整和更高分辨率的大气投影。

大多数专家说，欧洲GFS模型在数据模拟方面要比美国好得多。他们使用的论据是，它相当完整，并且提供了更多的经过验证的信息。举一个例子，可以看出欧美模型之间的差异，欧洲是能够进行50次大气模拟每个预测周期，而北美一次只能运行20个模拟。

西班牙的GFS模型

我国也有这种天气预报模型。该模型在多个部分中运行每个模型。让我们看看这些部分是什么：

第一种是采用比更高和更好的分辨率来完成的它通常最多需要192个小时，相当于每8个小时的预测图有6天。

预测的另一部分具有较低的分辨率。它只包含在204到384小时之间，这将是16天（每12小时有一张地图）。可以预见，此预测的分辨率较低，因为它涵盖的天数更多，因此无法以相同的精度进行预测。

在西班牙境内，该模型通常每天使用约4次，以便能够估算出良好的短期预测。可以说它在0小时，6 12和18小时使用。关于可以查看以查看预测结果的地图的更新，它们是从世界标准时间3：30、9：30、15：30和21:30实时执行的。

必须考虑的是，由于大气变量没有固定的操作，因此这种类型的气象预测模型存在缺陷。因此，我们看到许多天气报告的预测是错误的因为大气的演变并不总是那么容易预测。一些模式，例如风暴或反气旋的形成，可能非常简单。然而，更难以预测这些空气团的位移。

我希望借助这些信息，您可以了解有关GFS模型，其特征和重要性的更多信息。

文章的完整路径：网络气象 » 气象 » GFS模型

成为第一个发表评论

发表您的评论取消回复您的电子邮件地址将不会被发表。必填字段标有 *评论 * 名称

电子邮件地址*

我接受了隐私条款*

负责数据：MiguelÁngelGatón

数据用途：控制垃圾邮件，注释管理。

合法性：您的同意

数据通讯：除非有法律义务，否则不会将数据传达给第三方。

数据存储：Occentus Networks（EU）托管的数据库

权利：您可以随时限制，恢复和删除您的信息。

我想收到时事通讯

电子邮件中的新闻在您的电子邮件中接收有关气象的所有新闻。

名称

邮箱地址

我接受法律条件

↑

Facebook

Twitter

Youtube

电子邮件RSS

RSS订阅

组成与研究

绿色可再生能源

文化10

Androidsis

汽车新闻

贝齐亚

资讯动物

邮局

节

订阅电子邮件

编辑团队

编辑伦理

成为编辑

版本说明

许可证

联系我们

关闭

一篇文章告诉你什么是GFS（分布式文件系统）-CSDN博客

一篇文章告诉你什么是GFS（分布式文件系统）

最新推荐文章于 2022-03-28 09:16:37 发布

白雪滑落树梢

最新推荐文章于 2022-03-28 09:16:37 发布

阅读量9.7k

点赞数

分类专栏：

文件系统

文章标签：

缓存

gfs

本文链接：https://blog.csdn.net/weixin_59410846/article/details/121378477

版权

文件系统

专栏收录该内容

2 篇文章

0 订阅

订阅专栏

引言一、文件系统简介1. 组成2. 作用3. 文件系统的挂载使用

二、GFS 分布式文件系统概述1. GFS 简介2. GFS 的特点3. GFS 专业术语4. 模块化堆栈式架构5. GFS 工作流程6. 各服务器详解

三、GFS 卷类型1. 分布式卷（Distribute volume）1.2 分布式卷示例原理1.3 分布式卷特点1.4 创建分布式卷

2. 条带卷（Stripe volume）2.1 条带卷示例原理2.2 条带卷特点2.3 创建条带卷

3. 复制卷（Replica volume）3.1 复制卷示例原理3.2 复制卷特点3.3 创建复制卷

4. 分布式条带卷（Distribute Stripe volume）4.1 分布式条带卷示例原理4.2 创建分布式条带卷

5. 分布式复制卷（Distribute Replica volume）5.1 分布式条带卷的示例原理5.2 创建分布式复制卷

6. 条带复制卷（Stripe Replica volume）和分布式条带复制卷（Distribute Stripe Replicavolume）

引言

当数据集的大小超过一台独立物理计算机的存储能力时，就有必要对它进行分区（partition）并存储到若干台单独的计算机上。管理网络中夸多台计算机存储的文件系统。这种系统构架于网络之上，肯定会引入网络编程的复杂性，因此它比普通的磁盘文件系统更为复杂。

一、文件系统简介

1. 组成

接口：文件系统接口功能模块(管理、存储的工具)：对对像管理的软件集合对象及属性：(使用此文件系统的消费者)

2. 作用

从系统角度来看，文件系统是对文件存储设备的空间进行组织和分配，负责文件存储并对存入的文件进行保护和检索的系统主要负责为用户建立文件，存入、读出、修改、转储文件，控制文件的存取

3. 文件系统的挂载使用

除跟文件系统以外的文件系统创建后要使用需要先挂载至挂载点后才可以被访问挂载点即分区设备文件关联的某个目录文件类比 NFS（外部的文件系统），使用挂载的方式才可以让本地系统来使用外部的文件系统的功能例如：配置永久挂载时，我们会写入挂载点与挂载目录，还有文件系统的名称（xfs），文件类型格式等。我们在远程跨服务器使用 GFS 分布式文件系统，挂载时也需要指定其文件格式（GlusterFS）

二、GFS 分布式文件系统概述

1. GFS 简介

GFS（Gluster File System）是一个可扩展、开源的分布式文件系统（可以很好的体现出弹性伸缩的特点），用于大型的、分布式的、对大量数据进行访问的应用，在传统的解决方案中，GFS 能够灵活的结合物理的，虚拟的和云资源去体现高可用和企业级的性能存储GFS 由三个组件组成： ① 存储服务器（Brick Server） ② 客户端（不在本地）（且，有客户端，也会有服务端，这点类似于 NFS，但是更为复杂） ③ 存储网关（NFS/Samaba）

无元数据服务器：元数据是核心，描述对象的信息，影响其属性；例如NFS，存放数据本身，是一个典型的元数据服务器可能存在单点故障，故要求服务器性能较高，服务器一旦出现故障就会导致数据丢失；反过来看，所以无元数据服务不会有单点故障。那么数据存放在哪里呢？会借用分布式的原则，分散存储，不会有一个统一的数据服务器

2. GFS 的特点

扩展性和高性能：可扩展性，扩展节点，通过多节点提高性能高可用性：不存在单点故障，有备份机制，类似 Raid 的容灾机制全局统一命名空间：集中化管理，类比 API 的性质/概念，系统里根据他命名所定义的隔离区域，是一个独立空间；统一的名称空间，与客户端交互，把请求存放至后端的块数据服务器弹性卷管理：方便扩容及对后端存储集群的管理与维护，较为复杂基于标准协议：基于标准化的文件使用协议，让 CentOS 兼容 GFS

3. GFS 专业术语

Brick 存储服务器：实际存储用户数据的服务器Volume：本地文件系统的"分区”FUSE：用户空间的文件系统(类比EXT4)，“这是一个伪文件系统”;以本地文件系统为例，用户想要读写一个文件，会借助于EXT4文件系统，然后把数据写在磁盘上；而如果是远端的GFS，客户端的请求则应该交给FUSE(为文件系统)，就可以实现跨界点存储在GFS上VFS(虚拟端口) ：内核态的虚拟文件系统，用户是先提交请求交给VFS然后VFS交给FUSE，再交给GFS客户端，最后由客户端交给远端的存储Glusterd(服务)：是允许在存储节点的进程

4. 模块化堆栈式架构

模块化的设计，即把功能封装在一起，最后一起调用同时启用多个模块，多个功能的组合，这种提供功能的方式叫做堆栈式的结构通过对模块的组合，可以实现复杂的功能

模块化：类似linux 编译安装，很多功能都可以做定制的，通常都是通过软件开发的方式封装为模块，按需使用/不适用 GlusterFs也是这个思想：把功能封装为一个个模块，通过加载/调用/启用的方式就可以对应的功能堆栈式架构设计通过对模块不同功能的组合来实现复杂功能

5. GFS 工作流程

① 客户端或应用程序通过 GlusterFS 的挂载点访问数据② linux系统内核通过 VFS API 收到请求并处理③ VFS 将数据递交给 FUSE 内核文件系统，并向系统注册一个实际的文件系统 FUSE，而 FUSE 文件系统则是将数据通过 /dev/fuse 设备文件递交给了 GlusterFS client 端。可以将 FUSE 文件系统理解为一个代理④ GlusterFS client 收到数据后，client 根据配置文件的配置对数据进行处理⑤ 经过 GlusterFS client 处理后，通过网络将数据传递至远端的 GlusterFS Server，并且将数据写入到服务器存储设备上

简单来说：应用程序访问本地挂载的目录进行查看修改等操作，服务器会通过内核交给文件系统进行处理，并且处理后的数据会通过网络传递给该挂载目录实际所在的源服务器中，源服务器会对数据进行存储

GFS-server 端功能模块的划分： ① 卷的类型（使用分布式、复制、条带) ② 存储管理(卷的创建、启用、关闭) ③ I/O调用(存储后，读取数据，如何读取) ④ 与GFS-client 端对接 GFS-client 端 ① 用户通过用户态模式下，存储数据(写入数据) ② 写入的数据，使用GFS挂载的形式完成（网络挂载samba/NFS) ③数据的写入会由GFS-client转存到GFS-server端(对应的卷中) 网络通讯 ① Infinlband ——— IB ② RDMA——— 面向连接传输协议—— 数据完整性(丢包率低) ③ TCP/IP ④ RDMA———》以后的服务中可以做为跨节点共享内存资源的协议

6. 各服务器详解

Application：客户端或应用程序通过GlusterFSync的挂载点访问数据VFS：linux系统内核通过VFS的API 收到请求并处理FUSE：VFS将数据递交给FUSE内核文件系统，fuse文件系统则是将数据通过/dev/fuse设备文件递交给了GlusterFSGlusterFS Client ：通过网络将数据传递至远端的GlusterFS Server，并且写入到服务器存储设备上

三、GFS 卷类型

为了解决分布式文件数据索引、定位的复杂程度，而使用了HASH算法来辅助分布式(平均分配)的好处: ① 当数据量越来越大的时候，相对每个存储节点的数据量(几率)是相等的 ② 而如果考虑到单点故障问题，当数据存储再c存储节点，对此GFS是会有备份机制的，默认3备份，所以GFS本身的机制会对数据产生冗余，以此解决单点故障

GlusterFS支持七种卷，即分布式卷、条带卷、复制卷、分布式条带卷、分布式复制卷、条带复制卷和分布式条带复制卷

1. 分布式卷（Distribute volume）

文件通过 HASH 算法分布到所有 Brick Server 上，这种卷是 GlusterFS 的默认卷；以文件为单位根据 HASH 算法散列到不同的 Brick，其实只是扩大了磁盘空间，如果有一块磁盘损坏，数据也将丢失，属于文件级的 RAID0，不具有容错能力。在该模式下，并没有对文件进行分块处理，文件直接存储在某个 Server 节点上。由于直接使用本地文件系统进行文件存储，所以存取效率并没有提高，反而会因为网络通信的原因而有所降低。

1.2 分布式卷示例原理

File1 和 File2 存放在 Server1，而 File3 存放在 Server2，文件都是随机存储，一个文件（如 File1）要么在 Server1 上，要么在 Server2 上，不能分块同时存放在 Server1和 Server2 上。

1.3 分布式卷特点

文件分布在不同的服务器，不具备冗余性更容易和廉价地扩展卷的大小单点故障会造成数据丢失依赖底层的数据保护

1.4 创建分布式卷

创建一个名为dis-volume的分布式卷，文件将根据HASH分布在server1:/dir1、server2:/dir2和server3:/dir3中gluster volume create dis-volume server1:/dir1 server2:/dir2 server3:/dir3

2. 条带卷（Stripe volume）

类似 RAID0，文件被分成数据块并以轮询的方式分布到多个 Brick Server 上，文件存储以数据块为单位，支持大文件存储，文件越大，读取效率越高，但是不具备冗余性。

2.1 条带卷示例原理

File 被分割为 6 段，1、3、5 放在 Server1，2、4、6 放在 Server2。

2.2 条带卷特点

根据偏移量将文件分成N块（N个条带点），轮询的存储在每个Brick Serve 节点.分布减少了负载,在存储大文件时，性能尤为突出.没有数据冗余,类似于Raid 0

2.3 创建条带卷

创建了一个名为stripe-volume的条带卷，文件将被分块轮询的存储在Server1:/dir1和Server2:/dir2两个Brick中gluster volume create stripe-volume stripe 2 transport tcp server1:/dir1 server2:/dir2

3. 复制卷（Replica volume）

将文件同步到多个 Brick 上，使其具备多个文件副本，属于文件级 RAID 1，具有容错能力。因为数据分散在多个 Brick 中，所以读性能得到很大提升，但写性能下降。复制卷具备冗余性，即使一个节点损坏，也不影响数据的正常使用。但因为要保存副本，所以磁盘利用率较低。

3.1 复制卷示例原理

File1 同时存在 Server1 和 Server2，File2 也是如此，相当于 Server2 中的文件是 Server1 中文件的副本。

3.2 复制卷特点

卷中所有的服务器均保存一个完整的副本。具备冗余性.卷的副本数量可由客户创建的时候决定，但复制数必须等于卷中 Brick 所包含的存储服务器数。至少由两个块服务器或更多服务器。若多个节点上的存储空间不一致，将按照木桶效应取最低节点的容量作为改卷的总容量。

3.3 创建复制卷

创建名为rep-volume的复制卷，文件将同时存储两个副本，分别在Server1:/dir1和Server2:/dir2两个Brick中gluster volume create rep-volume replica 2 transport tcp server1:/dir1 server2:/dir2

4. 分布式条带卷（Distribute Stripe volume）

Brick Server 数量是条带数（数据块分布的 Brick 数量）的倍数，兼具分布式卷和条带卷的特点。主要用于大文件访问处理**，创建一个分布式条带卷最少需要 4 台服务器。**

4.1 分布式条带卷示例原理

File1 和 File2 通过分布式卷的功能分别定位到Server1和 Server2。在 Server1 中，File1 被分割成 4 段，其中 1、3 在 Server1 中的 exp1 目录中，2、4 在 Server1 中的 exp2 目录中。在 Server2 中，File2 也被分割成 4 段，其中 1、3 在 Server2 中的 exp3 目录中，2、4 在 Server2 中的 exp4 目录中。

4.2 创建分布式条带卷

创建一个名为dis-stripe的分布式条带卷，配置分布式的条带卷时，卷中Brick所包含的存储服务器数必须是条带数的倍数（>=2倍）。Brick 的数量是 4（Server1:/dir1、Server2:/dir2、Server3:/dir3 和 Server4:/dir4），条带数为 2（stripe 2）gluster volume create dis-stripe stripe 2 transport tcp server1:/dir1 server2:/dir2 server3:/dir3 server4:/dir4 创建卷时，存储服务器的数量如果等于条带或复制数，那么创建的是条带卷或者复制卷；如果存储服务器的数量是条带或复制数的 2 倍甚至更多，那么将创建的是分布式条带卷或分布式复制卷。

5. 分布式复制卷（Distribute Replica volume）

分布式复制卷（Distribute Replica volume）：Brick Server 数量是镜像数（数据副本数量）的倍数，兼具分布式卷和复制卷的特点，主要用于需要冗余的情况下。

5.1 分布式条带卷的示例原理

File1 和 File2 通过分布式卷的功能分别定位到 Server1 和 Server2。在存放 File1 时，File1 根据复制卷的特性，将存在两个相同的副本，分别是 Server1 中的exp1 目录和 Server2 中的 exp2 目录。在存放 File2 时，File2 根据复制卷的特性，也将存在两个相同的副本，分别是 Server3 中的 exp3 目录和 Server4 中的 exp4 目录。

5.2 创建分布式复制卷

建一个名为dis-rep的分布式复制卷，配置分布式的复制卷时，卷中Brick所包含的存储服务器数必须是复制数的倍数（>=2倍）。Brick 的数量是 4（Server1:/dir1、Server2:/dir2、Server3:/dir3 和 Server4:/dir4），复制数为 2（replica 2）gluster volume create dis-rep replica 2 transport tcp server1:/dir1 server2:/dir2 server3:/dir3 server4:/dir4

6. 条带复制卷（Stripe Replica volume）和分布式条带复制卷（Distribute Stripe Replicavolume）

条带复制卷（Stripe Replica volume）类似 RAID 1 0，同时具有条带卷和复制卷的特点。分布式条带复制卷（Distribute Stripe Replicavolume）三种基本卷的复合卷，通常用于类 Map Reduce 应用

优惠劵

白雪滑落树梢

关注

踩

觉得还不错?

一键收藏

知道了

一篇文章告诉你什么是GFS（分布式文件系统）

目录引言一、文件系统简介1. 组成2. 作用3. 文件系统的挂载使用二、GFS 分布式文件系统概述1. GFS 简介2. GFS 的特点3. GFS 专业术语4. 模块化堆栈式架构5. GFS 工作流程6. 各服务器详解三、GFS 卷类型1. 分布式卷（Distribute volume）1.2 分布式卷示例原理1.3 分布式卷特点1.4 创建分布式卷2. 条带卷（Stripe volume）2.1 条带卷示例原理2.2 条带卷特点2.3 创建条带卷3. 复制卷（Replica volume）3.1 复制

复制链接

扫一扫

专栏目录

GFS分布式文件系统

06-16

本文介绍GFS分布式文件系统的技术设计原理，是学习分布式文件系统的资料

GlusterFS 分布式文件系统

不要因为走的太远而忘了为什么出发

11-16

2413

参与评论

您还未登录，请先

后发表或查看评论

谷歌文件系统GFS理解

SwjtuPC的博客

03-22

6346

前言：

GFS是由Google设计并实现的一个可扩展的分布式文件系统，它适用于大型分布式计算密集型应用程序。与一般分布式文件系统具有诸多相同点，如性能、可伸缩性、可靠性和可用性，它的设计由Google应用工作负载和技术环境驱动。提出了一些不同的设计观点：

1.系统是由许多经常会故障的廉价商品组件组成，所以必须要经常对它进行监控，以及在例行基础上进行检测、容错，以及故障组件的恢复

2.系统存储了一定量的大文件。我们预计有数百万个文件，每个一般在100MB或更大。数GB的文件是很常见的情况，应该被有效的管理。小

详解 GFS分布式文件系统（条带卷/复制卷/分布式条带卷/分布式复制卷）

穷则独善其身达则兼善天下

07-17

1277

GFS分布式文件系统一.GlusterFS概述1.GlusterFS简介2.GlusterFS特点3. GlusterFS术语4.模块化堆栈式架构5. GlusterFS 工作流程6.弹性HASH算法7. GlusterFs的卷类型二. 部署GlusterFs 群集

一.GlusterFS概述

1.GlusterFS简介

① GlusterFS是一-个开源的分布式文件系统。

由存储服务器、客户端以及NFS/Samba存储网关(可选，根据需要选择使用)组成。

没有元数据服务器组件，这有助于提升整个系统的性能、

gfsrepo - GFS

05-10

gfsrepo - GFS

GlusterFS_分布式文件系统

Wsxyi的博客

05-11

468

GFS分布式文件系统一.概述1）文件系统组成(ext3,ext4)2）文件系统FS作用3）文件系统FS 的挂载使用4) 分布式文件系统(GFS)组成5)分布式文件系统(GFS)特点6）分布式文件系统(GFS)专业术语二.模块化堆栈架构模块部分：三.GFS工作原理

一.概述

GlusterFS:开源分布式文件系统，无元数据服务器

FS：文件系统

1）文件系统组成(ext3,ext4)

1.文件系统的接口(API)

2.对对象管理的软件集合

3.对象及属性

2）文件系统FS作用

对用户建立文件，存入，

【分布式系统】GFS(Google File System )详解

Yaoman753的博客

03-28

8729

GFS

是什么？

为什么要用GFS?

大量数据的存储会面临很多的难点：

所谓的一致性，就是在集群中表现的像与一台机器或一个副本进行交互那样

因为GFS不但是一个理论成熟的框架结构

搭建GFS分布式文件系统

12-15

一、GlusterFS概述；二、GlusterFS存储架构；三、GlusterFS工作原理；四、GlusterFS卷的类型；五、案例：搭建Gluster分布式文件系统

GFS分布式文件系统实验包

04-08

GFS分布式文件系统实验包

KVM+GFS分布式存系统构建KVM高可用

01-07

文章目录前言一：理论概述1.1：Glusterfs 简介1.2：Glusterfs 特点二：KVM高可用构建实操2.1：环境2.2：实验目的2.3：实验过程2.3.1：构建GFS集群2.3.2：安装KVM虚拟机2.3.3：GFS集群节点服务器添加磁盘2.3.4：KVM宿...

分布式文件系统-GFS1

08-08

分布式文件系统-GFS1

HDFS分布式文件系统

02-24

文件系统定义：文件系统是一种存储和组织计算机数据的方法，它使得对其访问和查找变得容易。文件名：在文件系统中，文件名是用于定位存储位置。元数据（Metadata）：保存文件属性的数据，如文件名，文件长度，文件...

第四十八章：GFS分布式文件系统1

08-08

2. 用户的这个操作被递交给本地linux系统的VFS来处理 3. VFS 将数据递交给FUSE 内核文件系统：在启动 glusterfs 客户端以前，需要

分布式系统学习——GFS谷歌文件系统Paper翻译1

08-08

第二，大型数据文件的规模出现导致文件观念的改变第三，文件的改变常为追加（append）而非覆盖（overwrite），对一个文件的随机写操作（random w

这些主流分布式存储系统，你都知道吗？

01-27

Hadoop分布式文件系统(HDFS)是一个分布式文件系统，适用于商用硬件上高数据吞吐量对大数据集的访问的需求。该系统仿效了谷歌文件系统(GFS)，数据在相同节点上以复制的方式进行存储以实现将数据合并计算的目的。该...

云计算中的分布式文件系统

02-21

云计算是一种基于互联网提供服务的业务模式,它能够实现IT...文章给出了云计算分布式文件系统的主要类型,分析了Google文件系统(GFS)和Hadoop分布式文件系统(HDFS)的演进情况。最后,详细描述了分布式文件系统的工作原理。

GFS分布式文件系统项目

GFS，一致性模型里，“已定义”和“不一致”具体表示的什么含义？ - 知乎

GFS，一致性模型里，“已定义”和“不一致”具体表示的什么含义？ - 知乎首页知乎知学堂发现等你来答切换模式登录/注册Hadoop分布式Google File SystemGFS，一致性模型里，“已定义”和“不一致”具体表示的什么含义？[图片]显示全部关注者72被浏览18,819关注问题写回答邀请回答好问题添加评论分享10 个回答默认排序EzeZ经历不多，只是探讨关注刚刚看了GFS论文，我来试答consistent（一致的）意思就是所有用户在查询同一个chunk的时候，看到的结果是一样的，不管他是从该chunk的哪一个replica（我们知道每个chunk都有几个replica），而不会出现A读了replica1, B读了replica2, 而A和B的结果不相同，要知道无论哪个replica都是同一个chunk的defined（定义的）这个词字面上不好理解，相信也是题主的困惑所在。首先，defined就包含了consistent，即如果一个chunk是defined，就一定是consistent的；其次，用户能够看到每一次mutation实际进行了什么操作写了什么数据。这是什么意思呢？这就牵扯出GFS的record append操作了以下是论文原话：Data mutations may be writes or record appends. A write causes data to be written at an application-specified file offset. A record append causes data (the "record") to be append atomically at least once even in presence of concurrent mutations, but at an offset of GFS's choosing.好了，write操作是由用户指定offset，那在并发的情况下，就有可能导致用户采用它觉得合理的offset，而实际上会导致并发写入的数据相互混合，这样，我们就无从得知这一堆混合的数据里，都是哪些操作分别写入了哪部分数据。但是在读的时候，又确实是相同的结果，此为 undefined but consistent而在实际的GFS场景中，record append是主要的操作（而不是write），GFS保证record append是atomic的，（至于这个at least once，我个人的理解是和append出错后保证客户端重试，直到每个record都是被原子地插入过一次）。原子化写入，配合GFS的operation log，就能够确定哪些数据是哪些操作写入的。继续往下读论文的 Lease and Mutation Order部分，我们知道，并发的mutation是被序列化并以相同顺序在各相关chunkserver中执行的。The primary assigns consecutive serial numbers to all the mutations it receives, possibly from multiple clients, which provides the necessary serialization.要知道，write操作由于不同用户指定了offset，系统是无法为其序列化的。而对于record append，GFS负责数据的offset并将其返回给用户。至于defined interspersed with inconsistent，就是那个at least once的结果，mutation在一些replica可能会失败而导致操作重试，或者因为重试导致的重复数据，或者会有一些无关数据填充（为了fit on 每个chunk的固定大小），所以会有一定量的inconsistent，但是，对于这种inconsistent，GFS是有相应措施去处理的，比如使用checksum和通过identifier忽略重复的record。好了，其他的还有许多细节，在论文中都有提到。编辑于 2015-01-15 23:40赞同 49添加评论分享收藏喜欢收起谭新宇天谋科技（北京）有限公司员工关注对着写入流程图讲讲"consistent but undefined"吧，讲完其它的就都好懂了：不论是 write 还是 atomic record append，其请求并发时在所有 replica 上的写入顺序都会由持有 lease 的 primary chunkserver 决定。之所以前者会导致 "consistent but undefined" 而后者不会，主要原因是他们处理数据跨越边界时的行为是不同的。如果一次写入的数据量跨过了一个 chunk 的边界，write 首先会写满当前 chunk，然后将剩余的数据在下一个 chunk 进行写入，这样在并发时即无法保证多个分片间数据写入的原子性；而 atomic record append 首先会用 padding 填充当前 chunk，然后再将所有数据在下一个 chunk 进行写入，这样就避免了跨越边界的写入分解成多个操作，从而保证了并发写入数据时的原子性。注意，atomic record append 限定了一次写入数据不大于 16MB，所以一个空分片一定能够至少承担一次 atomic record append，故其原子性始终能够得到保证。对于"consistent but undefined"的生成步骤，举例如下：文件目前有 2 个 chunk，分别是 chunk1, chunk2。用户有两个并发客户端，分别是 C1, C2。C1 要在 54MB 的位置写入 20MB 数据。这写入跨越了边界，要分解成 2 个操作，第一个操作写入 chunk1 最后 10 MB，第二个操作写入 chunk2 的开头 10MB。C2 也要在 54MB 的位置写入 10MB的数据。这个写入也跨越边界，也要分解为 2 个操作，作为第三个操作写入 chunk1 最后10 MB，作为第四个操作写入 chunk2 的开头 10MB。2 个客户端并发写入数据，那么第一个操作和第三个操作在 chunk1 上就是并发执行的，第二个操作和第四个操作在 chunk2 上并发执行，如果 chunk1 的先执行第一操作再执行第三个操作， chunk2 先执行第四个操作再执行第二个操作，那么最后，在 chunk1 上会保留 C1 写入的数据，在 chunk2 上保留了 C2 写入的数据。虽然 C1 和 C2 的写入都成功了，但最后既不是 C1 想要的结果，也不是 C2 想要的结果。最后的结果是 C1 和 C2 写入的混合。对于 C1 和 C2 来说，他们操作都不是原子的，这即是"consistent but undefined" 的含义。编辑于 2022-02-04 00:24赞同 261 条评论分享收藏喜欢

百度知道 - 信息提示

百度首页

商城

网页

资讯

视频

图片

知道

文库

贴吧采购

地图更多

搜索答案

我要提问

百度知道>提示信息

知道宝贝找不到问题了>_

该问题可能已经失效。返回首页

15秒以后自动返回

帮助

| 意见反馈

| 投诉举报

【分布式系统】GFS(Google File System )详解-CSDN博客

【分布式系统】GFS(Google File System )详解

最新推荐文章于 2024-03-11 21:26:06 发布

猎猎风中

最新推荐文章于 2024-03-11 21:26:06 发布

阅读量8.7k

点赞数

分类专栏：

分布式相关技术

文章标签：

分布式

GFS

本文链接：https://blog.csdn.net/Yaoman753/article/details/123786807

版权

分布式相关技术

专栏收录该内容

4 篇文章

1 订阅

订阅专栏

GFS

是什么？

为什么要用GFS?

大量数据的存储会面临很多的难点：

所谓的一致性，就是在集群中表现的像与一台机器或一个副本进行交互那样

因为GFS不但是一个理论成熟的框架结构，更是一种通过长期实际使用证明了其优秀性能的分布式架构。GFS是一种松散一致性模型，这是其具有优越的性能主要原因之一。

松散一致性模型关键：

依靠添加而不是重写检查点自我验证（校验和）自我认证记录

组成？

一个GFS集群通常由1个Master，多个ChunkServer组成，并同时接受多个Client的访问。

交互概要图

流程介绍：

client发送请求给Master，寻找存储了对应副本的chunkserver。 Master通过遍历本地记录获取chunkserver的信息，包括处理信息和地址信息

Master不但会在启动时获取集群中所有chunkserver的信息，还会在后续的周期性的获取chunkserver信息。所有的信息都是存在Master的RAM里

Master将信息返回给client client之后直接通过地址信息与chunkserver交互

GFS交互流程图

要点：

Master通过lease(租约)和Primary Replica(主副本)本来构建交互的流程。

Master是做出决策、创建新的块和赋值，并协调各种系统范围的活动，以保证块完全复制，平衡所有chunkserver的负载，同时还负责垃圾回收。

Master的操作通过锁来保证命名空间范围内的序列化

主副本是从众多chunkserver中选出的唯一特殊副本，该副本的特殊性在于其维护了一个定时的租约列表。租约指的是一组由用户发来的有顺序的指令集合主副本之外的副本都需要通过主副本中的这个列表来执行指令，以保证每个副本执行的最终结果相同。

Master失效怎么办

有副本master，拥有master状态的完整副本；GFS论文中设计需要人工干预才能切换到其中一种主故障后的副本。

如何保障副本记录的正确性

使用原子记录至少追加一次的方法。

为什么不使用完全追加？

如果在其中一个写入失败时客户端重新尝试写入，这将导致数据在未失败的副本上多次附加。不同的设计可能会检测到重复的客户端请求，例如，原始故障之间的主要故障请求和客户端的重试。

应用程序如何知道哪些部分组成填充，哪些是重复记录？

为了检测填充，应用程序可以放置一个可预测的幻数在有效记录的开头，或包含一个校验和，该校验和可能仅当记录有效时才有效。该应用程序可以检测通过在记录中包含唯一 ID 来复制。然后，如果它读取与先前记录具有相同 ID 的记录，它知道它们是彼此的重复。GFS 为应用程序提供了一个库处理这些情况。

什么是校验和？

校验和算法将一个字节块作为输入并返回一个单个数字，它是所有输入字节的函数。例如，一个简单校验和可能是输入中所有字节的总和（mod一些大数字）。GFS 存储每个块的校验和以及块。当一个chunkserver在它的磁盘上写一chunk时，它首先计算新块的校验和，并将校验和保存在磁盘上以及块。当一个chunkserver从磁盘读取一个chunk时，它还读取先前保存的校验和，从磁盘读取的块，并检查两个校验和是否匹配。如果数据已被磁盘损坏，校验和不匹配，并且chunkserver 会知道返回错误。另外，一些 GFS应用程序存储自己的校验和，而不是应用程序定义的记录，在 GFS 文件中，以区分正确的记录和填充。

GFS 以正确性换取性能在多大程度上可以接受

这是分布式系统中反复出现的主题。强一致性通常出现在需要复杂且需要交互的协议机器之间。经过利用特定应用程序类可以容忍的放松方式一致性，可以设计出具有良好性能和足够的一致性。例如，GFS 针对 MapReduce 进行了优化对大文件需要高读取性能的应用程序可以在文件中有漏洞，记录显示多次，并且不一致的读取。

Google 是否仍使用 GFS？

有传言说 GFS 已经被一个叫做Colossus，总体目标相同，但在 master 方面有所改进性能和容错性。

优惠劵

猎猎风中

关注

踩

觉得还不错?

一键收藏

知道了

【分布式系统】GFS(Google File System )详解

GFS是什么？GFS是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，并提供容错功能。它可以给大量的用户提供总体性能较高的服务。为什么要用GFS?大量数据的存储会面临很多的难点：大数据下需要良好的表现就需要分片和容错。在具体操作过程中，涉及到容错一般使用副本来解决，然而副本的使用会面临不一致问题。如果有一致性的要求，就会导致表现降低。所谓的一致性，就是在集群中表现的像与一台机器或一个副本进行交互那样因为GFS不但是一个理论成熟的框架结构

复制链接

扫一扫

专栏目录

GFS(Google File System)架构

02-27

GFS的架构，体现了很多经典的设计实践：

• 简化系统角色，单点master降低系统复杂度

• 不管是文件还是服务，均通过“冗余+故障自动转移”保证高可用

• 由于存在单点master，GFS将“降低与单点master的交互”作为性能优化核心

• 通过写日志，原子修改，checksum，快速监控快速恢复等方式保证可靠性与完整性

• 通过串行化保证多个副本数据的一致性

• 控制流与数据流分离，提高性能

GFS 分布式数据系统

Follow

imtoken安卓版app软件|gfs是什么意思

imtoken安卓版app软件|gfs是什么意思

三分钟带你弄懂GFS（Google File System）_gfs可以帮助google解决数据存储中的?-CSDN博客

硅谷之路9：深入浅出理解GFS - 知乎

GFS（Google 文件系统）_百度百科

【MIT 6.824】学习笔记 3: GFS - 知乎

Google File System - 知乎

GFS模型：它是什么，特征和重要性| 网络气象

一篇文章告诉你什么是GFS（分布式文件系统）-CSDN博客

GFS，一致性模型里，“已定义”和“不一致”具体表示的什么含义？ - 知乎

百度知道 - 信息提示

【分布式系统】GFS(Google File System )详解-CSDN博客

最近的新闻

您可能喜欢的文章

imtoken最新版钱包下载|五千万日元是多少人民币

im2.0钱包下载|中国银行汇率查询 实时

TP钱包HT如何兑换ETH

注册TP钱包-IP查找功能及用户隐私保护探讨

TP钱包跨链转账安全性分析

如何解决TP钱包互转BNB一直在确认中的问题

TP钱包官网下载苹果手机，让您安全便捷管理数字

im2.0钱包下载|中国银行汇率查询实时