HDFS原理分析之HA机制：avatarnode原理

Posted 2020-08-04 哼哼哈哈二将

一、问题描述

　　由于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的？