本文深入探讨了YARN的产生背景、架构与运行机制，包括资源管理、容错性和设计目标。同时，详细介绍了HDFS的NameNode高可用（HA）、Federation、Snapshots特性，以及WebHDFS REST API、DistCp工具和ResourceManager的重启与HA机制。
1. Yarn产生背景 2. 初识Yarn 3. Yarn运行机制 4. Hdfs NameNode HA 5. Hdfs NameNode Federation 6. Hdfs Snapshots 7. WebHDFS REST API 8. DistCp 9. ResourceManager Restart 10. ResourceManager HA
-
Yarn产生背景
1.mp存在的问题 1.一个jobtracker带着对各tasktracker，tt多了会对jt造成压力 2.仅支持mp计算 2.资源利用率 各个集群之间管理复杂，有的时候hbase忙，spark闲 3.数据共享 随着数据量的暴增，跨集群数据移动花费时间更长，成本更高。HDFS诞生了，共享数据 -
初识Yarn
1.YARN概述 1.一种新的hadoop资源管理者，是一个通用资源管理系统，可为上层提供统一的资源管理和调度，它的 引入为集群在利用率，资源统一管理和数据共享等方面带来了巨大好处 2.替代了以前的jobtracker，以前的jt任务过重，负责任务调度，跟踪和失败重启等，而且只能运行mp 作业。 2.Yarn架构 1.Yarn由Client，ResourceManager，NodeManger，ApplicationMaster组成。Yarn也是采用 Master/Slave,一个resourceManger和多个NodeManager。 2.Client向ResourceManger提交任务，终止任务 3.ApplicationMaster由对应的应用程序完成，每个应用程序对应一个ApplicationMaster，am向rm 申请资源用于在nm上启动相应的任务。 4.NodeManager向ResourceManager通过心跳信息，汇报NodeManager健康状况，任务执行新安湖给你 狂，领取任务等。 5.MapTask对应的时MapReduce作业启动时产生的Map任务。MPI Task时MPI框架对应的执行任务 3.Yarn核心组件功能 1.ResourceManager：整个集群只有一个，负责集群资源的统一管理和调度。 1.处理来自客户端的请求（启动/终止程序） 2.启动/监控Application Master：一旦某个AM挂了之后，RM将会在另外一个节点上启动AM 3.监控NodeManager，接受NodeManager的心跳汇报信息并分配任务到NodeManager上取执行，一 旦NM挂了之后，标志下该NM的任务，来告诉对应的AM应该如何处理。 4.负责整个集群的资源分配和调度 2.NodeManager：整个集群中有多个，负责当个节点资源管理和使用 1.周期性向RM汇报资源使用情况和各个container的运行状态 2.接受并处理来自RM的container启动/终止的各种命令 3.处理来AM的命令 4.负责单个节点的资源管理和任务调度 3.APPlicationMaseter：每个应用一个，负责应用程序的管理 1.数据切分 2.为应用程序/作业向RM申请资源(container),并分配给内部任务 3.与NM通信启动/停止任务 4.任务监控和容错（在任务执行失败的时候为该任务申请资源以重启任务） 5.处理RM发送过来的命令，终止container，让nm重启等。 4.Container：对任务环境的抽象 1.任务运行资源（节点，内容，CPU） 2.任务启动命令 3.任务运行环境 4.任务是运行在container中，一个container既可以运行AM，也可以运行spark/MP -
Yarn运行机制
1.Yarn工作原理 1.用户向Yarn中提交应用程序/作业，其中包括AM程序，启动AM的命令，用户程序等。 2.RM为作业分配第一个container，并于对应的NM通信，要求NM在这个container中启动该作业的AM 3.AM首先向RM注册，这样用户可以直接通过RM查询作业的运行状态，然后它为各个任务申请资源并监控 任务的运行状态，直到运行结束。 4.AM采用轮询的方式通过RPC请求向RM申请和获取资源。 5.一旦AM申请到资源后，便与对应NM通信，要求他启动任务 6.NM启动任务 7.各个任务通过RPC协议向AM汇报自己的状态和进度，以便AM随时掌握各个任务的运行状态，从而在任务 失败重启。 8.作业完成后，AM向RM注销并关闭自己 2.Yarn容错性 1.RM：基于ZK实现HA(high Available:高可用)避免单节点故障 2.NM：执行失败后，RM将失败任务告诉对应的AM，由AM决定如何处理失败的任务。 3.AM：执行失败后，由RM负责重启；AM需处理内部任务的容错问题，会保存已经运行完成的Task，重启 后无需重新运行 3.Yarn设计目标 通用的统一的资源管理系统 1.同时运行长应用程序（永不停止的程序，Service，HTTPService） 2.短应用程序（秒，分，小时级内运行结束的程序，MRjob，Aparkjob等） 3.打造以Yarn为核心的生态系统 在引入YArn之后，可以在Yarn上运行各种不同框架的作业 1.离线计算框架：MapReduce 2.DAG计算框架：Tez 3.流式计算框架：Storm 4.内存计算框架：Spark -
Hdfs NameNode HA
1.HDFS NameNode 单节点故障概述 在hadoop中的hdfs所处的位置是非常重要的，绝对不允许出现故障。因为整个hdfs文件系统的元数据信息都是由NameNode进行管理。一旦NameNode出现问题就不能工作了，Hive和Hbase多是建立在Hdfs之上的。 2.Hdfs NameNode HA体系架构 1.在典型的HA集群中，两个独立的机器作为NameNode。任何时刻，都只有一个NameNode处于Active，另外一台处于Stendby状态。actice负责所有操作，standby负责维护状态信息以便在需要的时候进行切换。 2.主备切换控制器ZKFailoverController;ZKFC作为独立进程运行，实时监控NameNode健康状况，主NameNode出现问题借助ZK进行切换。 ZKFailoverControlle的主要职责如下： 1.健康检测 2.会话管理 3.master选举 3.共享储存系统Quorum Journal Node,为了让standby Node与active node保持状态同步，他们两个 都要与称为“JournalNodes”的一组独立的进程通信，active node所做的一切都将修改记录发送给 jns，stendbynode从jns中读取edits,并实时监控技能书中数据的修改。stendby获取edits后， 将其应用到自己的命名空间，以备替换之需。 4.DataNode节点，除了通过共享储存系统共享HDFS的元数据信息之外，主NameNode和备份NameNode还 需要共享HDFS的数据块和DataNode之间的映射关系。datanode会同时向namenode和备份namenode 上报数据块的位置信息。 3.HDFS NameNode的主备切换实现原理 Namenode主备切换主要由ZKFailover-Controller,HealthMonitor和ActiveStandbyElector这三 个组件协同实现。 主备切换流程如下： 1.healthMonitor初始化完成之后会启动线程定时调用对应的nameNode的HAServiceProtocol RPC接 口的方法，对NameNode的健康状态进行检测。 2.如果检测到健康状态发生变化，会回调ZKFC注册的相应方法进行处理 3.如果ZKFC判断需要进行主备切换，会首先使用ActiceStandbyEletor来进行主备切换 4.ActiceStandbyEletor与ZK进行狡猾完成自动的主备选举 5.主备选举完成后，ActiceStandbyEletor会回调ZKFC的相应方法来同值当前的namenode称成为主或 者备。 6.ZKFC调用对应namenode的HAServiceProtocolRPC接口的方法将namenode转化为active或者 standby。 4.HDFS NameNode HA 环境搭建 1.Zookeeper下载/配置环境 2.修改配置文件 1.zoo_sample.cfg修改为zoo.cfg,然后进行编辑 ztickTime=2000 initLimit= 10 syncLimit=S dataDir=/home/hadoop/yarn/zookeeper-3.4.5-cdh5.5.0/zkdata dataLogDir=/home/hadoop/yarn/zookeeper-3.4.5-cdh5.5.0/zkdatalog clientPort=2l8l server.I=hadoopOOI:2888:3888 server.2=hadoop002:2888:3888 2.在zkdata文件夹中创建myid 填入1，1是zoo.cfgservice.1中的1 3.hadoop配置文件 core-site.xml hdfs-site.xml workers 编辑 -
Hdfs NameNode Federation
1.Federation产生背景 hdfs所有操作都会和namenode进行交互，当集群过大时，namenode会成为集群的瓶颈。Federation可 以解决如下场景问题。 1.hdfs集群扩展性，多个namenode分关一部分目录，使得一个集群可以扩展到更多的节点 2.性能更高效，多个namenode管理不同的数据，且同对外提供服务，将为用户提供更高的读写吞吐量 3.良好的隔离性，用户可更具需要将不同业务数据交互不同namenode管理，这样不同业务之间的影响很 小。 2.Hdfs数据管理架构 一个namenode下存在一个namespace，一个namespace对应一个blackpool。随着blockpool的增加， namenode下namespace组件增加，一味着增加jvm大小不行，HDFS Federation出现了。 3.Federation架构 1.namenode内存过高，可以完全将大的文件目录移到另外一个namenode上做管理，这些namenode是共 享集群中所有的datanode。 2.HDFSFederation时解决namenode单点问题的水平横向扩展方案。使得到多个独立的namenode和命名 空间 3.HDFSFederation中namenode相互独立管理自己的命名空间一个datanode下可能有多个 blockpool，。在Federation下，只有元数据的管理与存放是相互独立的，数据是共享的 -
Hdfs Snapshots
1.概述 hdfs快照是文件系统在某一时刻只读的镜像，可以是一个完整的文件系统也可以是某个目录的镜像 2.快照常用场景 1.防止用户的错误操作；管理员可以通过滚动的方式周期性设置一个只读的快照。 2.备份/恢复 3.测试/实验 4.灾难恢复 3.快照常用操作 1.allow Snapshots 1.确定目录是否可以进行快照 2.利用hdfs dfsadmin -allow snapshots <dirpath>开启快照功能，那么该目录就会成为一个 snapshotstable的目录，一个目录下最多储存快照为65535,但是快照目录数量没有限制。 2.Create SnapShots 只有目录运行进行快照，才能在该目录下创建快照 hdfs dfs -createSnapshots <path>[<snapshotName>] hdfs dfs -ls /.snapshots #快照显示 3.Rename Snapshots 重命名Snapshots hdfs dfs-renameSnapshots <path><oldname><newname> 4.Get Snapshotstable directory listing 通过hdfs ls snapshotstabledir来列出snapshotstable的目录 5.Get Snapshots Difference Report 比较两个快照之间的差异 hdfs snapshotDiff <path> <fromSnapshot><toSnapshot> 6.DeleteSnapshots 删除快照 hdfs dfs -deleteSnapshots <path><snapshotName> 7.disallowSnapshots 关闭快照 hdfs disallowsnapshot <path> 4.运用场景 1.通过snapshot可以按照定时任务，或按固定时间间隔的干事创建文件快照，并删除过期的文件快照，减少业务误操作所造成的数据存世，快照的操作远低于外部备份开销，可作为备份HDFS系统最常用的方式。 -
WebHDFS REST API
1.概述 提供HDFS文件系统的HTTP REST API支持 2.配置 hdfs-site.xml dfs.werhdfs.enabled/true 3.测试 1.HDFS访问方式 hdfs://<HOST><RPC_PORT>/<PATH> hdfs fs -ls hdfs://hadoop0180020/user 2.WebHdfsd访问方式 webHDFS://<HOST><HTTP_PORT>/<PATH> 3.REST访问方式 http://<HOST><HTTP_PORT>/webhdfs/v1/<PATH>?= -
DistCp
1.概述 DistCp是用于集群内部或者集群之间的一个拷贝工具，底层使用MapReduce作业完成，所以只用要启动 Yarn。 2.DistCp使用 1.相同版本Hadoop集群中的相互拷贝 将nn1集群中的bar文件拷贝到nn2中.后面可以继续跟 hadoop distcp hdfs://nn1:8020/foo/bar hdfs://nn2:8020/bar/foo 2.不同版本hadoop集群之间进行拷贝 hadoop distcp -i hftp://nn1:8020/a hftp://kk1:8020/a -
ResourceManager Restart
1.概述 在yarn中RM的地位是非常重要的，当RM单点出现故障的时候，尽可能RM重启，此进程用户是不感知的。 RM重启可以划分成两个阶段完成： 1.RM将应用程序的状态以及其他验证信息保存到一个可插拔的状态储存中；RM重启时将状态储存中重新加 载这些信 息， 然后重新开始之前正在运行的应用程序。 2.重启时通过从RM读取容器的状态和从AM读取容器的请求，集中重构RM的运行状态，第二阶段中正在运 行的程序不会因为RM重启而被杀死。 2.配置 yarn-site.xml -
ResourceManager HA
1.概述 RM的职责是负责整个集群资源的管理以及应用的调度；在hadoop2.4之前，RM是单节点故障的，出问题就 完蛋。 2.RM HA架构 构建类类似ZK下 HDFSNameNode HA的架构 actice/standby RM 3.RM HA切换 active Rh会将状态信息写入到ZK集群中，如果active RM挂了，那么可以将standby RM切换成active RM。 RM状态切换方法： 1.手动切换 1.查看当前状态 yarn rmadmin -getServiceState rm1 2.手工切换RM yarn rmadmin -transitionToStandby rm1 2.自动切换 通过内嵌的基于ZK的ActiveStandbyElector来决定哪个RM时Active yarn-site.xml 配置 # 启用RM重启的功能，默认时fslse 、#yam.resourcemanager.recovery. enabled # 用于状态储存的类 #yarn.reso cemanager.store.class # 被RM用于状态储存的ZK服务器的主机：端口号 #yam.resourcemanager.zk-address # 开启RM高可用 #yarn.resourcemanager.ha.enabled # 指定RM的cluster id # yarn.resourcemanager.cluster-id # 指定RM的名字 #yarn.resomcemanager.ha.rm-ids # 分别指定RM的地址 #yarn.resourcemanager.hostname.rml # 指定ZK集群地址 #yarn.resourcemanager.zk-address # 指定rm框架v为yarn方式 #apreduce..amework.name
扫一扫
392
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
