基于hadoop_yarn的资源隔离配置基于hadoop_yarn的资源隔离配置

yarn的基本概念
- scheduler
- 集群整体的资源定义
fair scheduler简介
- 配置demo
队列的资源限制
- 基于具体资源限制
- 基于权重资源限制
- 队列运行状态限制
- 基于用户和分组限制
队列的资源抢占
- 抢
- 被抢
队列内部资源调度策略
- FairSharePolicy
- FifoPolicy
- DominantResourceFairnessPolicy
队列的分配规则
- specified　rule
- user rule
- primary rule
- secondaryGroupExistingQueue
- nestedUserQueue
- default 和 reject
通过cdh的一个集群资源划分示例
- 基于组限制hue用户
参考资料

yarn的基本概念

文章图片

【基于hadoop_yarn的资源隔离配置】yarn由两部分组成:

ResourceManager 负责整个集群资源的管理和分配
NodeManager 管理很多容器，容器中运行着正真的分布式计算程序，比如flink，或者spark。NodeManager需要向ResourceManager上报自己的任务运行情况，同时向ResourceManager发起资源申请

从客户端向yarn提交的应用，最终都根据其资源需求，被放在NodeManager的容器中执行。yarn会对每个应用启动一个ApplicationMaster，它负责收集和监控该应用在其它NodeManager容器中执行的分布式任务状态，并和ResourceManager进行资源协调(具体同ResourceManager中的Scheuler)。图中绿色的模块即为一个应用在NodeManager中的分布式运行结构。
ResourceManager由两部分组成：

scheduler 只负责整个集群的磁盘、cpu、网络、内存等资源的管理，并根据应用的需求分配资源
ApplicationManager 注意同应用的ApplicationMaster区分开。ApplicationManager主要负责初始化应用的ApplicationMaster容器，同时监控ApplicationMaster的运行状态，并在其失败后尝试恢复。

总结来看：
yarn提供了一个分布式的资源管理和任务执行管理平台。yarn相当于一个分布式的操作系统，管理资源和任务执行
其中的ResourceManager的ApplicationMananger负责管理应用的ApplicationMaster
ApplicationMaster又负责管理自己具体的所有分布式任务
scheduler hadoop 2.6.0提供了两种scheduler

CapacityScheduler
Fair Scheduler

两者都是基于队列。前者是yahoo开源贡献的，后者是facebook开源贡献的。重点介绍Fair Scheduler ，也是cdh官方推荐的scheduler
最新的yarn版本支持更细粒度的资源管理。加入了ReservationSystem，可以对job的资源做deadline限制，以及可预期的任务做资源保留
集群整体的资源定义 cpu, 内存。配置参数
fair scheduler简介
配置demo

10000 mb,0vcores 90000 mb,0vcores 50 0.1 2.0 fair charlie 5000 mb,0vcores 0.5 3.0 30 5

队列的资源限制

文章图片

队列可以有子队列
所有队列都是root的子队列

基于具体资源限制

10000 mb,0vcores 90000 mb,0vcores 50 0.1 2.0 fair

maxRunningApps是硬性限制，即便集群有空闲资源，也无法超越该限制。
集群扩容后，也不会跟着变化，所以该种限制不推荐

基于权重资源限制

1.0 drf * * 10.0 60.0 30.0

权重是基于比例划分父队列的所有资源
同级子队列的权重相加不需要等于100,　按他们相加的整体算比例
随着集群扩容、缩容动态比例调整

队列运行状态限制

10 0.3

maxRunningApps　队列最大运行应用
队列分配到AM的资源比例

基于用户和分组限制

user1,user2,user3,... group1,group2,... userA,userB,userC,... groupA,groupB,...

aclSubmitApps　限制可以提交到队列的用户
-　aclAdministerApps　限制可以管理该队列的用户，比如杀死任务

队列的资源抢占
抢使用权重时，为了最大化集群资源利用率。在集群空闲时，繁忙的Ａ队列会获得超出自己权重比例的资源，以使其快速执行。
但此时Ｂ队列有一个任务需要执行，Ｂ队列的资源被Ａ队列占用，Ｂ队列只有等待Ａ队列中的任务执行完成释放属于自己的资源
但如果Ａ队列一直有任务执行，Ｂ队列就要一直等下去，为了避免这种情况发生，需要引入抢占机制
在Ｂ队列中配置自己能忍耐的极限，超过则要求fair scheduler帮忙抢资源，杀死Ａ队列中的任务，释放资源
首先在yarn-site.xml中启用抢占功能

yarn.scheduler.fair.preemption true

然后在fair-scheduler.xml　对应的队列中配置

10.0 60 0.5

fairSharePreemptionThreshold (0到１的小数)当队列获得的资源小于 fairSharePreemptionThreshold乘以自己应获得的资源时，
fairSharePreemptionTimeout　并且等待了60s，都还没获取自己要求的这个资源。那fair scheduler将会帮忙杀死Ａ队列中的任务，分配资源给B队列

被抢那如果Ａ队列本身的任务非常重要，不允许执行过程中被杀，那么需要以下配置

10.0 false

allowPreemptionFrom 是否允许调度器从自己这抢走资源，默认为true

队列内部资源调度策略
前面说了队列之间通过权重、或具体大小来划分集群资源。但队列内部对于先后提交的多个任务有以下几种调度方式

fair FairSharePolicy
fifo FifoPolicy
drf DominantResourceFairnessPolicy

FairSharePolicy 基于内存做公平调度。而不不同应用对cpu的的需求
FifoPolicy 先进先出，优先保证先提交到队列的应用所需要的所有资源，有空闲再给后续任务
DominantResourceFairnessPolicy 基于应用申请内存和cpu所在总资源的比例大小来选取占绝对主导权的(dominant)比例
假设总的队列资源是100 CPUs, 10000 GB Memory
A应用程序需求的资源是：2 CPUs, 300 GB Memory，其申请各项的占比为 2% of CPUs vs 3% of Memory
B应用程序需求的资源是：6 CPUs, 100 GB Memory ，其申请的各项占比为　6% of CPUs vs 1% of Memory
所以A占主导的内存申请，%3
B的占主导的应该是cpu申请，%6
B的主导比例是Ａ的两倍，所以Ｂ会获得多余Ａ两倍的资源
对应论文：https://people.eecs.berkeley.edu/~alig/papers/drf.pdf
队列的分配规则

. .

流程方式顺序选择规则，不匹配这下一条

规则的种类有

specified　rule

文章图片

user rule

文章图片

primary rule

文章图片

secondaryGroupExistingQueue

文章图片

nestedUserQueue

文章图片

default 和 reject 兜底，以上所有规则不满足，default为使用默认规则，reject为直接拒绝掉
通过cdh的一个集群资源划分示例

azkaban离线计算,60%,　可抢占，不可被抢占
flink实时计算，10%, 可抢占，不可被抢占
hueuser 即系查询，30%,可抢占，不可被抢占

文章图片

对应xml配置

1.0 drf * * 1.0 drf 10.0 60 0.5 false drf 60.0 60 0.5 false drf 30.0 60 0.5 drf drf

基于组限制hue用户用户组的方式进行队列分配时，yarn的实现是在linux账号体系下去拿该用户对应的组。而默认你在hue中新建的账号在hive的linux机器上没有对应的用户，所以上述配置在分组时，会异常，从而导致用户无法在hue中做hive查询。
所以后面添加新的hue用户的流程是

在hue中新建一个用户假设名为tom
去hiveserver 所在机器上新建同名用户adduser tom
由于linux中新建用户的默认primary group跟用户名同名，这里需要将其修改为hueser 组(该组我已在107上创建)，所以需要接着执行命令usermod -g hueuser tom

参考资料
https://stackoverflow.com/questions/13842241/can-we-use-both-fair-scheduler-and-capacity-scheduler-in-the-same-hadoop-cluster
https://clouderatemp.wpengine.com/blog/2016/06/untangling-apache-hadoop-yarn-part-4-fair-scheduler-queue-basics/