在HDFS集群的时候我们知道,NameNode只有一个,如果现在NameNode挂掉了,或者NameNode需要硬件或者软件的升级,那么势必就有单点问题。那么HDFS HA就是来解决这个问题的。
HA架构图:
集群需要考虑的问题:
1 我们要考虑两个NM之间的元数据是共享或者同步的
NM启动的时候,会去读取fsimage和 edits文件,那么备份NM也需要读取这两个文件
而且随着ActiveNM会记录元数据的变化,那么StandbyNM也需要随时同步元数据的变化
2 必须保证日志文件的安全
方案讨论:
解决方案【一】
在以前我们可能找一些质量比较好的机器,存储相关的数据或者文件
然后ActiveNM 负责写,然后StandbyNM负责读,也能实现同步,但是成本太高
解决方案【二】
Cloudera公司提出分布式存储日志文件,日志备份数目(2n+1)
解决方案【三】
使用Zookeeper+Journalnode
另外我们不在需要SecondaryNM,因为启用SecondaryNM的目的是合并NameNode的fsimage和 edits文件,以便节省下一次NM启动的时候减少启动时间
现在有了StandbyNM 它和ActiveNM是实时同步的,所以就不需要SecondaryNM
搭建HadoopHA集群,可能有很多种方法,我们这里采用官方文档所提供的使用QJM (QuorumJournal Manager)仲裁日志管理的方式。
首先因为不需要SecondaryNM,所以相关的配置需要去掉。
创建目录:
/opt/app/hadoop-2.5.0/data/tmp/dfs/journal
mkdir -p /opt/app/hadoop-2.5.0/data/tmp/dfs/journal
scp -r hadoop-2.5.0/ hadoop@hadoop-cluster-03:/opt/app
scp -r hadoop-2.5.0/ hadoop@hadoop-cluster-03:/opt/app
/opt/app/hadoop-2.5.0/sbin/hadoop-daemon.sh start journalnode
如果启动成功应该有一个JournalNodejava进程
我们规划hadoop-cluster-01为ActiveNameNode;然后http://hadoop-cluster-02为StandbyNameNode
/opt/app/hadoop-2.5.0/bin/hdfsnamenode -format
另外一台机器不需要格式化,因为他们管理的是同一份元数据。如果元数据都不相同,那么主备也就没什么意思呢。
启动ActiveNameNode:
/opt/app/hadoop-2.5.0/sbin/hadoop-daemon.sh start namenode
/opt/app/hadoop-2.5.0/bin/hdfs namenode -bootstrapStandby
启动StandbyNameNode:
/opt/app/hadoop-2.5.0/sbin/hadoop-daemon.sh start namenode
这时候当我们访问:
http://hadoop-cluster-01:50070/ 和http://hadoop-cluster-02:50070/
都还是standby状态,因为这时候都是待机状态,所以需要我们指定ActiveNameNode切换Active状态
/opt/app/hadoop-2.5.0/bin/hdfs haadmin -transitionToActive
namenode100
这时候ActiveNameNode 状态就是Active了,如图示:
./hdfs dfs -mkdir -p /var/hadoop/input
./hdfs dfs -put /opt/shell/hadoop.sh /var/hadoop/input
./hdfs dfs -cat /var/hadoop/input/hadoop.sh
先杀掉ActiveNameNode进程
kill -9 10223
然后把Standby状态强制转换成Active
/opt/app/hadoop-2.5.0/bin/hdfs haadmin -transitionToActive
namenode101--forceactive
./hdfs dfs -cat /var/hadoop/input/hadoop.sh
根据之前的配置,我们知道,如果ActiveNM挂了,那么Standby是需要我们手动切换才能转移状态,然后才对外提供服务的。
那如果是半夜宕机了,我们怎么办呢,所以我们需要一种自动故障转移的需求。
这时候需要使用到2个新的组件:
ZooKeeperquorum 和 ZKFailoverControllerprocess.
ZKFC是一个新的组件,它是一个ZooKeeper客户端,能够监视和管理NameNode的状态。每一台NameNode节点 都会运行一个ZKFC.负责:
HealthMonitoring: 健康监视,ZKFC会定期的用一个健康检查命令去ping本地的NameNode,只要NameNode即使做出响应,就被认为事实健康的。如果NameNode挂掉,假死或者其他原因造成不健康的状态,健康监视器它会标记为不健康状态
ZooKeepersession management: Zookeeper 会话管理。当本地NameNode是健康的,ZKFC在Zookeeper会持有一个session,如果ActiveNameNode是健康的,他会持有一个锁 znode,如果session到期,这个lockznode将会自动释放
ZooKeeper-basedelection:基于ZooKeeper的选举。如果本地NameNode是健康的,他会去查看是不是没有其他node在持有锁,他自己会去询问这个锁,如果成功,他将赢得选举。
我们需要在core-site追加如下配置:
<!--指定运行zookeeper的节点信息,多个用逗号分割-->
<property>
<name>ha.zookeeper.quorum</name>
<value>hadoop-cluster-01:2181,hadoop-cluster-02:2181,hadoop-cluster-03:2181
</value>
</property>
我们需要在hdfs-site.xml追加以下的配置:
<!--安装automiaticfailover-->
<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>
初始化会在Zookeeper生成一个hadoop-ha的znode.
/opt/app/hadoop-2.5.0/bin/hdfs zkfc -formatZK
只需要一台机器初始化就行。
在zookeeper查看是否创建集群成功
/opt/app/zookeeper-3.4.6/bin/zkCli.sh
然后ls / 如果成功会看到/hadoop-ha节点
/opt/app/hadoop-2.5.0/sbin/stop-dfs.sh
/opt/app/hadoop-2.5.0/sbin/start-dfs.sh
这时候你会发现每一个namenode都起了一个这样的进程:
DFSZKFailoverController
如果你没发现有这样的进程启动,你也是可以手动启动的:
/opt/app/hadoop-2.5.0/sbin/hadoop-daemon.sh start zkfc
杀掉ActiveNameNode 进程
kill-9 11708
现在查看StandbyNameNode:
本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。