Hadoop官网翻译【Quorum Journal Manager】

勾裕

2023-12-01

背景

hdfs单点问题，可能是机器故障，可能是软硬件升级。
解决方案，使用冗余的NameNode做一个热备份。

架构设计

Standby和Active节点之间和JournalNodes通信，当Active节点执行修改时，持久把修改记录记录的JN中。Standby监测，并从JN中读取编辑。

1.如果突然大量的操作会怎么样？
2.JournalNodes如何被监控的？

为了提供快速的故障转移，Standby节点必须有关于集群中块位置的最新信息。DataNodes配置所有的Namenode的位置，向Namenode发送位置和心跳。

DataNodes发送了啥心跳？

为了防止脑裂，只能有一个Active Namenode的写入。

硬件要求

Active和StandBy的机器配置要求一样，JournalNode的守护线程相对较轻。要求是奇数个。

JournalNode 守护线程做了啥事情？

StandBy会执行检查点，所以不需要CheckpointNode和BackupNode，Second NameNode了。

部署

支持联邦，通过nameserviceId来区分不同的namenode属于一个集群，以及通过不同的namenodeId进行标识不同的namenode。

dfs.nameservices

<property>
  <name>dfs.nameservices</name>
  <value>mycluster</value>
</property>

dfs.ha.namenodes.[nameservice ID]

<property>
  <name>dfs.ha.namenodes.mycluster</name>
  <value>nn1,nn2, nn3</value>
</property>

dfs.namenode.rpc-address.[nameservice ID].[name node ID]

<property>
  <name>dfs.namenode.rpc-address.mycluster.nn1</name>
  <value>machine1.example.com:8020</value>
</property>
<property>
  <name>dfs.namenode.rpc-address.mycluster.nn2</name>
  <value>machine2.example.com:8020</value>
</property>
<property>
  <name>dfs.namenode.rpc-address.mycluster.nn3</name>
  <value>machine3.example.com:8020</value>
</property>

dfs.namenode.http-address.[nameservice ID].[name node ID]

<property>
  <name>dfs.namenode.http-address.mycluster.nn1</name>
  <value>machine1.example.com:9870</value>
</property>
<property>
  <name>dfs.namenode.http-address.mycluster.nn2</name>
  <value>machine2.example.com:9870</value>
</property>
<property>
  <name>dfs.namenode.http-address.mycluster.nn3</name>
  <value>machine3.example.com:9870</value>
</property>

dfs.namenode.shared.edits.dir

<property>
  <name>dfs.namenode.shared.edits.dir</name>
  <value>qjournal://node1.example.com:8485;node2.example.com:8485;node3.example.com:8485/mycluster</value>
</property>

dfs.client.failover.proxy.provider.[nameservice ID]

确定哪一个namenode是active的

<property>
  <name>dfs.client.failover.proxy.provider.mycluster</name>
  <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>

dfs.ha.fencing.methods
如果namenode failover，journalNode应该可以知道，然后执行脚本/方法把NameNode kill掉

这里面是猜测，需要日志佐证

fs.defaultFS
默认前缀

<property>
  <name>fs.defaultFS</name>
  <value>hdfs://mycluster</value>
</property>

dfs.journalnode.edits.dir
只可以配置单个路径，所有journalnode节点上都会

<property>
  <name>dfs.journalnode.edits.dir</name>
  <value>/path/to/journal/node/local/data</value>
</property>

dfs.ha.n.not-become-active-in-safemode

<property>
  <name>dfs.ha.nn.not-become-active-in-safemode</name>
  <value>true</value>
</property>

部署细节

hdfs -daemon start journalnode

部署新的HA系统，其中一个Namenode先format
非高可用转换为高可用，或者增加完成和format，另一个执行 hdfs namenode -bootstrapStandby，用来同步元数据到standby和editlog到journal node
如果非HA启动，hdfs namenode -initializeShareEdits 用来本地editlog到JournalNodes

高可用命令

haadmin

transitionToactive / transitionToStandby
failover
让当前的Namenode进行failover，如果发生故障转移，那么顺序尝试fencing，过程成功之后，第二个active状态，否则返回错误
getServiceState
getAllServiceState
checkHealth

LB配置

如果需要配置负载均衡器检查NN状态，可以curl http://NN_HOSTNAME/isActive

In-Progress Edit Log

Standby获取Journal内存中的Editlog
-dfs.ha.tail-edits.in-progress

dfs.journalnode.edit-cache-size.bytes

自动故障转移

ZKFC/ZKFailOverControlller功能如下:

Failure detection
每一个NameNodes机器提供一个ZK上的持久连接
Active NameNode election
ZK上的一个独占锁
Health monitoring
ZKFC ping Namenode，看看是不是正常
Zookeeper session management
ZKFC在ZK中保持一个Session级别的节点
Zookeeper-based election
通过锁选举，通过Fencing机制进行故障转移

部署自动转移

配置zk
关闭集群

hdfs-site.xml

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

core-site.xml

 <property>
  <name>ha.zookeeper.quorum</name>
  <value>zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181</value>
</property>

如果是多个nameservice，那么key值增加 mynameservice.id

启动顺序

zkfc -formatZK
hdfs --daemon start zkfc
这里面有一个ZK安全配置，可以确保ZK中的数据也是安全的
ZKFC故障转移时间默认是5s

QJM迁移

停止NN
启动JNS
NN单个节点升级，立马进行Active
后续节点执行 -bootstrapStandBy和主进行同步