理解NameNode的工作机制尤其是元数据管理机制,以增强对HDFS工作原理的理解,及培养hadoop集群运营中“性能调优”
“NameNode”故障问题的分析解决能力
1.NameNode职责:
Hadoop集群中有两种节点,一种是NameNode,还有一种是DataNode;其中DataNode主要负责数据的存储,NameNode主
要负责三个功能,分别是;(1)管理元数据 (2)维护目录树 (3)响应客户请求
2.元数据管理:
NameNode对数据的管理采用了三种存储形式:
1.内存元数据(NameSystem)
2.磁盘元数据镜像文件(fsImage)
3.数据操作日志文件(可通过日志运算出元数据)
3.NameNode元数据管理机制
首先介绍下,元数据格式:
hdfs在外界看来就是普通的文件系统,可以通过路径进行数据的访问等操作,但在实际过程存储中,却是分布在各个节点上。
如上图所示的是一条元数据,/test/a.log 是在hdfs文件系统中的路径,3是这个文件的副本数(副本数可以通过在配置文件中的
配置来修改的)。在hdfs中,文件是进行分块存储的,如果文件过大,就要分成多块存储,每个块在文件系统中存储3个副本,以
上图为例,就是分成blk_1和blk_2两个块,每个块在实际的节点中有3个副本,比如blk_1的3个副本分别存储在h0,h1,h3中
现在由此引出一个问题,Namenode中的元数据是存储在哪里的?首先,我们假设如果存储在Namenode节点的磁盘中,因为经
常需要进行随机访问,还有响应客户请求,必然是效率过低。因此,元数据需要存放在内存中。但如果只存在内存中,一旦断点,
元数据丢失,整个集群就无法工作了!!!因此必须在磁盘中有备份,在磁盘中的备份就是fsImage,存放在Namenode节点对应的
磁盘中。当在内存中的元数据更新时,如果同时更新fsImage镜像文件(文件的随机读写),会导致效率过低,但如果不更新,就会
发生一致性问题,一旦Namenode节点断电,就会产生数据丢失。因此,引入操作日志文件edits.log(只进行追加操作,效率很高)。
每当元数据有更新或者添加元数据时,修改内存中的元数据并追加到edits.log中。这样,一旦Namenode节点断电,可以通过镜像
文件fsImage和edits.log的合并,合成元数据。但是,如果长时间添加数据到edit.log中,会导致该文件数据过大,效率降低且一
旦断电,恢复元数据需要的时间过长。因此,需要定期进行fsImage和edits.log的合并,如果这个操作由Namenode节点完成,又会
效率过低。因此,引入一个新的节点secondaryNamenode,专门用于fsImage和edits.log的合并。
元数据的Checkpoint:每隔一段时间,由secondaryNamenode将Namenode上积累的所有edits和一个最新的fsimage下载到本地,
并加载到内存进行merge(这个过程称为checkpoint)
元数据的Checkpoint处理过程的具体步骤如下:
1)Namenode节点每隔一定时间请求secondaryNamenode合并操作(满足触发条件)
2)secondaryNamenode请求Namenode进行edits.log的滚动,这样新的编辑操作就能够进入新的文件中
3)secondaryNamenode从namenode中下载fsImage和edits.log
4)secondaryNamenode进行fsImage和edits.log的合并,成为fsImage.checkpoint文件
5)namenode下载合并后的fsImage.checkpoin文件
6)将fsImage.checkpoint和edits.new命名为原来的文件名(这样之后fsImage和内存中的元数据只差edits.new
元数据的Checkpoint机制流程图:
4.CheckPoint操作的触发条件配置参数
dfs.namenode.checkpoint.check.period=60 #检查触发条件是否满足的频率,60秒dfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary#以上两个参数做checkpoint操作时,secondary namenode的本地工作目录dfs.namenode.checkpoint.edits.dir=${dfs.namenode.checkpoint.dir}dfs.namenode.checkpoint.max-retries=3 #最大重试次数dfs.namenode.checkpoint.period=3600 #两次checkpoint之间的时间间隔3600秒dfs.namenode.checkpoint.txns=1000000 #两次checkpoint之间最大的操作记录
5.总结:
5.1.元数据存储机制
A、内存中有一份完整的元数据(内存metadata)
B、磁盘有一个“准完整”的元数据镜像(fsimage)文件(在namenode的工作目录中)
C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志(edits文件)
注:当客户端对hdfs中的文件进行新增或者修改操作,操作记录首先被记入edits日志文件中,当客户端操作成功后,相应的元数据
会更新到内存metadata中
5.2.如果NameNode的硬盘损坏,元数据是否还能恢复,如果能恢复,该如何恢复?
:可恢复绝大部分数据,NameNode和secondaryNamenode的工作目录存储结构完全相同,所以,当Namenode故障退出需要重新恢复时,
可以将SecondaryNamenode的工作目录拷贝到namenode的工作目录,以恢复namenode的元数据
5.3.如果NameNode宕机,hdfs服务能否正常提供?
:不能,虽然SecondaryNamenode有元数据信息,但不能更新元数据,不能充当NameNode使用;
5.4.通过以上思考,我们在配置NameNode工作目录参数时,应该注意什么?
:NameNode的工作目录应该配置在多块磁盘上,同时往多块磁盘上写日志,数据时相同的;
:修改NameNode的配置文件:vi /usr/local/src/hadoop-2.6.4/etc/hadoop/hdfs-site.xml
dfs.name.dir /disk1/name1,/disk2/name2
:然后重新对NameNode format :hadoop namenode -format,会重新生成两个name1和name2目录
:dfs.name.dir属性可以配置多个目录,各个目录存储的文件结构和内容完全相同,相当于备份,这样做的好处就是当其中
一个目录损坏了,也不会影响到Hadoop的元数据,
5.5.补充:该hdpdata/dfs/name/current/目录下的seen_txid文件:
:该文件中记录的是edits滚动的序号,每次重启NnmeNode时,NnmeNode就知道该加载哪些edits(序号小的)