目录
Hadoop 系统架构
保持主和备NameNode的状态同步,并让Standby在Active挂掉后迅速提供服务。
Hadoop1.x和Hadoop2.x 架构
Hadoop 1.x之前,其官方架构如图所示:
从图中可看出,1.x版本之前只有一个Namenode,所有元数据由唯一的Namenode负责管理,当这个NameNode挂掉时整个集群基本也就不可用。Hadoop 2.x的架构如图所示:
2.x版本中,HDFS架构解决了单点故障问题,即引入双NameNode架构(NameNode 的双机热备高可用
),同时借助共享存储系统来进行元数据的同步,这里Quorum Journal Manager(QJM)作为共享存储组件,通过搭建奇数结点的JournalNode实现主备NameNode元数据操作信息同步。
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。
上面所示的还有一个很重要的文件就是seen_txid,保存的是一个事务ID,这个事务ID是EditLog最新的一个结束事务id,当NameNode重启时,会顺序遍历从edits_0000000000000000001到seen_txid所记录的txid所在的日志文件,进行元数据恢复,如果该文件丢失或记录的事务ID有问题,会造成数据块信息的丢失。
HA其本质上就是要保证主备NN元数据是保持一致的,即保证fsimage和editlog在备NN上也是完整的。
QJM原理
QJM原理
QJM全称是Quorum Journal Manager,由JournalNode组成,一般是奇数点结点组成。每个JournalNode对外有一个简易的RPC接口,以供NameNode读写EditLog到JournalNode本地磁盘。当写EditLog时,NameNode会同时向所有JournalNode并行写文件,只要有N/2+1结点写成功则认为此次写操作成功,遵循Paxos协议。其内部实现框架如下:
从图中可看出,主要是涉及EditLog的不同管理对象和输出流对象,每种对象发挥着各自不同作用:
- FSEditLog:所有EditLog操作的入口
- JournalSet: 集成本地磁盘和JournalNode集群上EditLog的相关操作
- FileJournalManager: 实现本地磁盘上 EditLog 操作
- QuorumJournalManager: 实现JournalNode 集群EditLog操作
- AsyncLoggerSet: 实现JournalNode 集群 EditLog 的写操作集合
- AsyncLogger:发起RPC请求到JN,执行具体的日志同步功能
- JournalNodeRpcServer:运行在 JournalNode 节点进程中的 RPC 服务,接收 NameNode 端的 AsyncLogger 的 RPC 请求
- JournalNodeHttpServer:运行在 JournalNode 节点进程中的 Http 服务,用于接收处于 Standby 状态的 NameNode 和其它 JournalNode 的同步 EditLog 文件流的请求。<