Google File System

一、概述

Google的三篇论文：Google File System 、BigTable 、MapReduce的发表彻底拉开了云计算时代的序幕，同时这三篇论文也是想要入门云计算的学习人员必读的。最近读了这三篇论文，再参考了一些资料后写下自己的总结

HDFS 、HBase 、MapReduce

1. GFS
2. BigTable
3. MapReducd

Google系统整体的架构图如下

GFS系统的优点：高可用性、自动负载均衡

系统的结构：文件系统（GFS）、数据模型（Bigtable）、算法（MapReduce）、应用

在本篇文章中我们着重去描述GFS

二、GFS系统的设计

1.设计思路

​ （1）组件失效是一种常态，而不是意外；因此持续的监控、错误的侦测、灾难冗余等机制必须集成在GFS

​ （2）存储的文件非常巨大，基本上为TB级的，I/O操作和Block、Chunk的尺寸都需要规划

​ （3）对文件的修改以在文件尾部追加数据为主，数据的追加对系统性能有重要的影响

​ （4）应用程序和文件系统的API协同设计可以大幅度提高系统的灵活性

2.系统的工作负载分析

3.GFS系统架构

三、系统工作原理

设计原则：最小化所有的操作和Master节点的交互

系统具体的工作过程：

3.文件系统的操作

4.Master节点的操作

名称空间管理和锁

副本的位置

创建、重新复制、重新负载均衡、垃圾回收、过期失效的副本检测

5.容错和诊断

高可用性、数据完整性、诊断工具

四、总结

3.Linux文件系统工作原理：

​ 保存一个小文件

​ 保存的每一个文件都有一个元数据Metadata，其中包括filename文件信息 文件名 创建时间 文件大小 index组成文件的每一个Block的索引 关键点为1block = 1024 Byte

​ 保存一个大文件：

​ 关键点为chunk : 1chunk = 64MB =64*1024 =65536 blocks

​ 优点：减少元数据 减少流量 缺点：小文件会浪费较多空间

4.GFS的原理：

​ 将MetaData放入Master Server ,然后其他的Chunk都放在ChunkServer中

​ 关键点：Master+many ChunkServers

​ 缺点：ChunkServer中任何数据的改变都需要通知Master

​ 但是Master只保存了Chunk在各个服务器的地址，不记录每块数据的偏移量这样的优点是减少Master的元数据信息 减少Master和 ChunkServer之间的通信

5.GFS的容错机制

​ 客户端在读数据时检查checksum, 每一个Block 保存校验和, 1个checksum 是32位的，

​ 如果数据损坏的话，Chunk Server就需要去找Master恢复数据 具体的过程为：

​ （1） ChunkServer4 向Master服务器发送请求信息 "我的Chunk坏了，谁还有数据的备份"

​ （2）Master服务器向ChunkServer4发送 “ChunkServer1 和ChunkServer3 这两台服务器还有你数据的备份”

​ （3）ChunkServer4 向ChunkServer3(距离较近) 发送请求 "我需要备份的数据"

​ （4）ChunkServer3 便向ChunkServer4发送它所需要的数据

发送心跳检查ChunkServer是否运行正常 如果有服务器挂掉的话就向Master申请恢复 基于存活副本数的恢复策略

6.GFS核心的读写操作

读文件的过程

写文件的过程

如果在写入文件的过程中出现错误，那么就直接返回给客户端一个错误，让客户端自行去处理，对于分布式系统处理错误的机制会带来更多的错误，底层只是实现基本的功能，不去管错误的处理；