大数据学习-Hadoop生态章
(二) HA高可用
2.1. Hadoop 2.0产生背景
Hadoop 1.0中HDFS和MapReduce在高可用、扩展性等方面存在问题。
- HDFS存在的问题(如下图):
- NameNode单点故障,难以应用于在线场景
- NameNode压力过大,且内存受限,影响系统扩展性
- MapReduce存在的问题
- JobTracker访问压力大,影响系统扩展性
- 难以支持除MapReduce之外的计算框架,比如Spark、Storm等.
- Hadoop 2.x由
HDFS
、MapReduce
和YARN
三个分支构
- HDFS:分布式文件存储系统;
- YARN:资源管理调度系统
- MapReduce:运行在YARN上的MR;
2.2. HDFS 2.x
- 解决单点故障
HDFS HA高可用:通过
主备NameNode解决
,如果主NameNode发生故障,则切换到备NameNode上
- 解决内存受限问题
(1) HDFS Federation(联邦机制)
(2)2.x 支持2个NN节点的HA;
3.0实现了NN一主多从,水平扩展,支持多个NameNode;
每个NameNode分管一部分目录;
所有NameNode共享所有DataNode存储资源; - 2.x仅是架构上发生了变化,使用方式不变
- 对HDFS使用者透明
2.3. HDFS 2.x HA高可用
2.3.1. HDFS 2.x的HA
HDFS的高可用结构图:
JournalNode(JN)实现主备NN 间的数据共享
-
主备NameNode
-
解决单点故障(状态 :active为主、standby为备)
主NameNode对外提供服务,备NameNode同步主NameNode元数据,以待切换,所有DataNode同时向两个NameNode汇报数据块信息。主NN将对外提供服务,并将元数据放到JN上,备NN同步备份JN的上存储的元数据。
-
两种切换选择
手动切换:通过命令实现主备之间的切换,可以用HDFS升级等场合
自动切换:基于Zookeeper实现 -
基于Zookeeper自动切换方案
2个NN通过获取zkfc竞争锁,来判定谁是active和standby.
2.3.2.Federation联邦
通过多个
namenode/namespace
把元数据
的存储和管理分散到多个节点中
,使到namenode/namespace可以通过增加机器
来进行水平扩展
。
能把单个
namenode
的负载分散到多个节点
中,在HDFS数据规模较大的时候不会也降低HDFS的性能。可以通过多个namespace
来隔离不同类型的应用,把不同类型应用
的HDFS元数据的存储和管理分派
到不同的namenode
中。
2.4. Zookeepeer
详见:Zookeeeper详解
2.5. YARN
Hadoop 2.0新引入的资源管理任务调度系统
,直接从MRv1演化而来的;
核心思想:将MRv1中JobTracker
的资源管理
和任务调度
两个功能分开,分别由ResourceManager
和ApplicationMaster
进程实现。
ResourceManager
: 负责整个集群的资源管理和调度。
ApplicationMaster
:负责应用程序相关的事务,比如任务调度、任务监控和容错等。
YARN的引入,使得多个计算框架可运行在一个集群中.
每个应用程序对应一个ApplicationMaster(应用程序控制-主人)
目前多个计算框架可以运行在YARN上,比如MapReduce、Spark、Storm
等。
yarn资源管理任务调度流程:
流程大致如下:
- client客户端向yarn集群(ResourceManager)提交任务
- ResourceManager选择一个node创建AppMaster
- AppMaster根据任务向RM申请资源
- RM返回资源申请的结果(返回给AppMaster一批资源)
- AppMaster去对应的node上创建任务需要的资源(container形式,包括内存和CPU)
- AppMaster负责与NodeManager进行沟通,监控任务运行
- 最后任务运行成功,汇总结果。
其中ResourceManager里面一个很重要的东西,就是调度器Scheduler,调度规则可以使用官方提供的,也可以自定义。
官方大概提供了三种模式(了解):
FIFO,最简单的先进先出,按照用户提交任务的顺序执行。这种方式最简单,但是也一大堆问题,比如任务可能独占资源,导致其他任务饿死等。
Capacity,采用队列的概念,任务提交到队列,队列可以设置资源的占比,并且支持层级队列、访问控制、用户限制、预定等等高级的玩法。
Fair share,基于用户或者应用去平分资源,灵活分配。
capacity和fair share都是采用队列的模式,队列内部基本上还是FIFO。并且同级的队列任务,如果一个队列是空闲的,那么另一个队列任务可以使用资源;如果这个队列又提交了任务,则会抢占或者等待资源释放,直到资源到达预定的分配比例。
总的来说,YARN的资源调度还是比较完善的。
2.6.MapReduce On YARN
- MapReduce On YARN:MRv2
- 将MapReduce作业直接运行在YARN上,而不是由JobTracker和TaskTracker构建的MRv1系统中
- 基本功能模块
YARN:负责资源管理和调度
MRAppMaster:负责任务切分、任务调度、任务监控和容错等
MapTask/ReduceTask:任务驱动引擎,与MRv1一致 - 每个MapRduce作业对应一个MRAppMaster任务调度
YARN将资源分配给MRAppMaster
MRAppMaster进一步将资源分配给内部的任务 - MRAppMaster容错
失败后,由YARN重新启动
任务失败后,MRAppMaster重新申请资源
2.7.Hadoop2.X 集群搭建
集群合理安装部署规划(我这里以3太服务器为例)
Zookeeper Failover Controller:监控NameNode健康状态,并向Zookeeper注册NameNode,NameNode挂掉后,ZKFC为NameNode竞争锁,获得ZKFC 锁的NameNode变为active
-
解压
-
配置
hadoop-env.sh
-
配置
core-site.xml
<property> <name>fs.defaultFS</name> <value>hdfs://qiaoke</value> </property> <property> <name>ha.zookeeper.quorum</name> <value>node01:2181,node02:2181,node02:2181</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/opt/hadoop2.6.5</value> </property>
-
配置
hdfs-site.xml
<property> <name>dfs.nameservices</name> <value>qiaoke</value> </property> <property> <name>dfs.ha.namenodes.qiaoke</name> <value>nn1,nn2</value> </property> <property> <name>dfs.namenode.rpc-address.qiaoke.nn1</name> <value>node01:8020</value> </property> <property> <name>dfs.namenode.rpc-address.qiaoke.nn2</name> <value>node02:8020</value> </property> <property> <name>dfs.namenode.http-address.qiaoke.nn1</name> <value>node01:50070</value> </property> <property> <name>dfs.namenode.http-address.qiaoke.nn2</name> <value>node02:50070</value> </property> <property> <!-- 指定namenode元数据存储在journalnode中的路径 --> <name>dfs.namenode.shared.edits.dir</name> </property> <property> <!-- 指定namenode元数据存储在journalnode中的路径 --> <name>dfs.namenode.shared.edits.dir</name> <value>qjournal://node01:8485;node02:8485;node03:8485/qiaoke</value> </property> <property> <!-- 指定HDFS客户端连接active namenode的java类 --> <name>dfs.client.failover.proxy.provider.qiaoke</name> <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value> </property> <property> <!-- 配置隔离机制为ssh 防止脑裂 --> <name>dfs.ha.fencing.methods</name> <value>sshfence</value> </property> <property> <!-- 指定秘钥的位置 --> <name>dfs.ha.fencing.ssh.private-key-files</name> <value>/root/.ssh/id_rsa</value> </property> <property> <!-- 指定journalnode日志文件存储的路径 --> <name>dfs.journalnode.edits.dir</name> <value>/opt/hadoop2.6.5/data</value> </property> <property> <!-- 开启自动故障转移 --> <name>dfs.ha.automatic-failover.enabled</name> <value>true</value> </property>
-
配置
zookeeper
详见:zookeeper详解 配置章节
a) 三台zookeeper:node01,node02,node03
并解压ZooKeeper安装文件
b) 编辑zoo.cfg
配置文件
修改
dataDir=/opt/zookeeper
server.1=node01:2888:3888
server.2=node02:2888:3888
server.3=node03:2888:3888
c) 在dataDir目录中创建一个myid的文件,文件内容分别为1,2,3
d) 环境变量
-
配置hadoop中的
slaves
-
发送到 其他节点服务器 环境变量配置
-
启动三个zookeeper:
./zkServer.sh start
注意:相关的zookeeper服务器都要启动
-
启动三个JournalNode:
./hadoop-daemon.sh start journalnode
-
在
其中一个
namenode上格式化:hdfs namenode -format
-
把刚刚格式化之后的元数据
拷贝
到另外一个
namenode上
a)启动刚刚格式化的namenode :
hadoop-daemon.sh start namenode
b)在没有格式化的
namenode上执行:hdfs namenode -bootstrapStandby
c)启动第二个
namenodehadoop-daemon.sh start namenode
- 在其中一个namenode上初始化zkfc:
hdfs zkfc -formatZK
- 停止上面节点:
stop-dfs.sh
- 全面启动(在NN节点执行):
start-all.sh
- 启动(resourcemanager,我这里是在2,3节点服务器上) :
yarn-daemon.sh start resourcemanager
- 关机:先NN上执行
stop-all.sh
在每个ZooKeeper节点服务器执行zkServer.sh stop
有可能会出错的地方
1,确认每台机器
防火墙均关掉
2,确认每台机器的时间是一致
的
3,确认配置文件无误
,并且确认每台机器上面的配置文件一样
4,如果还有问题想重新格式化
,那么先把所有节点
的进程关掉
,
删除
之前格式化的数据目录
hadoop.tmp.dir属性对应的目录,所有节点
同步都删掉,别单删掉之前的一个,删掉三台JN节点
中dfs.journalnode.edits.dir属性所对应的目录
5,接上面的第6步又可以重新格式化已经启动了
6,最终Active Namenode停掉的时候,StandBy可以自动接管!