hdfs是nas_hadoop-HDFS-HA的详解

1 Hadoop 系统架构

1.1 Hadoop1.x和Hadoop2.x 架构

在介绍HA之前，我们先来看下Hadoop的系统架构，这对于理解HA是至关重要的，Hadoop

1.x之前，其官方架构如图1所示:

[ 图1.Hadoop 1.x架构图 ]

从图中可看出，1.x版本之前只有一个Namenode,所有元数据由惟一的Namenode负责管理,可想而之当这个NameNode挂掉时整个集群基本也就不可用。

Hadoop 2.x的架构与1.x有什么区别呢。我们来看下2.x的架构：

[ 图2.Hadoop 2.x架构图 ]

2.x版本中，HDFS架构解决了单点故障问题，即引入双NameNode架构，同时借助共享存储系统来进行元数据的同步，共享存储系统类型一般有几类，如：Shared

NAS+NFS、BookKeeper、BackupNode 和 Quorum Journal

Manager(QJM)，上图中用的是QJM作为共享存储组件，通过搭建奇数结点的JournalNode实现主备NameNode元数据操作信息同步。

Hadoop的元数据包括哪些信息呢，下面介绍下关于元数据方面的知识。

1.2 Hadoop 2.x元数据

Hadoop的元数据主要作用是维护HDFS文件系统中文件和目录相关信息

元数据的存储形式主要有3类：内存镜像、磁盘镜像(FSImage)、日志(EditLog)。

在Namenode启动时，会加载磁盘镜像到内存中以进行元数据的管理，存储在NameNode内存；

磁盘镜像是某一时刻HDFS的元数据信息的快照，包含所有相关Datanode节点文件块映射关系和命名空间(Namespace)信息，存储在NameNode本地文件系统；

日志文件记录client发起的每一次操作信息，即保存所有对文件系统的修改操作，用于定期和磁盘镜像合并成最新镜像，保证NameNode元数据信息的完整，存储在NameNode本地和共享存储系统(QJM)中。

如下所示为NameNode本地的EditLog和FSImage文件格式，EditLog文件有两种状态：

inprocess和finalized,

inprocess表示正在写的日志文件，文件名形式:editsinprocess[start-txid]

finalized表示已经写完的日志文件,文件名形式：edits*[start-txid]*[end-txid]；

FSImage文件也有两种状态, finalized和checkpoint，

finalized表示已经持久化磁盘的文件，文件名形式: fsimage_[end-txid],

checkpoint表示合并中的fsimage

2.x版本checkpoint过程在Standby

Namenode(SNN)上进行，SNN会定期将本地FSImage和从QJM上拉回的ANN的EditLog进行合并，合并完后再通过RPC传回ANN。

data/hbase/runtime/namespace

├── current

│ ├── VERSION

│ ├── edits_0000000003619794209-0000000003619813881

│ ├── edits_0000000003619813882-0000000003619831665

│ ├── edits_0000000003619831666-0000000003619852153

│ ├── edits_0000000003619852154-0000000003619871027

│ ├── edits_0000000003619871028-0000000003619880765

│ ├── edits_0000000003619880766-0000000003620060869

│ ├── edits_inprogress_0000000003620060870

│ ├── fsimage_0000000003618370058

│ ├── fsimage_0000000003618370058.md5

│ ├── fsimage_0000000003620060869

│ ├── fsimage_0000000003620060869.md5

│ └── seen_txid

└── in_use.lock

上面所示的还有一个很重要的文件就是seen_txid,保存的是一个事务ID，这个事务ID是EditLog最新的一个结束事务id，当NameNode重启时，会顺序遍历从edits_0000000000000000001到seen_txid所记录的txid所在的日志文件，进行元数据恢复，如果该文件丢失或记录的事务ID有问题，会造成数据块信息的丢失。

HA其本质上就是要保证主备NN元数据是保持一致的，即保证fsimage和editlog在备NN上也是完整的。元数据的同步很大程度取决于EditLog的同步，而这步骤的关键就是共享文件系统，下面开始介绍一下关于QJM共享存储机制。

2 Hadoop的HA机制

前言：正式引入HA机制是从hadoop2.0开始，之前的版本中没有HA机制

1.1 HA的运作机制

(1)hadoop-HA集群运作机制介绍

所谓HA，即高可用(7*24小时不中断服务),实现高可用最关键的是消除单点故障

hadoop-ha严格来说应该分成各个组件的HA机制——HDFS的HA、YARN的HA

(2)HDFS的HA机制详解

通过双namenode消除单点故障,双namenode协调工作的要点：

A、元数据管理方式需要改变：

(1)内存中各自保存一份元数据

(2)Edits日志只能有一份，只有Active状态的namenode节点可以做写操作

(3)两个namenode都可以读取edits

(4)共享的edits放在一个共享存储中管理(qjournal和NFS两个主流实现)

B、需要一个状态管理功能模块

(1)实现了一个zkfailover，常驻在每一个namenode所在的节点

(2)每一个zkfailover负责监控自己所在namenode节点，利用zk进行状态标识

(3)当需要进行状态切换时，由zkfailover来负责切换

(4)切换时需要防止brain split现象的发生

1.2 HDFS-HA图解：