HDFS的运行原理,如何实现HDFS的高可用

一.HDFS的运行机制

HDFS集群中的节点分为两种角色，一种角色负责管理整个集群的元数据，是名称节点（name node）；另一种角色负责存储文件数据块和管理文件数据块，是数据节点(datanode)。

1.1 NameNode

1.1.1名称节点负责响应客户端的请求，负责管理整个文件系统的元数据。

1.1.2HDFS的内部工作机制对客户端是透明的，客户端对HDFS的读、写操作都必须先向name node申请。所以元数据是关键。

1.1.3负责维持文件的副本数量

1.1.4 为了保证集群的元数据不丢失，生产环境下需要配置辅助名称节点(secondary name node,简称2NN),目的是帮助  NameNode 合并编辑日志，减少  NameNode 启动时间，万一name node的元数据丢失就可以从2NN恢复元数据。

1.1.5 名称节点可用的前提是此节点运行名为“NameNode”的进程。

1.2 数据节点Data Node

​ 1.2.1 负责存放被切割后的文件块。文件在data node的存储单位是块(block)。

​ 1.2.2 如果hadoop集群是完全分布式模式，那么一个文件的每一个块必须有多个副本，存放在不同的datanode上。当客户端把某个文件写入HDFS时，首先按照固定的块大小（block size）把该文件切成若干个块，再分布式地存储在若干台data node上。

​ 1.2.3 data node通过心跳信息定期地向name node汇报自身保存的文件块信息。

​ 1.2.4 数据节点可用的前提是此节点运行名为“DataNode”的进程。

1.3 客户端向HDFS写数据的流程

​ 1.3.1 客户端和name node通信，name node检查目标文件是否已存在，父目录是否存在,检查通过以后name node通知客户端可以写入

​ 1.3.2 客户端向name node请求上传文件的第一个块(block1),询问name node应该把block1上传到哪些data node主机上。客户端每传一个block都要向name node请求

​ 1.3.3 name node把3台data node服务器信息返回给客户端。基于可靠性的考虑，每个文件块都有副本，每个副本分别存放在不同的data node服务器上。副本存放的data node选择策略：首选在本地机架的一个节点上存放副本, 第二个副本在本地机架的另一个不同节点，第三个副本在不同机架的不同节点上

​ 1.3.4 正式上传之前，客户端请求与3台中的其中一台(dn1)建立传输通道，dn1又和dn2主机建立传输通道，dn2又和dn3建立传输通道

​ 1.3.5整个传输通道建立完成后，客户端把block1从磁盘读出来放到本地缓存, 开始向dn1上传block1，上传时以package为单位进行传输，package默认大小64kb。dn1每收到一个package就会复制一份传给dn2，dn2再复制一份传给dn3。

​ 1.3.6 当block1传输完成后，客户端再次向name node申请上传此文件的第二个块block2

1.4 客户端从HDFS读数据的流程

​ 1.4.1 客户端和name node通信，查询元数据，找到文件块存放的data node服务器信息

​ 1.4.2 客户端收到name node返回的信息(例如block1存放在dn1和dn2上，block2在dn2和dn3上)，去找到相应的dn(按就近挑选dn原则，然后随机)，再请求和dn建立socket流

​ 1.4.3 socket流建立好以后，dn开始向客户端发送数据（从磁盘读取数据放入socket流）

​ 1.4.4 客户端以packet为单位接收文件块，把各个块在本地合并成一个完整的文件

1.5 名称节点是如何管理元数据的？

Name node对数据的管理采用了三种存储形式：memory meta data, fsimage, edit log.

​ 1.5.1 memorymeta data：内存元数据。在name node服务器启动时会把fsimage从磁盘加载到内存，有了元数据就可以向客户端提供读、写服务了

​ 1.5.2 fsimage是在磁盘中的元数据镜像文件，整个文件系统的元数据（包括所有目录和文件inode序列化信息）都永久保存在此文件里；它位于name node的工作目录中

​ 1.5.3 edit logs是数据操作日志文件（可通过日志运算出元数据），客户端对HDFS中的文件进行写操作(增加或删除)之前，先把此操作行为记录到edit log文件中，再把成功操作代码发送给客户端。edit log需要定期通过checkpoint机制融合到fsimage，以保证name node的元数据是最新的，详见下面的描述。

1.6 若名称节点发生磁盘故障，如何挽救集群以及数据？

​ 这个需要提前单独准备一台主机，专门用于部署辅助名称节点（2NN）。同时，name node(NN)和2NN的工作目录存储结构完全相同，这样一来，一旦NN服务器挂掉，可以从2NN的工作目录中将fsimage拷贝到NN的工作目录，以恢复元数据。注意：这种补救措施是事后的，不能保证内存中的元数据是最新的，因为2NN不能充当name node使用(只有NN才能及时更新元数据)。要想让HDFS集群持续对外提供服务，需要引入高可用(HA)配置，HDFS高可用的原理可继续阅读下文。

​ 实际上2NN是用来备份NN中的元数据，备份的内容包括NN服务器上最新的fsimage文件以及全部的日志文件（edit log），备份的过程叫做checkpoint(检查点)，过程概要：每隔一段时间，会由2NN将NN上积累的所有edits和一个最新的fsimage下载到2NN本地，并加载到内存进行merge（融合），再把融合后的文件上传给NN。具体checkpoint流程如下：

​ 1.6.1 在做检查点之前，先让NN上正在写的日志文件滚动一下，以供2NN拷贝。日志文件和fsimage的路径可从配置文件hdfs-site.xml的dfs.namenode.name.dir属性中找到，例如我的元数据存放的路径是/home/centos/namemeta

<property>
<name>dfs.namenode.name.dir</name>
<value>/home/centos/namemeta</value>
</property>

下面有个子目录current存放所有的fsimage和edit log文件，查看此目录的树结构：

current/
|-- edits_0000000000000010612-0000000000000010613
|-- edits_0000000000000010614-0000000000000010615
|-- edits_0000000000000010616-0000000000000010617
|-- edits_inprogress_0000000000000010618
|-- fsimage_0000000000000010472
|-- fsimage_0000000000000010472.md5
|-- fsimage_0000000000000010563
|-- fsimage_0000000000000010563.md5
`-- seen_txid

​ 1.6.2 在HDFS集群首次做检查点时才会从NN下载最新的fsimage文件，以后做检查点时只需下载NN上的edit log(因为editlog比fsimage要小)。2NN有了fsimage和editlog，就可以在2NN服务器的内存中对二者进行融合，生成一个检查点文件fsimage.checkpoint，再把此文件上传到NN并重命名为fsimage文件

​ 1.6.3 NN根据刚才2NN传来的最新fsimage更新内存中的元数据

​ 1.6.4 默认是间隔30分钟做一次checkpoint

二.如何实现HDFS高可用

​ HDFS的高可用指的是HDFS持续对各类客户端提供读、写服务的能力，因为客户端对HDFS的读、写操作之前都要访问name node服务器，客户端只有从name node获取元数据之后才能继续进行读、写。所以HDFS的高可用的关键在于name node上的元数据持续可用。

​ 前面说过2NN的功能是checkpoint，把NN的fsimage和edit log做定期融合，融合后传给NN, 以确保备份到的元数据是最新的，这一点类似于做了一个元数据的快照。Hadoop官方提供了一种quorum journal manager来实现高可用，那么就没必要配置2NN了。

​ 在高可用配置下，edit log不再存放在名称节点，而是存放在一个共享存储的地方，这个共享存储由奇数个Journal Node组成，一般是3个节点(JN小集群)， 每个JN专门用于存放来自NN的编辑日志，编辑日志由活跃状态的NN写入JN小集群。

​ 那么要有两个NN，而且二者之中只能有一个NN处于活跃状态（active），另一个是待命状态（standby），只有active的NN节点才能对外提供读写HDFS服务，也只有active态的NN才能向JN写入编辑日志；standby状态的NN负责从JN小集群中拷贝数据到本地。另外，各个DATA NODE也要向active状态的NN报告状态(心跳信息、块信息等)。

​ 2个NN与3个JN构成的组保持通信，活跃的名称节点负责往JN集群写入编辑日志，待命的名称节点负责观察JN集群中的编辑日志,并且把日志拉取到待命节点，再加上两个NN各自的fsimage镜像文件，这样一来就能确保两个NN的元数据保持同步。一旦active NN不可用，提前配置的zookeeper会把standby节点自动变为active状态,继续对外提供读写服务。详见下文的 2.2如何通过自动容灾而不是手动容灾？

2.1手动实现高可用的大概流程：

​ 2.1.1 准备3台服务器分别用于运行JournalNode进程（也可部署在date node上），准备2台name node用于运行NameNode进程，Data Node数量不限

​ 2.1.2 分别启动3台JN服务器上的JournalNode进程，分别在date node服务器启动DataNode进程

​ 2.1.3 需要同步2台name node之间的元数据。具体做法：从第一台NN拷贝元数据到另一台NN，然后启动第一台的NameNode进程,再到另一台名称节点上做standby引导启动

​ 2.1.4 把第一台名节点的edit log初始化到JN节点，以供standby状态的NN到JN拉取数据

​ 2.1.5启动standby状态的名称节点，这样就能同步fsimage文件

​ 2.1.6 模拟故障，检验是否成功实现：手动把active状态的NN弄死，正常的话会自动把standby状态的NN转变成active.

2.2如何通过自动容灾而不是手动容灾？

​ 通过分布式协调服务者zookeeper来实现。

​ 自动容灾须引入两个组件：zk quarum + zk容灾控制器。

​ 运行NN的2台主机还要运行ZKFC进程（即DFSZKFailoverController），此进程负责健康监控、session管理、leader选举。

如何实现：

​ 2.2.7 在上面HA配置的基础上，要另外准备奇数台（一般是3台）主机安装zookeeper，形成一个小的zk集群.

​ 2.2.8 启动ZK集群每个节点上的QuorumPeerMain进程

​ 2.2.9 登录其中一台NN, 在ZK中初始化HA状态

​ 2.2.10 模拟故障：停掉活跃的NameNode进程，会发现自动切换active到另一台NN，模拟过程如下——

[centos@h201 current]$ xcall jps # 查看HDFS集群的每个节点上运行哪些进程

----------执行jps 在主机h201

44992 DFSZKFailoverController

46624 Jps

44110 QuorumPeerMain

44686 NameNode

命令已成功执行!----------

----------执行jps 在主机h202

17521 Jps

17210 DataNode

17021 QuorumPeerMain

17310 JournalNode

命令已成功执行!----------

----------执行jps 在主机h203

15777 JournalNode

15988 Jps

15494 QuorumPeerMain

15677 DataNode

命令已成功执行!----------

----------执行jps 在主机h204

16516 DataNode

16616 JournalNode

16826 Jps

命令已成功执行!----------

----------执行jps 在主机h205

23170 DFSZKFailoverController

23844 Jps

23064 NameNode

命令已成功执行!----------

[centos@h201 hadoop]$ hdfs haadmin -getServiceState nn1 #h201是第一台NN

active

[centos@h201 hadoop]$ hdfs haadmin-getServiceState nn2 # h205是另一台NN

standby

[centos@h201 hadoop]$jps

44992 DFSZKFailoverController

44110 QuorumPeerMain

44686 NameNode

47326 Jps

[centos@h201 hadoop]$kill -9 44686 # 模拟nn1故障, DFSZKFailoverController自动把nn2激活

[centos@h201 hadoop]$ hdfs haadmin-getServiceState nn2

active