NameNode频繁切换active/standby的原因和解决

冷不防 2022-11-04 05:27 860阅读 0赞

**【导读】**  
若HA-Hadoop集群的active NameNode频繁出现自动切换，则可能的原因有二：  
（1）ZKFC的健康检查超时时长设置不合理，导致ZKFC认为NN挂掉（实际上此时的NameNode是正常active的，即“NameNode假死现象”），从而引起自动切换active NN；  
（2）Zookeeper上的Session Timeout导致zookeeper的服务端丢弃了当前持有的active锁（是一个临时znode），导致自动切换。

**【故障现象】**  
某天下午，钉钉群发出一条NameNode下线的告警，于是前往Ambari页面检查HDFS组件（我们用的HDP的Hadoop-3.1.1版本），发现NameNode正在切换主备，也就是Standby的NameNode正在切换为Active。切换完成后恢复正常，过了几分钟钉钉群又发出一条告警，内容也是NameNode下线，再去检查HDFS组件发现NameNoe（NN）又在做主备切换。之后半小时内又发生了几起NN主备切换事件。  
在NN切换主备期间，干扰到了数仓同学的作业，他们的反馈是Hive 客户端无法连接master1主机上的50070端口。50070端口是hdfs对外提供的http端口，客户端无法连接50070就意味着hdfs的外部用户无法操作HDFS上的数据了。数仓同学发来的报错信息截图如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNTk4MTEz_size_16_color_FFFFFF_t_70]  
在这么短的时间内发生多次NN主备切换，过于频繁，因此首先做一个根本原因分析（RCA，即Root Cause Analysis），再着手解决和预防。

**【RCA】**  
既然NameNode服务是由ZKFC、Zookeeper、JournalNode共同实现了高可用，那么就要查看一下zkfc日志、znode信息、NameNode日志、JournalNode日志。  
检查zookeeper相关的日志，未发现有关seesion超时的异常。  
检查zookeeper上的相关znode信息可以看出，nn2表示的master2是active，如截图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNTk4MTEz_size_16_color_FFFFFF_t_70 1]  
再来检查ZKFC的日志，摘要如下：

2021-01-14 16:57:45,571 WARN  ha.HealthMonitor (HealthMonitor.java:doHealthChecks(210)) - Transport-level exception trying to monitor health of NameNode at master1.data-hz.com/171.24.157.236:8020
    java.net.SocketTimeoutException: Call From master1.data-hz.com/171.24.157.236 to master1.data-hz.com:8020 failed on socket timeout exception: java.net.SocketTimeoutException: 45000 millis timeout while waiting for channel to be ready for read. ch : java.nio.channels.SocketChannel[connected local=/171.24.157.236:46140 remote=master1.data-hz.com/171.24.157.236:8020]; For more details see:  http://wiki.apache.org/hadoop/SocketTimeout
    Caused by: java.net.SocketTimeoutException: 45000 millis timeout while waiting for channel to be ready for read. ch : java.nio.channels.SocketChannel[connected local=/171.24.157.236:46140 remote=master1.data-hz.com/171.24.157.236:8020]

从zkfc服务日志中可以看出，master1节点上的NN在45000ms的时长内没有向zkfc进程的健康检查子进程发送存活消息，那么ZKFC就会判定此节点的NN不再active（而实际上此时master1上的NN是active状态的，“NameNode假死”）。于是ZKFC就会断开与zookeeper的连接，名为“/hadoop-ha/$\{your\_dfs\_cluster\}/ActiveStandbyElectorLock“的临时znode就会被zookeeper自动删除，之后master2节点的zkfc立即前往zookeeper竞争创建同名的临时znode，一旦成功创建则master2上的NN成为新的active NN，此时master2上的NN立即修改JournalNode集群中的epoch（也就是执行epoch + 1操作）。  
接下来检查master1节点上的NameNode的日志，摘要如下：

2021-01-14 16:58:51,036 WARN  client.QuorumJournalManager (IPCLoggerChannel.java:call(399)) - Remote journal 171.24.157.226:8485 failed to write txns 10598686066-10598686066. Will try to write to this JN again after the next log roll.
    org.apache.hadoop.ipc.RemoteException(java.io.IOException): IPC's epoch 246 is less than the last promised epoch 247 ; journal id: ${your_dfs_cluster}
    2021-01-14 16:58:51,053 WARN  client.QuorumJournalManager (IPCLoggerChannel.java:call(399)) - Remote journal 172.25.159.11:8485 failed to write txns 10598686066-10598686066. Will try to write to this JN again after the next log roll.
    org.apache.hadoop.ipc.RemoteException(java.io.IOException): IPC's epoch 246 is less than the last promised epoch 247 ; journal id: ${your_dfs_cluster}
    2021-01-14 16:58:51,066 FATAL namenode.FSEditLog (JournalSet.java:mapJournalsAndReportErrors(390)) - Error: flush failed for required journal (JournalAndStream(mgr=QJM to [172.25.159.11:8485, 171.24.157.226:8485, 171.24.157.230:8485], stream=QuorumOutputStream starting at txid 10598680688))
    org.apache.hadoop.hdfs.qjournal.client.QuorumException: Got too many exceptions to achieve quorum size 2/3. 3 exceptions thrown:
    171.24.157.226:8485: IPC's epoch 246 is less than the last promised epoch 247 ; journal id: ${your_dfs_cluster}
    172.25.159.11:8485: IPC's epoch 244 is less than the last promised epoch 247 ; journal id: ${your_dfs_cluster}
    171.24.157.230:8485: IPC's epoch 244 is less than the last promised epoch 247 ; journal id: ${your_dfs_cluster}

从master1上的NameNode日志可以看出，master1上的NN进程仍然认为自己是active状态，就去向JournalNode集群写入EditLog，但实际上此时JournalNode集群的epoch已经被master2上的NN更新了，master1上的NN持有的epoch不再是最新的值（或者叫最大的值），导致master1上的NN向JournalNode集群尝试写入EditLog的时候失败。  
下面的示意图描述了NN、ZKFC、JN之间是如何协作的：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNTk4MTEz_size_16_color_FFFFFF_t_70 2]  
**序号①和序号③表示：** master1主机和master2主机上都分别运行着ZKFC和NN。进程ZKFC的子进程包括HealthMonitor和ActiveStandbyElector，其中HealthMonitor负责定期对当前主机上的NN做健康检查，ActiveStandbyElector负责与zookeeper交互。在本案中，由于master1节点上的active NN未能在45秒内向HealthMonitor发送存活信息，于是在HealthMonitor的推动下进入序号②的操作。  
**序号②：** master1上的ActiveStandbyElector与zookeeper断开连接，那么临时节点“/hadoop-ha/$\{your\_dfs\_cluster\}/ActiveStandbyElectorLock”会被zookeeper删除（也就是释放锁）。  
**序号④：** master2上的ZKFC也有ActiveStandbyElector子进程，它一直在监视zookeeper上的同名临时节点（锁），当这个锁被释放时，master2上的ActiveStandbyElector就会前往zookeeper创建同名临时节点，创建成功则获得锁，于是进入序号⑤的操作  
**序号⑤：** master2上的NN状态变成active，并立即修改JournalNode集群中的epoch值，也就是执行epoch + 1操作。之所以active状态的NN要向JournalNode写入一个新的epoch值，是为了确保不出现两个NN同时向JournalNode写入数据的情况，也就是说只有持有最新epoch值的NN才能向JournalNode集群写入EditLog。  
**序号⑥：** 本案中，master1上的NN当时仍然认为自己是active状态（NN假死），它会向JournalNode集群写入EditLog，但是JournalNode集群发现master1的NN持有的epoch值已经落后于当前最新的epoch值（已由master2的NN更新），所以JournalNode会拒绝来自master1上的NN写入EditLog。

细心的同学可能有疑问：根据上面的描述，会不会同时出现两个active状态的NN（也就是脑裂现象）？其实不会。配置了高可用的HDFS有一个隔离机制，它能确保不发生脑裂。我们可以在Ambari页面的HDFS组件的配置项中查找配置项“dfs.ha.fencing.methods”的值，这个值一般是“shell(/bin/true)”，它的含义是：

（1）HDFS为了防止NN脑裂，会自动通过ssh到old active把NN杀掉，再把另一节点上处于standby状态的NN切换为active状态，这种方式只能在网络通畅时有用，当发生网络抖动或者网络故障时fencing method会返回false，standby NN就不会被自动切换为active，此时只能手动执行hdfs haadmin failover namenode1 namenode2来切换主备，所以需要另外配置shell(/bin/true)。
    （2）shell(/bin/true)的作用是，如果发生网络故障而且fencing method返回了false，就继续执行shell(/bin/true)，于是自动切换active-standby；若fencing method返回true则不执行shell(/bin/true)。

回顾本案，在发生频繁切换NN主备时，数仓同学的作业在短时间内创建或删除了大量文件，引发了active NN节点频繁更新本地内存的数据结构，这会导致RPC的处理时长增加，CallQueue中的rpcCall堆积（严重的情况下会撑满CallQueue），从而导致active状态的NN长时间不响应ZKFC的HealthMonitor子进程，于是ActiveStandbyElector就会断开与ZooKeeper的连接，从而释放锁，于是master2节点上的ActiveStandbyElector就会从zookeeper争抢锁，抢到锁之后的NN就会从standby转换成active状态。

【如何解决】  
先调高NameNode的参数ha.health-monitor.rpc-timeout.ms值，该参数位于core-site.xml文件中，此参数是指ZKFC的健康检查超时的时长，默认值45000ms，现已修改为120000ms（2分钟）。改完NN参数后，需要重启相关的NameNode。

另外，如果内存足够，可以顺便把两个NameNode的heap size适当调大一些。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNTk4MTEz_size_16_color_FFFFFF_t_70]: /images/20221023/89d3df9b913e423781221adf31ed0dc2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNTk4MTEz_size_16_color_FFFFFF_t_70 1]: /images/20221023/0ef22043aee64b268e29e41ae5fcecd8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNTk4MTEz_size_16_color_FFFFFF_t_70 2]: /images/20221023/7ffd5775896940e3817891b4d47172bb.png