分布式文件系统架构设计(20201126073806)

合集下载
相关主题
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

分布式文件系统架构设计

1. 前言...................................................... 3.

2. HDFS1 (3)

3. HDFS2 (5)

4. HDFS3 ............................................................................................. 1 1

5. 结语..................................................... 1.5

1. 刖言

Hadoop 是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下,开发分布式程序。充分利用集群的威力进行高速运算和存储。

Hadoop 实现了一个分布式文件系统(Hadoop Distributed File System ),简称HDFS,解

决了海量数据存储的问题;实现了一个分布式计算引擎MapReduce ,解决了海量数据如何计

算的问题;实现了一个分布式资源调度框架YARN,解决了资源调度,任务管理的问题。而我

们今天重点给大家介绍的是Hadoop 里享誉世界的优秀的分布式文件系统-HDFS。

Hadoop 重要的比较大的版本有:Hadoop1 ,Hadoop2 , hadoop3 。同时也相对应的有HDFS1 ,HDFS2,HDFS3三个大版本。后面的HDFS的版本,都是对前一个版本的架构进行了调整优

化,而在这个调整优化的过程当中都是解决上一个版本的架构缺陷,然而这些低版本的架构缺陷也是我们在平时工作当中会经常遇到的问题,所以这篇文章一个重要的目的就是通过给大家介绍HDFS不同版本的架构演进,通过学习高版本是如何解决低版本的架构问题从而来提升我

们的系统架构能力。

2. HDFS1

最早出来投入商业使用的的Hadoop 的版本,我们称为Hadoopl ,里面的HDFS就是HDFS1 ,

当时刚出来HDFS1,大家都很兴奋,因为它解决了一个海量数据如何存储的问题。HDFS1用的是主从式架构,主节点只有一个叫:Name node ,从节点有多个叫:DataNode 。

我们往HDFS上上传一个大文件,HDFS会自动把文件划分成为大小固定的数据块(HDFS1的时候,默认块的大小是64M,可以配置),然后这些数据块会分散到存储的不同的服务器上面,为了保证数据安全,HDFS1里默认每个数据块都有3个副本。Name node 是HDFS的主节

点,里面维护了文件系统的目录树,存储了文件系统的元数据信息,用户上传文件,下载文件

等操作都必须跟NameNode 进行交互,因为它存储了元数据信息,Name node 为了能快速

响应用户的操作,启动的时候就把元数据信息加载到了内存里面。DataNode 是HDFS的从节

点,干的活就很简单,就是存储block文件块。

01 / HDFS1 架构缺陷

缺陷一:单点故障问题(高可用)

我们很清楚的看到,HDFS1里面只有一个NameNode ,那么也就是说如果这个Name node 出问题以后,整个分布式文件系统就不能用了。

缺陷二:内存受限问题

NameNode 为了能快速响应用户的操作,把文件系统的元数据信息加载到了内存里面,那么

如果一个集群里面存储的文件较多,产生的元数据量也很大,大到name node 所在的服务器

撑不下去了,那么文件系统的寿命也就到尽头了,所以从这个角度说,之前的HDFS1的架构里Name node 有内存受限的问题。

我们大体能看得出来,在HDFS1架构设计中,DataNode 是没有明显的问题的,主要的问题

是在NameNode 这儿。

3. HDFS2

HDFS1明显感觉架构不太成熟,所以HDFS2就是对HDFS1的问题进行解决。

01 /单点故障问题解决(高可用)

大家先跟着我的思路走,现在我们要解决的是一个单点的问题,其实解决的思路很简单,因为

之前是只有一个NameNode ,所以有单点故障问题,那我们把设计成两个Name node 就可以了,如果其中一个name node 有问题,就切换到另外一个NameNode 上。

NameNode

所以现在我们想要实现的是:其中一个Name node 有问题,然后可以把服务切换到另外一个

Name node 上。如果是这样的话,首先需要解决一个问题:如何保证两个NameNode 之间的

元数据保持一致?因为只有这样才能保证服务切换以后还能正常干活。

保证两个NameNode 之间元数据一致

为了解决两个NameNode 之间元数据一致的问题,引入了第三方的一个JournalNode 集群。

IdumalnDde 集群

JournO'INodo Journal Nodo

L -riri -!

0$ 1 # ----------

Ail JF M

Jour nalNode 集群的特点:JournalNode 守护进程是相对轻量级的,那么这些守护进程可与

其它Hadoop 守护进程,如NameNode ,运行在相同的主机上。由于元数据的改变必须写入大多数(一半以上)JNs,所以至少存在3个JournalNodes 守护进程,这样系统能够容忍单

个Journal Node 故障。当然也可以运行多于3个JournalNodes ,但为了增加系统能够容忍

的故障主机的数量,应该运行奇数个JNs。当运行N个JNs时,系统最多可以接受(N-1)/2 个主机故障并能继续正常运行,所以Jou nal Node 集群本身是没有单点故障问题的。

元数据,StandBy 状态的NameNode 实时从Journal Node 集群同步元数据,这样就保证了

两个NameNode 之间的元数据是一致的。

两个NameNode 自动切换

引入了Journal Node 集群以后,Active状态的NameNode 实时的往Journal Node 集群写

相关文档
最新文档