本次部署产生的问题有很大一部分都是因为我用的不是特别老旧导致的。

相关信息

• 我大致跟随此博客来配置HA模式的hadoop+zookeeper。

• 官方文档

• hadoop:3.3.5

• zookeeper:3.8.4

• 使用docker容器模拟多机环境，基础镜像为ubuntu:22.04

设置允许使用start-dfs.sh拉起zkfc守护程序

根据Starting the cluster with start-dfs.sh一节，配置automatic failover功能后执行此脚本可以自动拉起zkfcdaemon，但是跟随那个博客部署成功并运行后发现并没有成功拉起zkfc守护程序，每个节点只能使用hdfs --daemon进行手动启动，非常麻烦。

经过检查后我发现跟随的教程对于automatic-failover的配置是

<property>
    <name>dfs.ha.automatic-failover.enabled.hadoopcluster</name>
    <value>true</value>
</property>

官方教程描述的默认参数格式则为

<property>
  <name>dfs.ha.automatic-failover.enabled</name>
  <value>true</value>
</property>

修改后发现可以直接拉起zkfc守护程序了。

如果active namenode down掉，无法选择新的standby节点提升为active节点

这一系列问题我检查了很久。

invalid privatekey

Unable to create SSH session com.jcraft.jsch.JSchException: invalid privatekey: [B@263a1f95

关键是invalid privatekey，后跟的乱码似乎是随机的。

stackoverflow中解释到：7.8及以后的版本的OpenSSH默认情况下生成新的OpenSSH格式的private key头，而JSch不支持（至少我使用的hadoop依赖的JSch不支持）。所以我直接用ssh-keygen -m PEM -t rsa生成rsa格式的密钥对。

关联问题“Invalid privatekey” when using JSch

批量替换密钥对并重复手动down掉active的namenode后，报错终于不是这个了，但是又出现了一个新的问题…………

报错com.jcraft.jsch.JSchException: Auth fail，但是可以使用ssh直接连接目标主机

以及相关日志

jsch: Authentications that can continue: publickey,keyboard-interactive,password
org.apache.hadoop.ha.SshFenceByTcpPort.jsch: Next authentication method: publickey
Authentications that can continue: password
Next authentication method: password
Disconnecting from <ip> port 22

看起来似乎是直接跳过了publickey的鉴权，也没输出什么相关日志，然后匹配password，但是发现没有设置password就直接退出，并抛出一长串的异常。

这是我花了很久的时间进行查找的问题，最后找到了这个问答

使用ssh -vvv复现后发现问题几乎一样，就是hadoop依赖的jsch不支持更新的rsa-sha2-512 key signature，但是由于我使用的基础镜像较新，默认ssh启用此签名方式。所以无法使用jsch连接sshd的同时也不抛出什么有意义的异常。
通过在ssh_config中添加PubkeyAcceptedAlgorithms +ssh-rsa，让sshd启用过时的ssh-rsa签名来允许jsch建立ssh连接。

配置完成后可以在手动关闭active的namenode后在很短的时间内从standby中选举出来一个新的namenode升级成active。我真的搭起来了Hadoop HA了这下。

(如果我用的是CentOS 7，这些问题或许就会因为上边的软件过旧，从而产生一个微妙的平衡，从而真的不会存在了哈哈。)