• 基于hadoop_yarn的资源隔离配置


    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/

  • 相关阅读:
    最大似然估计
    信号和槽:Qt中最差劲的创造
    从生物神经网络到人工神经网络
    巩固一下C语言中的指针
    linux启动后自动登录并运行自定义图形界面程序
    删除linux系统服务
    《痞子衡嵌入式半月刊》 索引
    痞子衡嵌入式:恩智浦i.MX RTxxx系列MCU开发那些事
    痞子衡嵌入式:高性能MCU之音视频应用开发那些事
    痞子衡嵌入式:恩智浦i.MX RT1xxx系列MCU开发那些事
  • 原文地址:https://www.cnblogs.com/niceshot/p/15551866.html
Copyright © 2020-2023  润新知