背景
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和主进行同步