YARN
最初的思想是把hadoop1中的job tracker的功能拆分出来,
把它的资源管理与任务调度功能分成两个单独的进程.
yarn体系结构中有两个进程,resource manager和nodemanger
.
前者主要负责资源分配,后者nodemanager在每一个机器中都有一个进程,
负责container的创建,监控分配的资源(CPU,内存和磁盘与网络资源),同时
通过心跳汇报这些情况给RM.
applicationmaster是框架特定的作业进程,主要负责与RM申请资源与监控任务
执行的情况.运行在nodemanager上面.
包含两大组件,Scheduler和ApplicationManager.
Scheduler负责创建资源,这些资源基于队列与容量限制.
现在资源以容器的形式包装起来,如多少内存,多少个cpu core被定义成一个容器.
一个作业请求的时候分配多少个容器?
调度器具有可插拔的功能,来负责把集群的资源进行划分.现在主流的调度策略是
基于YARN的容量调度策略与基于FB的公平调度策略.
应用管理器主要负责作业的提交,并且负责协调第一个容器,第一个窗口是作业的
applicationmaster进程需要的,它还负责这个容器启动失败后的重启.appicationmaster
后期会向sheduler来协调作业运行需要的资源.
YARN支持资源保留机制,有时候需要运行特别重要的作业,或者某作业需要的容量比较大,
可会自动启用保留机制,预留一些cpu,内存资源供作业使用.
如何主动在代码中使用这个功能?
RM的重启,
早期的RM HA实现中,只做到了不保留工作的重启,即它只保留了作业的状态与
运行时所需安全证书等信息,然后重启之后,nm会杀死正在运行的container并重新注册到rm上,
相当于重新启动了整个yarn,只是不需要重新提交作业而已.
近两年已经实现了保留工作的RM重启,通过结合从NM,application master来重建容器状态,原来
运行的作业不需要在rm重启后被杀死重新运行,在重启或切换期间它们只是轮询尝试,对用户是透明的.
这些作业运行的元数据信息可能保存在HDFS上,也可以保存在数据库与ZOOKEEPER上,
主流的配置是ZOOKEERP,因为它可以支持RM的HA,主要是支持fencing来保证不脑裂,不让多个rm进程来
改写存储的内容,这是ZK的特定,它的节点可以用于分布式锁类似的功能.
基于文件或leveldb的存储都不支持fencing的功能.
<property> <description>Enable RM to recover state after starting. If true, then yarn.resourcemanager.store.class must be specified</description> <name>yarn.resourcemanager.recovery.enabled</name> <value>true</value> </property> <property> <description>The class to use as the persistent store.</description> <name>yarn.resourcemanager.store.class</name> <value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value> </property> <property> <description>Comma separated list of Host:Port pairs. Each corresponds to a ZooKeeper server (e.g. "127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002") to be used by the RM for storing RM state. This must be supplied when using org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore as the value for yarn.resourcemanager.store.class</description> <name>yarn.resourcemanager.zk-address</name> <value>127.0.0.1:2181</value> </property>
主要翻译自apache hadoop yarn官网