HDFS原理分析（二）—— HA机制 avatarnode原理

1、问题描述

因为namenode 是HDFS的大脑，而这个大脑又是单点，若是大脑出现故障，则整个分布式存储系统就瘫痪了。HA（High Available）机制就是用来解决这样一个问题的。碰到这么个问题，首先本能的想到的就是冗余备份，备份的方式有不少种，前辈们设计的有元数据备份方案，secondary namenode以及avatarnode等方案。而这些方案中最有优点的天然是可以让HDFS以最短的时间完成故障切换的方案。也就是咱们今天要讨论的avatarnode。

2、基本结构

primary：负责正常业务namenode，也就是为client提供元数据查询和操做。

standby：热备的namenode，彻底备份primary的元数据，并对primary作checkpoint（一种元数据持久化机制，后面会介绍到）。

NFS：网络文件服务器，primary会将日志实时同步一份到该服务器，来保证primary出故障时备份元数据的完整性。

3、数据持久化机制——checkpoint

primary管理着全部的元数据，一般元数据都保存在内存里，这样对元数据的访问可以高效。可是有个隐患，就是若是primary节点宕机了，或者掉电了，那么全部的元数据就一去不复返了。若是咱们可以把元数据在内存里保存一份，同时在硬盘上也保存一份，那么即便掉电也能将数据再恢复过来。

checkpoint机制就是将元数据实时在硬盘上保存一份的机制。

首先介绍几个关键概念：

edits：日志文件，记录引起元数据改变的操做。

fsimage：元数据的镜像文件，能够理解为元数据保存在磁盘上的一个副本。

问题1：fsimage表明的是某一时刻的元数据镜像，元数据在不断改变，那么这个镜像是如何实时更新的呢？

问题2：如何在保证primary namenode正常对外服务的状况下生成fsimage？

checkpoint步骤以下：

第一步：secondary namenode请求namenode中止使用edits，暂时记录在edits.new文件中

第二步：secondary namenode从namenode复制fsimage、edits到本地

第三步：secondary namenode合并fsimage、edits为fsimage.ckpt

第四步：secondary namenode发送fsimage.ckpt到namenode

第五步：namenode用新的fsimage覆盖旧的fsimage，用新的edits覆盖旧的edits

第六步：更新checkpoint时间

到这里fsimage更新完毕，即保证了primary正常服务，也完成了fsimage的更新

4、avatarnode元数据的一致性

checkpoint只是保证了元数据的持久化，可是若是primary出现故障，修复后仍是要花大量的时间来加载fsimage，如何让standby在内存中就和primary保持元数据同步，就是一个高可用的HDFS须要解决的问题。

namenode的元数据其实包括两个部分：

第一部分：目录树，目录树管理着HDFS中存储的全部的文件信息。

第二部分：块数据和datanode的对应关系

只要可以保证以上两部分的数据一致了，那么元数据的一致性问题就解决了。

第一部分：primary将日志实时同步到NFS上，而standby能够实时读取NFS上的日志，经过日志回放，能够解决目录树信息一致的问题。

第二部分：快数据和datanode的对应关系，是全部datanode想namenode汇报总结出来的，那么让全部的datanode向两个namenode汇报，就能够解决块数据和datanode的对应关系一致性问题。

问题：新引入的NFS会带来新的单点问题。据facebook工程师统计，这个单点故障率很是之低，他们在四年中之碰到一次。

 

到这里avatarnode原理基本讲完，可是实际应用中还存在几个问题：

一、HDFS是如何快速检测到primary出现故障的？

二、standby是如何迅速从备用机切换到primary的？