1、yarn产生和发展历史

背景:

数据、程序、运算资源三者组合在一起,才能完成数据的处理,单机不存在问题,但是分布式环境如何协调是一个问题。

Hadoop早期用户使用Hadoop与众多主机上运行的桌面程序类似:

在少了几个节点上建立一个集群、将数据载入HDFS、运行mapreduce

Hadoop演进阶段:

Ad hoc集群以单用户的方式建立,随着私人集群的使用实现了HDFS集群的共享,不同于HDFS,共享mapreduce非常困难。HOD集群解决;额集群条件下多租户的问题yahoo发展部署了Hadoop on Demand平台。在节点分配上实现了多个用户使用mapreduce集群。缺点无法支持数据本地化、资源回收效率低、无法动态扩容能力,多租户共享延迟高,阶段2共享计算集群JobTracker:中央守护进程(压力大、可靠性欠缺、计算模型单一),TaskTracker

阶段3:Yarn集群,拆分mapreduce,剥离出资源管理成为单独框架成为Yarn,mapreduce专注于数据处理,两者解耦。

YARN被设计用以解决以往架构的需求和缺陷的资源管理和调度软件

对Yarn的需求(特性):可扩展性(平滑的扩展至数万个节点)、可维护性(软件和应用程序完全解耦)、多租户(同一集群中多个租户并存,细粒度共享单个节点)、位置感知(将计算移至数据所在位置)、可靠性和可用性(高可用)、对编程模型多样化的支持(支持多样化的编程模型,不仅仅以Mapreduce为中心)、灵活的资源模型(动态分配)、向后兼容。

Apache Hadoop Yarn(Yet Another Resource Negotiator,另一种资源协调者 ):资源管理系统和调度平台。

资源管理系统:集群的硬件资源,和程序运行相关,比如内存、CPU

调度平台:多个程序同时申请资源,如何分配

通用:不仅仅支持Mapreduce,理论上支持各种计算程序。

yarn页面的kill按钮在哪里_hadoop

2、yarn和MRv1区别

Hadoop1中,Mapreduce负责数据计算、资源管理,运行时环境(JobTracker--资源管理和任务管理调度,TaskTracker--单个节点的资源管理和任务执行)、编程模型(Mapreduce)、数据处理引擎(Map Task和Reduce Task)。

Hadoop2中,编程模型和数据处理引擎没有变化,但运行时环境(resourceManager,nodemanager)完全被重写,有Yarn来专管资源管理和任务调度。Yarn将程序内部具体管理职责交给一个叫做ApplicationMaster

3、yarn集群安装部署

标准的主从架构模式,主角色ResourceManager(RM)是Yarn的主角色,决定应用程序之间资源分配的最终权限,RM接受用户作业提交,通过NodeManager(NM)管理本机器上的计算资源,根据RM命令,启动Container容器、监视容器资源使用情况。并向主角色汇报。

通常把NodeManager和DataNode部署咋同一台机器上(有数据的地方就有可能产生计算,移动程序的成本比移动数据的成本低)。

服务器

运行角色

node1

namenode、datanode 、resourcemanager、nodemanager

node2

secondarynamenode、datanode、nodenamager

node3

datanode、nodenamager

hosts配置、防火墙关闭、免密登录、时间同步、配置文件修改等

# 启动yarn、启动MapReduce历史服务:MRJobHistoryServer

start-yarn.sh
mapred --daemon start historyserver

Yarn初体验,示例程序运行

cd /export/server/hadoop-3.1.4/share/hadoop/mapreduce/

计算圆周率测试

yarn jar hadoop-mapreduce-examples-3.1.4.jar  pi 2 2

第一步就是链接resourcemanager

yarn页面的kill按钮在哪里_yarn_02

 web页面查看

yarn页面的kill按钮在哪里_hadoop_03

 还可以进入查看程序运行的日志信息

yarn页面的kill按钮在哪里_大数据_04

yarn HA集群

在Hadoop2.4之前,ResourceManager 是yarn集群中的单点故障(SPOF)

为了解决RM的单点故障问题,yarn设计了Activte/Standy模式的HA

Hadoop官方推荐的方案:基于Zookeeper集群实现

实现HA的关键:主备之间状态数据同步、主备之间顺利切换,

针对数据同步,zk来存储共享集群的状态数据,本质也是一个小的文件系统

针对主备之前切换:手动故障转移和自动故障转移

RM可以选择嵌入基于zk的ActiveStandbyElector来实现自动故障转移

创建锁节点-->注册watcher监听-->准备切换

4、HA YARN搭建(根据黑马教程配置)

安装前需要安装好jdk

##
检测集群时间是否同步
检测防火墙是否关闭
检测主机 ip映射有没有配置

##下载安装包、解压

tar -zxvf zookeeper-3.4.6.tar.gz
mv zookeeper-3.4.6 zookeeper

##修改环境变量(注意:3台zookeeper都需要修改)

vi /etc/profile
export ZOOKEEPER_HOME=/export/server/zookeeper
export PATH=$PATH:$ZOOKEEPER_HOME/bin
source /etc/profile

##修改Zookeeper配置文件

cd zookeeper/conf
cp zoo_sample.cfg zoo.cfg
vi zoo.cfg
添加内容:
dataDir=/export/data/zookeeper/zkdata
## (心跳端口、选举端口)
server.1=node1:2888:3888
server.2=node2:2888:3888
server.3=node3:2888:3888
创建文件夹:
cd export/server/zookeeper
mkdir zkdata
在data文件夹下新建myid文件,myid的文件内容为:
cd zkdata
echo 1 > myid 

##分发安装包到其他机器
scp -r /export/data/zookeeper root@node2:$PWD
scp -r /export/data/zookeeper root@node3:$PWD

##修改其他机器的配置文件
修改myid文件
到mini2上:修改myid为:2
到mini3上:修改myid为:3

##启动(每台机器)
zkServer.sh start
或者编写一个脚本来批量启动所有机器:
for host in node1 node2 node3
do
   ssh $host "source /etc/profile;/export/server/zookeeper/bin/zkServer.sh start"
done

##查看集群状态
jps(查看进程)
zkServer.sh status(查看集群状态,主从信息)

如果启动不成功,可以观察zookeeper.out日志,查看错误信息进行排查

-----------------------------
配置文件中参数说明:

tickTime这个时间是作为zookeeper服务器之间或客户端与服务器之间维持心跳的时间间隔,也就是说每个tickTime时间就会发送一个心跳。

initLimit这个配置项是用来配置zookeeper接受客户端(这里所说的客户端不是用户连接zookeeper服务器的客户端,而是zookeeper服务器集群中连接到leader的follower 服务器)初始化连接时最长能忍受多少个心跳时间间隔数。

当已经超过10个心跳的时间(也就是tickTime)长度后 zookeeper 服务器还没有收到客户端的返回信息,那么表明这个客户端连接失败。总的时间长度就是 10*2000=20秒。

syncLimit这个配置项标识leader与follower之间发送消息,请求和应答时间长度,最长不能超过多少个tickTime的时间长度,总的时间长度就是5*2000=10秒。

dataDir顾名思义就是zookeeper保存数据的目录,默认情况下zookeeper将写数据的日志文件也保存在这个目录里;

clientPort这个端口就是客户端连接Zookeeper服务器的端口,Zookeeper会监听这个端口接受客户端的访问请求;

server.A=B:C:D中的A是一个数字,表示这个是第几号服务器,B是这个服务器的IP地址,C第一个端口用来集群成员的信息交换,表示这个服务器与集群中的leader服务器交换信息的端口,D是在leader挂掉时专门用来进行选举leader所用的端口。

----------------------------------------------------------------

export JAVA_HOME=/root/apps/jdk1.8.0_65
export PATH=$PATH:$JAVA_HOME/bin
export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
 

yarn配置文件修改

<!--删除-->
<property>
    <name>fs.defaultFS</name>
    <value>hdfs://node1.itcast.cn:8020</value>
</property>
<!--添加-->
<!-- 启用RM HA -->
<property>
	<name>yarn.resourcemanager.ha.enabled</name>
	<value>true</value>
</property>
<!-- RM HA集群标识ID -->
<property>
	<name>yarn.resourcemanager.cluster-id</name>
	<value>cluster1</value>
</property>
<!-- RM HA集群中各RM的逻辑标识 -->
<property>
	<name>yarn.resourcemanager.ha.rm-ids</name>
	<value>rm1,rm2</value>
</property>
<!-- rm1运行主机 -->
<property>
	<name>yarn.resourcemanager.hostname.rm1</name>
	<value>node1.btks.cn</value>
</property>
<!-- rm2运行主机 -->
<property>
	<name>yarn.resourcemanager.hostname.rm2</name>
	<value>node2.btks.cn</value>
</property>
<!-- rm1 WebUI地址 -->
<property>
	<name>yarn.resourcemanager.webapp.address.rm1</name>
	<value>node1.btks.cn:8088</value>
</property>
<!-- rm2 WebUI地址 -->
<property>
	<name>yarn.resourcemanager.webapp.address.rm2</name>
	<value>node2.btks.cn:8088</value>
</property>
<!-- 开启自动故障转移 -->
<property>
	<name>yarn.resourcemanager.ha.automatic-failover.enabled</name>
	<value>true</value>
</property>
<!-- zk集群的地址 -->
<property>
	<name>hadoop.zk.address</name>
	<value>node1.btks.cn:2181,node2.btks.cn:2181,node3.btks.cn:2181</value>
</property>
<!-- 开启rm状态恢复重启机制 -->
<property>
	<name>yarn.resourcemanager.recovery.enabled</name>
	<value>true</value>
</property>
<!-- 使用zk集群存储RM状态数据 -->
<property>
	<name>yarn.resourcemanager.store.class</name>
	<value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value>
</property>

将配置拷贝到其他节点

测试故障转移

yarn rmadmin -getAllServiceState

yarn页面的kill按钮在哪里_hadoop_05

访问node1:8088,自动跳转到node2主节点

杀死主节点,自动切换到备份节点

yarn页面的kill按钮在哪里_yarn页面的kill按钮在哪里_06

 手动启动被杀死的节点

yarn --daemon start resourcemanager

查看结果

yarn页面的kill按钮在哪里_大数据_07

5、Yarn架构体系

集群物理层面

ResourceManager:决定系统中所有应用程序之间资源分布的最终权限,级最终仲裁者

主要有两个组件构成,调度器(Scheduler)和应用程序管理器(Application Manager,ASM)

NodeManager每个节点上的资源和任务管理器。

一方面,会定时向RM汇报本届点的使用情况和哥哥Container的运行状态

另一方面,他接收AM的container的启动和关闭

App层面

ApplicationMaster(APP mstr):与RM调度器协商以获取资源(用container表示);将得到的任务进一步分配给内部任务,与NM通讯启动、停止任务,监控任务状态,并在任务运行失败时重新为任务申请资源以重启任务

当前YARN自带了两个AM实现,一个用于显示AM编写方法的示例程序distributedshell,另一个是运行Mapreduce应用程序的AM-MRAppMaster

以上三个共同构成Yarn的3大组件

其他组件

client

container容器(资源的抽象):封装了某个节点上的多维度资源,当下仅支持CPU和内存两种资源,底层使用了轻量级资源隔离机制Cgroups

核心交互流程

yarn页面的kill按钮在哪里_大数据_08

通讯协议,涉及跨机器跨网络通讯,yarn底层使用RPC协议实现通讯

RPC协议组成,JOBClient(作业提交客户端)、Admin(管理员)

yarn页面的kill按钮在哪里_大数据_09

 

yarn交互流程

yarn页面的kill按钮在哪里_大数据_10

应用类型:短应用程序,比如Mapreduce作业、Spark作业

长应用程序:不出意外永不终止

MR交互流程:

第一阶段启动ApplicationMaster

第二个阶段由Application创建应用程序,为他申请资源,并监控整个运行过程

yarn页面的kill按钮在哪里_yarn页面的kill按钮在哪里_11