YARN/MRv2 Resource Manager深刻剖析—资源调度器

在YARN中，资源调度器（ResourceScheduler）是一个很是核心的部件，它负责将各个节点上的资源封装成container，并按照必定的约束条件（按队列分配，每一个队列有必定的资源分配上限等）分配给各个application。

（注意：本文分析基于hadoop-2.0.3-alpha）

YARN的资源管理器其实是一个事件处理器，它须要处理来自外部的6种SchedulerEvent类型的事件，并根据事件的具体含义进行相应的处理。这6种事件含义以下：

（1）  NODE_REMOVED

事件NODE_REMOVED表示集群中被移除一个计算节点（多是节点故障或者管理员主动移除），资源调度器收到该事件时须要从可分配资源总量中移除相应的资源量。

（2） NODE_ADDED

事件NODE_ADDED表示集群中增长了一个计算节点，资源调度器收到该事件时须要将新增的资源量添加到可分配资源总量中。

（3）APPLICATION_ADDED

事件APPLICATION_ADDED 表示ResourceManager收到一个新的Application。一般而言，资源管理器须要为每一个application维护一个独立的数据结构，以便于统一管理和资源分配。资源管理器需将该Application添加到相应的数据结构中。

（4）APPLICATION_REMOVED

事件APPLICATION_REMOVED表示一个Application运行结束（可能成功或者失败），资源管理器需将该Application从相应的数据结构中清除。

（5） CONTAINER_EXPIRED

当资源调度器将一个container分配给某个ApplicationMaster后，若是该ApplicationMaster在必定时间间隔内没有使用该container，则资源调度器会对该container进行再分配。

（6）NODE_UPDATE

NodeManager经过心跳机制向ResourceManager汇报各个container运行状况，会触发一个NODE_UDDATE事件，因为此时可能有新的container获得释放，所以该事件会触发资源分配，也就是说，该事件是6个事件中最重要的事件，它会触发资源调度器最核心的资源分配机制。

资源表示模型

当前YARN支持内存和CPU两种资源类型的管理和分配。当NodeManager启动时，会向ResourceManager注册，而注册信息中会包含该节点可分配的CPU和内存总量，这两个值都可经过配置选项设置，具体以下：

（1）yarn.nodemanager.resource.memory-mb

可分配的物理内存总量，默认是8*1024MB。

（2）yarn.nodemanager.vmem-pmem-ratio

每单位的物理内存总量对应的虚拟内存量，默认是2.1，表示每使用1MB的物理内存，最多可使用2.1MB的虚拟内存总量。

（3）yarn.nodemanager.resource.cpu-core（默认是8）

可分配的CPU总个数，默认是8

（4）yarn.nodemanager.vcores-pcores-ratio

为了更细粒度的划分CPU资源，YARN将每一个物理CPU划分红若干个虚拟CPU，默认值为2。用户提交应用程序时，能够指定每一个任务须要的虚拟CPU个数。在MRAppMaster中，每一个Map Task和Reduce Task默认状况下须要的虚拟CPU个数为1，用户可分别经过mapreduce.map.cpu.vcores和mapreduce.reduce.cpu.vcores进行修改（对于内存资源，Map Task和Reduce Task默认状况下须要1024MB，用户可分别经过mapreduce.map.memory.mb和mapreduce.reduce.memory.mb修改）。

（在最新版本2.1.0-beta中，yarn.nodemanager.resource.cpu-core和yarn.nodemanager.vcores-pcores-ratio两个参数被遗弃，引入一个新参数yarn.nodemanager.resource.cpu-vcore，表示虚拟CPU个数，具体请阅读YARN-782）

YARN对内存资源和CPU资源采用了不一样的资源隔离方案。对于内存资源，为了可以更灵活的控制内存使用量，YARN采用了进程监控的方案控制内存使用，即每一个NodeManager会启动一个额外监控线程监控每一个container内存资源使用量，一旦发现它超过约定的资源量，则会将其杀死。采用这种机制的另外一个缘由是Java中建立子进程采用了fork()+exec()的方案，子进程启动瞬间，它使用的内存量与父进程一致，从外面看来，一个进程使用内存量可能瞬间翻倍，而后又降下来，采用线程监控的方法可防止这种状况下致使swap操做。对于CPU资源，则采用了Cgroups进行资源隔离。具体可参考YARN-3。

资源分配模型

在YARN中，用户以队列的形式组织，每一个用户可属于一个或多个队列，且只能向这些队列中提交application。每一个队列被划分了必定比例的资源。

YARN的资源分配过程是异步的，也就是说，资源调度器将资源分配给一个application后，不会马上push给对应的ApplicaitonMaster，而是暂时放到一个缓冲区中，等待ApplicationMaster经过周期性的RPC函数主动来取，也就是说，采用了pull-based模型，而不是push-based模型，这个与MRv1是一致的。

总结

相比于MRv1中的资源调度器，尽管YANR的调度器也是插拔式的，但因为YARN采用了事件驱动的模型，所以编写起来更加复杂，难度也远远大于MRv1。

同MRv1同样，YARN也自带了三种经常使用的调度器，分别是FIFO，Capacity Scheduler和Fair Scheduler，其中，第一个是默认的调度器，它属于批处理调度器，然后两个属于多租户调度器，它采用树形多队列的形式组织资源，更适合公司应用场景。须要注意的是，这三种调度器采用的算法与MRv1中的彻底一致，只不过是根据YARN中资源调度器的对外接口从新实现了一遍，在此再也不赘述。

原创文章，转载请注明： 转载自董的博客

本文连接地址: http://dongxicheng.org/mapreduce-nextgen/yarnmrv2-resource-manager-resource-manager/