Hadoop High Availability
hadoop的ha模式:
一般实际工作当中都要求我们的任务 7 *24 小时的可用
伪分布模式下,只有一个namenode,只有一个resourceManager,通过高可用,可以解决我们主节点单机故障的问题。
HA(High Available), 高可用,是保证业务连续性的有效解决方案,一般有两个或两个以上的节点,分为活动节点(Active)及备用节点(Standby)。从而实现业务的不中断或短暂中断。
Namenode HA
hadoop2.x之后,Clouera提出了QJM/Qurom Journal Manager,这是一个基于Paxos算法(分布式一致性算法)实现的HDFS HA方案,它给出了一种较好的解决思路和方案。
QJM主要优势如下:
不需要配置额外的高共享存储,降低了复杂度和维护成本。
消除spof(单点故障)。
系统鲁棒性(Robust)的程度可配置、可扩展。
基本原理就是用2N+1台 JournalNode 存储EditLog,每次写数据操作有>=N+1返回成功时即认为该次写成功,数据不会丢失了。
Yarn HA
从Hadoop 2.4.0版本开始,Yarn实现了ResourceManager HA,在发生故障时自动failover,大大提高了服务的可靠性。
在一个典型的HA集群中,两台独立的机器被配置成ResourceManger。在任意时间,有且只允许一个活动的ResourceManger,另外一个备用。切换分为两种方式:
手动切换:在自动恢复不可用时,管理员可用手动切换状态,或是从Active到Standby,或是从Standby到Active。
自动切换:基于Zookeeper,但是区别于HDFS的HA,2个节点间无需配置额外的ZFKC守护进程来同步数据。
Hadoop HA集群的搭建
在已有的伪分布式的基础上面搭建HA高可用集群
- 停止服务
停止oozie服务
node03停止oozie服务
cd /export/servers/oozie-4.1.0-cdh5.14.0
bin/oozied.sh stop
停止hue服务
node03停止hue的服务
停止impala服务
node03停止impala相关服务
service impala-catalog stop
service impala-state-store stop
service impala-server stop
node02停止impala相关服务
service impala-server stop
node01停止impala相关服务
service impala-server stop
停止hive服务
node03停止hive服务
通过kill命令直接杀死相关hive进程即可
停止hadoop服务
node01机器执行以下命令停止hadoop服务
cd /export/servers/hadoop-2.6.0-cdh5.14.0
sbin/stop-dfs.sh
sbin/stop-yarn.sh
sbin/mr-jobhistory-daemon.sh stop historyserver
-
启动所有节点的zookeeper服务
cd /export/servers/zookeeper-3.4.5-cdh5.14.0
bin/zkServer.sh start -
更改配置文件
更改四个文件:core-site.xml hdfs-site.xml mapred-site.xml yarn-site.xml
更改后将更改文件发到另外两台机器上。
scp core-site.xml hdfs-site.xml mapred-site.xml yarn-site.xml node02:$PWD
scp core-site.xml hdfs-site.xml mapred-site.xml yarn-site.xml node03:$PWD
在node3上配置rm1,在node2上配置rm2
注意:一般都喜欢把配置好的文件远程复制到其它机器上,但这个在YARN的另一个机器上一定要修改,其他机器上不配置此项。
将发送过去的在node2上的yarn-site.xml下面rm1需要改为rm2。
<property>
<name>yarn.resourcemanager.ha.id</name>
<value>rm1</value>
<description>If we want to launch more than one RM in single node, we need this configuration</description>
</property>
- 服务的启动
初始化zookeeper
在node01机器上进行zookeeper的初始化,其本质工作是创建对应的zookeeper节点
cd /export/servers/hadoop-2.6.0-cdh5.14.0
bin/hdfs zkfc -formatZK
启动journalNode
三台机器执行以下命令启动journalNode,用于我们的元数据管理
cd /export/servers/hadoop-2.6.0-cdh5.14.0
sbin/hadoop-daemon.sh start journalnode
初始化journalNode
node01机器上准备初始化journalNode
cd /export/servers/hadoop-2.6.0-cdh5.14.0
bin/hdfs namenode -initializeSharedEdits -force
启动namenode
node01机器上启动namenode
cd /export/servers/hadoop-2.6.0-cdh5.14.0
sbin/hadoop-daemon.sh start namenode
node02机器上启动namenode
cd /export/servers/hadoop-2.6.0-cdh5.14.0
bin/hdfs namenode -bootstrapStandby
sbin/hadoop-daemon.sh start namenode
启动所有节点的datanode进程
在node01机器上启动所有节点的datanode进程
cd /export/servers/hadoop-2.6.0-cdh5.14.0
sbin/hadoop-daemons.sh start datanode
启动zkfc
在node01机器上面启动zkfc进程
cd /export/servers/hadoop-2.6.0-cdh5.14.0
sbin/hadoop-daemon.sh start zkfc
在node02机器上面启动zkfc进程
cd /export/servers/hadoop-2.6.0-cdh5.14.0
sbin/hadoop-daemon.sh start zkfc
启动yarn进程
node03机器上启动yarn集群
cd /export/servers/hadoop-2.6.0-cdh5.14.0
sbin/start-yarn.sh
node02机器上启动yarn集群
cd /export/servers/hadoop-2.6.0-cdh5.14.0
sbin/start-yarn.sh
启动jobhsitory
node03节点启动jobhistoryserver
cd /export/servers/hadoop-2.6.0-cdh5.14.0
sbin/mr-jobhistory-daemon.sh start historyserver
Hadoop Federation
单NameNode的架构使得HDFS在集群扩展性和性能上都有潜在的问题,当集群大到一定程度后,NameNode进程使用的内存可能会达到上百G,NameNode成为了性能的瓶颈。因而提出了namenode水平扩展方案-- Federation。
NameNode的Federation,也就是会有多个NameNode。
多个NameNode的情况意味着有多个namespace(命名空间),区别于HA模式下的多NameNode,它们是拥有着同一个namespace。
Federation架构设计
Federation 的namenode之间是联合的,他们之间相互独立且不需要互相协调,各自分工,管理自己的区域。这些NameNode是共享集群中所有的DataNode的,它们还是在同一个集群内的。
HDFS Federation不足
HDFS Federation并没有完全解决单点故障问题。虽然namenode/namespace存在多个,但是从单个namenode/namespace看,仍然存在单点故障:如果某个namenode挂掉了,其管理的相应的文件便不可以访问。
Federation中每个namenode仍然像之前HDFS上实现一样,配有一个secondary namenode,以便主namenode挂掉一下,用于还原元数据信息。
当集群规模很大的时候可以考虑HA+Federation的部署方案。