Hadoop之系统架构及HA机制

1.Hadoop系统架构

1.1 Hadoop1.X 和 Hadoop2.X架构

在介绍HA之前，我们先来看下Hadoop的系统架构，这对于理解HA是至关重要的，Hadoop1.X之前，其官方架构如下图：

从上图可以看出，1.X版本之前只有一个NameNode，所有元数据由唯一的NameNode负责管理，可想而知当这个NameNode宕机时整个集群基本也就GG了。
Hadoop2.X的架构与1.X有什么区别呢？
我们来看一下2.X的架构：

上图为2.X版本，在2.X版本中，HDFS架构解决了单点故障问题，即引入NameNode架构，同时借助共享存储系统来进行元数据的同步，共享存储系统类型一般有这几类：Shared NAS+NFS、BookKeeper、BackupNode和Quorum Journal Manager（QJM），上图中用的是QJM作为共享存储组件，通过搭建奇数节点的JournalNode实现主备NameNode元数据操作信息同步。
那么Hadoop的元数据包括哪些信息呢，下面介绍关于元数据方面的知识。

1.2 Hadoop2.X 元数据

Hadoop的元数据主要作用是维护HDFS文件系统中文件 和目录相关信息。
元数据的存储形式主要有3类：
内存镜像、
磁盘镜像（FSImage）、
日志（EditLog）。

1.2.1

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

1.2.2

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

1.2.3

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

1.2.4

④ 如下所示为NameNode本地的EditLog和FSImage文件格式，EditLog文件有两种状态：inprocess 和 finalized，inprocess表示正在写的日志文件，文件名形式为：editsinprocess[start-txid]；

1.2.5

⑤ finalized表示已经写完的日志文件，文件名形式：
edits[start-txid] [end-txid];
FSImage也有两种状态：
finalized 和 checkpoint，finalized表示已经持久化磁盘的文件，文件名形式：fsimage_[end-txid],checkpoint 表示合并中的fsimage；

1.2.6

⑥ 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

1.2.7

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

1.2.8

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

2 Hadoop的HA机制

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

2.1 HA的运作机制

2.1.1 Hadoop-HA集群运作机制介绍

所谓HA，即高可用（7*24小时不中断服务），实现高可用最关键的是消除单点故障
Hadoop-HA 严格来说应该分为各个组件的HA机制——HDFS的HA、YARN的HA

2.1.2 HDFS的HA机制详解

通过双NameNode消除单点故障，双NameNode协调工作的要点：
（1）元数据管理方式需要改变：
① 内存中各自保存一份元数据
② Edits日志只能有一份，只有Active状态的NameNode节点可以做写操作
③ 两个NameNode都可以读取edits
④ 共享的edits放在一个共享存储器中管理（QJM流实现）
（2）需要一个状态管理功能模块
① 实现了一个zkfailover，常驻在每一个NameNode所在的节点
② 每一个zkfailover负责监控自己所在NameNode节点，利用zk进行状态标识
③ 当需要进行状态切换时，有zkfailover来负责切换

2.2 HDFS-HA图解：