HDFS原理分析(二)—— HA机制 avatarnode原理

一、问题描述

由于namenode 是HDFS的大脑,而这个大脑又是单点,如果大脑出现故障,则整个分布式存储系统就瘫痪了。HA(High Available)机制就是用来解决这样一个问题的。碰到这么个问题,首先本能的想到的就是冗余备份,备份的方式有很多种,前辈们设计的有元数据备份方案,secondary namenode以及avatarnode等方案。而这些方案中最有优势的自然是能够让HDFS以最短的时间完成故障切换的方案。也就是我们今天要讨论的avatarnode。

二、基本结构

HDFS原理分析(二)—— HA机制 avatarnode原理_第1张图片

primary:负责正常业务namenode,也就是为client提供元数据查询和操作。

standby:热备的namenode,完全备份primary的元数据,并对primary做checkpoint(一种元数据持久化机制,后面会介绍到)。

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

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

primary管理着所有的元数据,通常元数据都保存在内存里,这样对元数据的访问能够高效。但是有个隐患,就是如果primary节点宕机了,或者掉电了,那么所有的元数据就一去不复返了。如果我们能够把元数据在内存里保存一份,同时在硬盘上也保存一份,那么即使掉电也能将数据再恢复过来。

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

首先介绍几个关键概念:

edits:日志文件,记录引发元数据改变的操作。

fsimage:元数据的镜像文件,可以理解为元数据保存在磁盘上的一个副本。

问题1:fsimage代表的是某一时刻的元数据镜像,元数据在不断改变,那么这个镜像是如何实时更新的呢?

问题2:如何在保证primary namenode正常对外服务的情况下生成fsimage?

HDFS原理分析(二)—— HA机制 avatarnode原理_第2张图片

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的对应关系

HDFS原理分析(二)—— HA机制 avatarnode原理_第3张图片

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

第一部分:primary将日志实时同步到NFS上,而standby可以实时读取NFS上的日志,通过日志回放,可以解决目录树信息一致的问题。

第二部分:快数据和datanode的对应关系,是所有datanode想namenode汇报总结出来的,那么让所有的datanode向两个namenode汇报,就可以解决块数据和datanode的对应关系一致性问题。

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

 

到这里avatarnode原理基本讲完,但是实际应用中还存在几个问题:

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

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

你可能感兴趣的:(高可用,hdfs,NameNode,avatarnode)