基于hadoop_yarn的资源隔离配置

[TOC]

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

<?xml version="1.0"?>
<allocations>
  <queue name="sample_queue">
    <minResources>10000 mb,0vcores</minResources>
    <maxResources>90000 mb,0vcores</maxResources>
    <maxRunningApps>50</maxRunningApps>
    <maxAMShare>0.1</maxAMShare>
    <weight>2.0</weight>
    <schedulingPolicy>fair</schedulingPolicy>
    <queue name="sample_sub_queue">
      <aclSubmitApps>charlie</aclSubmitApps>
      <minResources>5000 mb,0vcores</minResources>
    </queue>
  </queue>

  <queueMaxAMShareDefault>0.5</queueMaxAMShareDefault>

  <!—- Queue 'secondary_group_queueue' is a parent queue and may have
       user queues under it -->
  <queue name="secondary_group_queue" type="parent">
  <weight>3.0</weight>
  </queue>
  
  <user name="sample_user">
    <maxRunningApps>30</maxRunningApps>
  </user>
  <userMaxAppsDefault>5</userMaxAppsDefault>
  
  <queuePlacementPolicy>
    <rule name="specified" />
    <rule name="primaryGroup" create="false" />
    <rule name="nestedUserQueue">
        <rule name="secondaryGroupExistingQueue" create="false" />
    </rule>
    <rule name="default" queue="sample_queue"/>
  </queuePlacementPolicy>
</allocations>

队列的资源限制

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

基于具体资源限制

<queue name="sample_queue">
   <minResources>10000 mb,0vcores</minResources>
   <maxResources>90000 mb,0vcores</maxResources>
   <maxRunningApps>50</maxRunningApps>
   <maxAMShare>0.1</maxAMShare>
   <weight>2.0</weight>
   <schedulingPolicy>fair</schedulingPolicy>
 </queue>
  • maxRunningApps是硬性限制,即便集群有空闲资源,也无法超越该限制。
  • 集群扩容后,也不会跟着变化,所以该种限制不推荐

基于权重资源限制

    <queue name="root">
       <weight>1.0</weight>
       <schedulingPolicy>drf</schedulingPolicy>
       <aclSubmitApps>*</aclSubmitApps>
       <aclAdministerApps>*</aclAdministerApps>
       <queue name="flink">
           <weight>10.0</weight>
       </queue>
       <queue name="test1">
          <weight>60.0</weight>
      </queue>
       <queue name="test2">
         <weight>30.0</weight>
     </queue>
    </queue>
  • 权重是基于比例划分父队列的所有资源
  • 同级子队列的权重相加不需要等于100, 按他们相加的整体算比例
  • 随着集群扩容、缩容动态比例调整

队列运行状态限制

<maxRunningApps>10</maxRunningApps>
<maxAMShare>0.3</maxAMShare>
  • maxRunningApps 队列最大运行应用
  • 队列分配到AM的资源比例

基于用户和分组限制

<aclSubmitApps>user1,user2,user3,... group1,group2,...</aclSubmitApps>
<aclAdministerApps>userA,userB,userC,... groupA,groupB,...</aclAdministerApps>
  • aclSubmitApps 限制可以提交到队列的用户
    - aclAdministerApps 限制可以管理该队列的用户,比如杀死任务

队列的资源抢占

使用权重时,为了最大化集群资源利用率。在集群空闲时,繁忙的A队列会获得超出自己权重比例的资源,以使其快速执行。

但此时B队列有一个任务需要执行,B队列的资源被A队列占用,B队列只有等待A队列中的任务执行完成释放属于自己的资源

但如果A队列一直有任务执行,B队列就要一直等下去,为了避免这种情况发生,需要引入抢占机制

在B队列中配置自己能忍耐的极限,超过则要求fair scheduler帮忙抢资源,杀死A队列中的任务,释放资源

首先在yarn-site.xml中启用抢占功能

<property>
    <name>yarn.scheduler.fair.preemption</name>
    <value>true</value>
  </property>

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

<queue name="B">
      <weight>10.0</weight>
      <fairSharePreemptionTimeout>60</fairSharePreemptionTimeout>
      <fairSharePreemptionThreshold>0.5</fairSharePreemptionThreshold>
  </queue>
  • fairSharePreemptionThreshold (0到1的小数)当队列获得的资源小于 fairSharePreemptionThreshold乘以自己应获得的资源时,
  • fairSharePreemptionTimeout 并且等待了60s,都还没获取自己要求的这个资源。那fair scheduler将会帮忙杀死A队列中的任务,分配资源给B队列

被抢

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

<queue name="B">
      <weight>10.0</weight>
      <allowPreemptionFrom>false</allowPreemptionFrom>
  </queue>
  • 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的主导比例是A的两倍,所以B会获得多余A两倍的资源

对应论文:https://people.eecs.berkeley.edu/~alig/papers/drf.pdf

队列的分配规则

<queuePlacementPolicy>
  <Rule #1>
  <Rule #2>
  <Rule #3>
  .
  .
 </queuePlacementPolicy>
  • 流程方式顺序选择规则,不匹配这下一条

规则的种类有

<rule name=”specified” create=”false”>

<rule name="user"/>

<rule name="primaryGroup"/>

<rule name="secondaryGroupExistingQueue"/>

<rule name="nestedUserQueue" create=”true”>
<!-- Put one of the other Queue Placement Policies here. -->
</rule>

<rule name="default" queue="default" />

<rule name="reject"/>

specified rule

user rule

primary rule

secondaryGroupExistingQueue

nestedUserQueue

<rule name="nestedUserQueue" >
    <rule name="primaryGroup" create="true" />
</rule>

default 和 reject

兜底,以上所有规则不满足,default为使用默认规则,reject为直接拒绝掉

通过cdh的一个集群资源划分示例

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

对应xml配置

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<allocations>
    <queue name="root">
        <weight>1.0</weight>
        <schedulingPolicy>drf</schedulingPolicy>
        <aclSubmitApps>*</aclSubmitApps>
        <aclAdministerApps>*</aclAdministerApps>
        <queue name="default">
            <weight>1.0</weight>
            <schedulingPolicy>drf</schedulingPolicy>
        </queue>
        <queue name="flink">
            <weight>10.0</weight>
            <fairSharePreemptionTimeout>60</fairSharePreemptionTimeout>
            <fairSharePreemptionThreshold>0.5</fairSharePreemptionThreshold>
            <allowPreemptionFrom>false</allowPreemptionFrom>
            <schedulingPolicy>drf</schedulingPolicy>
        </queue>
        <queue name="azkaban" type="parent">
            <weight>60.0</weight>
            <fairSharePreemptionTimeout>60</fairSharePreemptionTimeout>
            <fairSharePreemptionThreshold>0.5</fairSharePreemptionThreshold>
            <allowPreemptionFrom>false</allowPreemptionFrom>
            <schedulingPolicy>drf</schedulingPolicy>
        </queue>
        <queue name="hueuser" type="parent">
            <weight>30.0</weight>
            <fairSharePreemptionTimeout>60</fairSharePreemptionTimeout>
            <fairSharePreemptionThreshold>0.5</fairSharePreemptionThreshold>
            <schedulingPolicy>drf</schedulingPolicy>
        </queue>
    </queue>
    <defaultQueueSchedulingPolicy>drf</defaultQueueSchedulingPolicy>
    <queuePlacementPolicy>
        <rule name="specified" create="true"/>
        <rule name="nestedUserQueue">
            <rule name="primaryGroup" create="true"/>
        </rule>
        <rule name="default"/>
    </queuePlacementPolicy>
</allocations>

基于组限制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/

欢迎关注我的个人公众号"西北偏北UP",记录代码人生,行业思考,科技评论

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,222评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,455评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,720评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,568评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,696评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,879评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,028评论 3 409
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,773评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,220评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,550评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,697评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,360评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,002评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,782评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,010评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,433评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,587评论 2 350

推荐阅读更多精彩内容