标签：
一、问题描述
由于namenode 是HDFS的大脑，而这个大脑又是单点，如果大脑出现故障，则整个分布式存储系统就瘫痪了。HA（High Available）机制就是用来解决这样一个问题的。碰到这么个问题，首先本能的想到的就是冗余备份，备份的方式有很多种，前辈们设计的有元数据备份方案，secondary namenode以及avatarnode等方案。而这些方案中最有优势的自然是能够让HDFS以最短的时间完成故障切换的方案。也就是我们今天要讨论的avatarnode。
二、基本结构
primary：负责正常业务namenode，也就是为client提供元数据查询和操作。
standby：热备的namenode，完全备份primary的元数据，并对primary做checkpoint（一种元数据持久化机制，后面会介绍到）。
NFS：网络文件服务器，primary会将日志实时同步一份到该服务器，来保证primary出故障时备份元数据的完整性。
三、数据持久化机制——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的更新
四、avatarnode元数据的一致性
checkpoint只是保证了元数据的持久化，但是如果primary出现故障，修复后还是要花大量的时间来加载fsimage，如何让standby在内存中就和primary保持元数据同步，就是一个高可用的HDFS需要解决的问题。
namenode的元数据其实包括两个部分：
第一部分：目录树，目录树管理着HDFS中存储的所有的文件信息。
第二部分：块数据和datanode的对应关系
只要能够保证以上两部分的数据一致了，那么元数据的一致性问题就解决了。
第一部分：primary将日志实时同步到NFS上，而standby可以实时读取NFS上的日志，通过日志回放，可以解决目录树信息一致的问题。
第二部分：快数据和datanode的对应关系，是所有datanode想namenode汇报总结出来的，那么让所有的datanode向两个namenode汇报，就可以解决块数据和datanode的对应关系一致性问题。
问题：新引入的NFS会带来新的单点问题。据facebook工程师统计，这个单点故障率非常之低，他们在四年中之碰到一次。
到这里avatarnode原理基本讲完，但是实际应用中还存在几个问题：
1、HDFS是如何快速检测到primary出现故障的？
2、standby是如何迅速从备用机切换到primary的？
标签：
原文地址：http://www.cnblogs.com/snowbook/p/5811482.html
