Hadoop学习11：NameNode和Secondary NameNode的工作机制

1 NN和2NN的作用概述
2 基本原理
3 NN元数据信息维护到哪里?
4 数据同时维护到磁盘和内存带来的问题
- 4.1 如何保证内存和磁盘数据的同步
- 4.2 edits文件中记录的操作越来越多怎么办？
5 Secondary NameNode工作过程
6 fsimages和edits文件
- 6.1 文件简述
- 6.2 文件查看
- - 6.2.1 格式化选项
  - 6.2.2 元数据简述
  - 6.2.3 edits操作信息
7 CheckPoint参数设置
8 NameNode故障处理
9 集群安全模式
- 9.1 集群安全模式概念
- 9.2 集群安全模式操作
10 NameNode多目录配置

1 NN和2NN的作用概述

NameNode (nn)：就是Master，它是一个主管、管理者
1. 管理HDFS的名称空间
2. 配置副本策略
3. 管理数据块（Block)映射信息
4. 处理客户端读写请求
Secondary NameNode：并非NameNode的热备。当NameNode挂掉的时候，它并不能马上替换NameNode并提供服务
1. 辅助NameNode，分担其工作量，比如定期合并fsimage和fdits，并推送给NameNode
2. 在紧急情况下，可辅助恢复NameNode

fsimage ：它是在NameNode启动时对整个文件系统的快照
edit：它是在NameNode启动后，对文件系统的改动序列

2 基本原理

NameNode存储目录树的信息，而目录树的信息则存放在fsimage文件中，当NameNode启动的时候会首先读取整个fsimage文件，将信息装载到内存中
edits文件存储日志信息，在NameNode上所有对目录的操作，增加，删除，修改等都会保存到edits文件中，并不会同步到fsimage中，当NameNode关闭的时候，也不会将fsimage和edits进行合并

客户端的操作首先是写入到edits文件中，然后再进行操作内存中的数据

所以当NameNode启动的时候，首先装载fsimage文件，然后按照edits中的记录执行一遍所有记录的操作，最后把信息的目录树写入fsimage中，并删掉edits文件，重新启用新的edits文件
如果该合并过程只由NameNode去做，那么就会增加NameNode的压力，因为不仅需要处理合并还要处理客户端的请求
基于上述NameNode中fsimage和edits合并只在NameNode启动的时候才会进行，但是生产环境下，重启NameNode的时候edits往往非常大，而edits中保存的是操作相关的，往往也存在许多重复性操作，意味着做无用功且损耗效率
Secondary NameNode的职责分担NameNode的压力，按一定规则合并NameNode的edits到fsimage文件中。并且合并过程不影响NameNode的操作
- 合并合并规则：
1. 设置了定时，定时时间到请求相关文件并进行合并
2. edits文件的"数据满了"，例如达到一定的操作次数

以下详细介绍二者工作机制以

3 NN元数据信息维护到哪里?

如果考虑数据的可靠性，需要将元数据维护到磁盘.带来的问题是对磁盘的数据修改效率低
如果考虑数据访问和修改的效率，需要将元数据维护到内存。带来的问题是数据不可靠
综合考虑:磁盘+内存

4 数据同时维护到磁盘和内存带来的问题

4.1 如何保证内存和磁盘数据的同步

问题描述：因为数据的可靠性需要将数据写入到磁盘中，考虑到操作数据的效率就需要将数据写入到内存中，最终将内存的数据写入到磁盘中，那么二者如果不同步的话，就会存在数据丢失以及重复写数据的可能性

方案: 在内存中维护元数据，且在磁盘中通过fsimage(镜像文件)来维护元数据，并且通过edits(编辑日志)文件记录对元数据的修改操作，记录的方式为文件末尾追加操作。元数据信息可以存在内存中，fsimage(镜像文件)和edits(编辑日志)存在磁盘上，对数据的操作直接追加到edits文件末尾，这比随机写入要快很多

4.2 edits文件中记录的操作越来越多怎么办？

问题描述：fsimage和edits合并只在NameNode启动的时候才会进行，如果NameNode死机，那么在生产环境，重启NameNode的时候edits往往非常大，而edits中保存的是操作相关的，往往也存在许多重复性操作，意味着做无用功且损耗效率
方案：Secondary NameNode帮助NameNode合并文件

5 Secondary NameNode工作过程

Secondary NameNode请求是否需要CheckPoint（也就是合并的相关文件的构成）,NameNode回复执行
Secondary NameNode通知NameNode准备提交edits文件，假设此时的编辑日志文件是edits_inprogress_001，所有的客户端的操作首先追加到该日志中，当NameNode提交edits日志文件的时候该日志就定格为edits_001，滚动产生产生edits_inprogress_002，并将它提交给Secondary NameNode，新的操作信息存到新的日志文件中
SecondaryNameNode通过http get方式获取NameNode的fsimage与edits文件（在Secondary NameNode的current同级目录下可见到temp.check-point或者previous-checkpoint目录，这些目录中存储着从NameNode拷贝来的镜像文件）
3.Secondary NameNode开始合并获取的上述两个文件，产生一个新的fsimage文件fsimage.ckpt
Secondary NameNode用http post方式发送fsimage.ckpt至NameNode。
NameNode将fsimage.ckpt与edits.new文件分别重命名为fsimage与edits，然后更新fstime，整个checkpoint过程到此结束

6 fsimages和edits文件

6.1 文件简述

NameNode被格式化后会在指定的NameNode数据存储目录中，该目录在hdfs-site.xml指定，如下
在该目录下name/current文件夹下会产生以下文件

fsimage文件：HDFS文件系统元数据的一个永久性的检查点，其中包含HDFS文件系统的所有目录和文件inode的序列化信息。上图中存在两个版本的fsimages，后缀分别为1570和1572，1570为上一次合并的fsimages文件，1572表示是当前的
edits文件：存放HDFS文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到edits文件中。当前的日志文件都在上述目录中当前日志是edits_inprogress_0000000000000001573。历史日志文件后的数字范围表示的是数字是操作的次数，例如edits_001-edits_101表示做了100次操作
seen_txid文件保存的是一个数字，就是最后一个edits_的数字，如当前可以看到是edits_inprogress_0000000000000001573，也就是1573
每次NameNode启动的时候都会将fsimage文件读入内存，加载edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成NameNode启动的时候就将fsimage和edits文件进行了合并

6.2 文件查看

6.2.1 格式化选项

oiv：格式化输出fsimages
oev：格式化输出edits

#以XML的格式输出fsimage_0000000000000000975为当前目录下的fsimage.xml
hdfs oiv -p XML -i fsimage_0000000000000000975 -o ./fsimage.xml#以XML的格式输出edits_0000000000000000130-0000000000000000237为当前目录下的edits .xml
hdfs oev -p XML -i edits_0000000000000000130-0000000000000000237 -o ./edits .xml

6.2.2 元数据简述

fsimages文件中保存的是元数据信息，他包括了文件系统的目录结构，HDFS中文件目录是不实际在服务器创建对应的文件夹的，而是以元数据进行保存，上述格式化输出fsimages.xml文件，内容部分如下：

如上图中,每一个inode表示一个文件的元数据信息，包括inode的id以及类型，类型是由上述的type标签进行指定以及通过name标签指定他的名称，block指定他的块以及修改时间等信息
inode是单个文件或目录的元数据信息，他从层次关系是通过id进行实现的，也就是哪个目录下边存在什么文件

parent表示是父节点的id，child表示子节点的id，这样表示一个层次的关系
该数据结构中存在块的id信息，但是不能存在块是存在哪个DataNode上边的，当设置的副本数小于服务器节点数，就会按一定策略进行选择副本去存储。这个数据块及其存储的服务器信息，是在NameNode启动的时候由DataNode进行提交到NameNode的内存中的

6.2.3 edits操作信息

7 CheckPoint参数设置

Secondary NameNode可以定时或者到达一定的数据量（操作次数）就会去进行合并fsimages和edits文件，这个是可以在hdfs-site.xml文件进行配置的


<property><name>fs.checkpoint.period</name><value>3600</value><description>每3600秒进行一次合并</description>
</property><property><name>dfs.namenode.checkpoint.txns</name><value>1000000</value><description>操作动作次数达到1000000次进行合并</description>
</property><property><name>dfs.namenode.checkpoint.check.period</name>  <value>60</value><description> 1分钟检查一次操作次数是否达到配置的值</description>
</property>

8 NameNode故障处理

NameNode故障后，可以通过如下方法进行处理：将Secondary NameNode中数据拷贝到NameNode存储数据的目录。过程如下：

首先强制清除NameNode进行：shell kill -9 NameNode进程
通过rm -rf删除NameNode存储的数据，存储的位置可以在``hdfs-site.xml进行查看：rm -rf /opt/module/hadoop3.1.3/data/name`
可以通过scp命令进行拷贝Secondary NameNode下上述配置的目录到NameNode中

#递归拷贝目录
scp -r 2NN上的name目录  NN上的name目录scp -r cxj@hadoop103:/opt/module/hadoop3.1.3/data/name、* ./name/

Secondary NameNode可以恢复绝大部分数据，跟NameNode主要差异，就是Secondary NameNode中没有NameNode最新的编辑日志，因为编辑日志是按一定规则进行提交合并的，不符合条件的edits文件就存在于NameNode中，所以如果服务器出现问题需要进行NameNode的恢复，那么通过Secondary NameNode不一定可以完全恢复所有的数据

上述故障恢复做一个了解，目前使用的是HA的架构，会创建多个NameNode，当发生故障会自动切换到其他可用的NameNode

9 集群安全模式

9.1 集群安全模式概念

NaneNode启动
NameNode启动时，首先将镜像文件(fsimage) 载入内存,并执行编辑日志(edits) 中的各项操作。一旦在内存中成功建立文件系统元数据的映像，则创建一个新的fsimage文件和一个空的编辑日志。此时NameNode开始监听DataNode请求。这个过程期间，NameNode一直运行在安全模式，即NameNode的文件系统对于客户端未说是只读的
DataNode启动
系统中的数据块的位置并不是由NameNode维护的，而是以块列表的形式存储在DataNode中。在系统的正常操作期间，NameNode会在内存中保留所有块位置的映射信息。在安全模式下，各个DataNode会向NameNode发送最新的块列表信息，NameNode了解到足够多的块位置信息之后，即可高效运行文件系統
安全模式退出判断
如果满足“最小副本条件”，NameNode会在 30秒钟之后就退出安全模式。所谓的最小副本条件指的是在整个文件系统中99.9%的块满足最小副本级别(默认值: dfs replication.min=1),也就是知道每个块至少一个副本就可以正常启动或者在启动一个刚刚格式化的HDFS集群时，因为系统中还没有任何块，所以NameNode不会进入安全模式

集群进入安全模式的时候，不能正常操作，例如不能正常修改HDFS上的文件。
上述可以在Web端可以看到该字段，Safemode为off表示关闭

9.2 集群安全模式操作

#获取安全模式状态
hdfs dfsadmin -safemode get#开启安全模式
hdfs dfsadmin -safemode enter##关闭安全模式
hdfs dfsadmin -safemode leave#等待安全模式关闭，一般用在脚本中
hdfs dfsadmin -safemode wait

#wait实例：编写safe.sh脚本如下
hdfs dfsadmin -safemode wait
echo "Hello World"

在安全模式关闭的情况下直接执行以上脚本会直接输出Hello World
如果执行上述脚本的时候处于安全模式，那么整个命令行会处于一个阻塞的状态，可以通过其他的服务器关闭安全模式，在执行脚本的服务器就会解除阻塞状态并输出Hello World

10 NameNode多目录配置

多个NameNode存储目录保证NameNode的可靠性，但是理论上而言应该NameNode的存储目录要分配在不同的磁盘上，因为NameNode相关的存储放在一台服务器上的一个磁盘意义并不大，如下仅仅是在hdfs-site.xml中指定了一个目录

多目录文件配置，在hdfs-site.xml文件中只需要配置多个目录即可
磁盘挂载

临时挂载（重启服务器后消失消失)

#将name1目录挂载到/dev/sda1磁盘分区上以及将name2 目录挂载到/dev/sdb1上
mount /dev/sda1 ./name1
mount /dev/sdb1 ./name2

永久挂载

vim /etc/fstab

磁盘类型是看当初格式化磁盘的时候设置的,可以通过lsblk -f查看

配置好后使用输入mount -a命令自动挂载