hadoop 2.x之HDFS HA讲解之十WEB UI监控页面分析和查看NN与JN存储的编辑日志

到现在为止，我们已经配置了hadoop的HA，让我们通过页面去查看下hadoop的文件系统。

1. 分析active namenode和standby namenode对客户端服务的情况。



我们可以清楚看到hadoop文件系统的目录结构：



以上我们都是通过active的namenode访问hadoop的，那么如果我们通过standby namenode可不可以访问hadoop呢？



接下来我们看到，通过standby namenode是无法访问hadoop的文件系统的。根据提示，我们知道，standby namenode是不支持读操作的。



这也就证明了，在HA机制中，standby namenode是不能给客户端提供服务的。

2. 分析active namenode和standby namenode的datanode的情况。

在我们的HA配置中，总共有3个datanode，这3个datanode同时为active namenode和standby namenode服务。

第一：我们首先分析下standby namenode下的datanode个数情况以及standby namenode是从哪里读取编辑日志的。



通过上图我们知道，standby namenode下面有3个datanode, 并且standby namenode是通过QJM的方式读取编辑日志的。

第二，我们来查看一下active namenode是如何向三个journal node写编辑日志的。



我们可以看到当前的active namenode正在向3个journal node写编辑日志，当前的编辑日志的transaction id 是 41。

第三，我们来对比下active namenode和standby namenode的cluster ID，必定是相同的。





第四：对比Block ID，我们知道Block ID存储的是hadoop分布式文件系统的元信息，因为standby namenode是active namenode的备份节点，

他们管理的元信息应该是一样的，所以他们的Block ID应该也是相同的。





第五：现在我们去active namenode的存储目录中去看下。



有一个in_user.lock的文件，证明当前这个文件正在被使用。current 目录下存放的是当前的active namenode下存放的映像文件和编辑日志文件。

我们查看下current 目录下的文件：



有人肯定会有疑问，我们的编辑日志文件不是存放在journal node里面吗？为什么active namenode里面也会有编辑日志文件呢？

让我们来看下面的一张图，来解释下。我们发现，编辑日志文件在active namenode端始终是有的。当客户端请求namenode的时候，

namenode不仅将编辑日志写到本地，还会将编辑日志文件写QJM的节点中。



第六：现在我们去standby namenode的存储目录中去看下。



进入到current目录下面：



我们发现，这里只有映像文件，没有编辑日志文件。这里的映像文件，我们在启动的时候，使用的一个命令，将active namenode的映像文件完全复制过来的。



第七：现在我们去journal node为当前的namespace(ns1)创建的存储目录中去看下。



至于为什么要这么配置，官方文档有一个很好的说明：



我们先进去看下这个目录下存放的是什么？里面存放的应该是编辑日志。



首先是current 文件夹，然后current下面存放的是编辑日志。