HDFS原理分析(二)—— HA机制 avatarnode原理
2012-12-03 00:04
232 查看
一、问题描述
由于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的?
由于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的?
相关文章推荐
- HDFS原理分析之HA机制:avatarnode原理
- 3 视频里weekend05、06、07的可靠性 + HA原理、分析、机制 + weekend01、02、03、04、05、06、07的分布式集群搭建
- 基于QJM/Qurom Journal Manager/Paxos的HDFS HA原理及代码分析
- HDFS集群搭建,高可用双机热备模式(HA)自动切换,hdfs+zookeeper+journalnode,步骤分步原理详解(适合初学者)
- 大数据之路-Hadoop-5-HDFS原理解析及NameNode、DataNode工作机制
- Redis 原理及应用(3)--内存淘汰机制、主从同步原理,HA策略(哨兵机制)分析
- Ambari—HDFS配置NameNode HA高可用原理和操作步骤(一)
- 基于QJM/Qurom Journal Manager/Paxos的HDFS HA原理及代码分析
- Master原理剖析与源码分析:Master状态改变处理机制原理剖析与源码分析
- Hadoop详解(二)——HDFS的命令,执行过程,Java接口,原理详解。RPC机制
- HDFS源代码分析(二)-----元数据备份机制
- hadoop2.0的DataNode与NameNode交互机制相关代码分析
- HDFS原理分析(一)—— 基本概念
- hadoop分析之三org.apache.hadoop.hdfs.server.namenode各个类的功能与角色
- Android Handler 机制以及各方法所在线程原理分析
- hadoop HA机制分析
- HDFS HA系列实验之二:HA+JournalNode+zookeeper
- Redis实现原理:数据同步机制分析
- HDFS2.X源码分析之:NameNode写文件原理
- 大数据实战下笔记——Hadoop NameNode HA的原理