EMR集群上capacity scheduler的ACL实现

简介: 本文接着yarn capacity scheduler的实现原理,介绍了capacity scheduler的设置和其中需要注意的问题,并结合EMR集群做了实际操作实验。

背景

前面一篇介绍了yarn的capacity scheduler原理,实验了在EMR集群上使用capacity scheduler对集群资源的隔离和quota的限制。本文会介绍EMR集群上capacity scheduler的ACL实现。

为什么要做这个?前面给集群分配的资源分配了多个队列,以及每个队列的资源配比和作业调度的优先级。如果多租户里面的每个都按照约定,各自往自己对应的队列里面提交作业,自然没有问题。但是如果用户熟悉capacity scheduler的操作和原理,也是可以占用别组的资源队列。所有有了capacity scheduler的ACL设置。

关键参数

  • yarn.scheduler.capacity.queue-mappings

    • 指定用户和queue的映射关系。默认用户上来,不用指定queue参数就能直接到对应的queue。这个比较方便,参数的格式为:[u|g]:[name]:[queue_name][,next mapping]*
  • yarn.scheduler.capacity.root.{queue-path}.acl_administer_queue

    • 指定谁能管理这个队列里面的job,英文解释为The ACL of who can administer jobs on the default queue. 星号*表示all,一个空格表示none;
  • yarn.scheduler.capacity.root.{queue-path}.acl_submit_applications

    • 指定谁能提交job到这个队列,英文解释是The ACL of who can administer jobs on the queue.星号*表示all,一个空格表示none;

EMR集群上具体操作步骤

  • 创建EMR集群
  • 修改相关配置来支持queue acl

    • yarn-site: yarn.acl.enable=true
    • mapred-site: mapreduce.cluster.acls.enabled=true
    • hdfs-site: dfs.permissions.enabled=true这个跟capacity scheduler queue的acl没什么关系,是控制hdfs acl的,这里一并设置了
    • hdfs-site: mapreduce.job.acl-view-job=* 如果配置了dfs.permissions.enabled=true,就需要配置一下这个,要不然在hadoop ui上面没发查看job信息
  • 重启yarn和hdfs,使配置生效(root账户)

    • su -l hdfs -c '/usr/lib/hadoop-current/sbin/stop-dfs.sh'
    • su -l hadoop -c '/usr/lib/hadoop-current/sbin/stop-yarn.sh'
    • su -l hdfs -c '/usr/lib/hadoop-current/sbin/start-dfs.sh'
    • su -l hadoop -c '/usr/lib/hadoop-current/sbin/start-yarn.sh'
    • su -l hadoop -c '/usr/lib/hadoop-current/sbin/yarn-daemon.sh start proxyserver'
  • 修改capacity scheduler配置
    完整配置
<configuration>
  <property>
    <name>yarn.scheduler.capacity.maximum-applications</name>
    <value>10000</value>
    <description>
      Maximum number of applications that can be pending and running.
    </description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.maximum-am-resource-percent</name>
    <value>0.25</value>
    <description>
      Maximum percent of resources in the cluster which can be used to run
      application masters i.e. controls number of concurrent running
      applications.
    </description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.resource-calculator</name>
    <value>org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator</value>
    <description>
      The ResourceCalculator implementation to be used to compare
      Resources in the scheduler.
      The default i.e. DefaultResourceCalculator only uses Memory while
      DominantResourceCalculator uses dominant-resource to compare
      multi-dimensional resources such as Memory, CPU etc.
    </description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.queues</name>
    <value>a,b,default</value>
    <description>
      The queues at the this level (root is the root queue).
    </description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.default.capacity</name>
    <value>20</value>
    <description>Default queue target capacity.</description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.a.capacity</name>
    <value>30</value>
    <description>Default queue target capacity.</description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.b.capacity</name>
    <value>50</value>
    <description>Default queue target capacity.</description>
  </property>


  <property>
    <name>yarn.scheduler.capacity.root.default.user-limit-factor</name>
    <value>1</value>
    <description>
      Default queue user limit a percentage from 0.0 to 1.0.
    </description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.default.maximum-capacity</name>
    <value>100</value>
    <description>
      The maximum capacity of the default queue.
    </description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.default.state</name>
    <value>RUNNING</value>
    <description>
      The state of the default queue. State can be one of RUNNING or STOPPED.
    </description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.a.state</name>
    <value>RUNNING</value>
    <description>
      The state of the default queue. State can be one of RUNNING or STOPPED.
    </description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.b.state</name>
    <value>RUNNING</value>
    <description>
      The state of the default queue. State can be one of RUNNING or STOPPED.
    </description>
  </property>


  <property>
    <name>yarn.scheduler.capacity.root.acl_submit_applications</name>
     <value> </value>
     <description>
       The ACL of who can submit jobs to the root queue.
     </description>
   </property>

  <property>
    <name>yarn.scheduler.capacity.root.a.acl_submit_applications</name>
    <value>root</value>
    <description>
      The ACL of who can submit jobs to the default queue.
    </description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.b.acl_submit_applications</name>
    <value>hadoop</value>
    <description>
      The ACL of who can submit jobs to the default queue.
    </description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.default.acl_submit_applications</name>
    <value>root</value>
    <description>
      The ACL of who can submit jobs to the default queue.
    </description>
  </property>

<property>
    <name>yarn.scheduler.capacity.root.acl_administer_queue</name>
    <value> </value>
    <description>
      The ACL of who can administer jobs on the default queue.
    </description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.default.acl_administer_queue</name>
    <value>root</value>
    <description>
      The ACL of who can administer jobs on the default queue.
    </description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.a.acl_administer_queue</name>
    <value>root</value>
    <description>
      The ACL of who can administer jobs on the default queue.
    </description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.b.acl_administer_queue</name>
    <value>root</value>
    <description>
      The ACL of who can administer jobs on the default queue.
    </description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.node-locality-delay</name>
    <value>40</value>
    <description>
      Number of missed scheduling opportunities after which the CapacityScheduler
      attempts to schedule rack-local containers.
      Typically this should be set to number of nodes in the cluster, By default is setting
      approximately number of nodes in one rack which is 40.
    </description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value>u:hadoop:b,u:root:a</value>
  </property>

  <property>
    <name>yarn.scheduler.capacity.queue-mappings-override.enable</name>
    <value>false</value>
    <description>
      If a queue mapping is present, will it override the value specified
      by the user? This can be used by administrators to place jobs in queues
      that are different than the one specified by the user.
      The default is false.
    </description>
  </property>

</configuration>

上面的配置,分配了三个队列和对应的资源配比,设置用户hadoop默认(不指定队列的时候)往b队列提,root默认往a队列提。同时hadoop只能往b队列提交作业,root可以往所有队列提交作业。其它用户没有权限提交作业。

踩过的坑

  • acl_administer_queue的配置

    • 配置中支持两种操作的acl权限配置acl_administer_queueacl_submit_applications。按照语意,如果要控制是否能提交作业,只要配置队列的acl_submit_applications属性即可,按照文档,也就是这个意思。但是其实不是的,只要有administer权限的,就能提交作业。这个问题查了好久,找源码才找到。
  @Override
  public void submitApplication(ApplicationId applicationId, String userName,
      String queue)  throws AccessControlException {
    // Careful! Locking order is important!

    // Check queue ACLs
    UserGroupInformation userUgi = UserGroupInformation.createRemoteUser(userName);
    if (!hasAccess(QueueACL.SUBMIT_APPLICATIONS, userUgi)
        && !hasAccess(QueueACL.ADMINISTER_QUEUE, userUgi)) {
      throw new AccessControlException("User " + userName + " cannot submit" +
          " applications to queue " + getQueuePath());
    }
  • root queue的配置

    • 如果要限制用户对queue的权限root queue一定要设置,不能只设置leaf queue。因为权限是根权限具有更高的优先级,看代码注释说:// recursively look up the queue to see if parent queue has the permission。这个跟常人理解也不一样。所以需要先把把的权限限制住,要不然配置的各种自队列的权限根本没有用。
<property>
    <name>yarn.scheduler.capacity.root.acl_submit_applications</name>
     <value> </value>
     <description>
       The ACL of who can submit jobs to the root queue.
     </description>
   </property>
目录
相关文章
|
存储 消息中间件 分布式计算
|
8月前
|
存储 数据采集 运维
自建埋点分析系统的成本对比(含 ClkLog 开源方案)
本文对比自建埋点系统与基于开源ClkLog方案的成本与落地效率:完全自建需几十万、周期长、风险高;而ClkLog可一周快速部署,首期投入仅几万元,覆盖采集、接入、存储、分析及可视化全链路,兼顾数据自主性与实施可控性。
|
8月前
|
人工智能 监控 API
分布式智能崛起后,我们终于知道 AI调度官 负责什么了
2026年,AI从云端巨兽蜕变为亿级边缘智能体,“AI调度官”应运而生——不再写提示词,而是设计交互协议、调控算力资源、熔断群体风险、注入人类价值观。他们是分布式智能时代的“立法者”与“守夜人”,掌控人机共生新秩序。(239字)
408 6
|
SQL 关系型数据库 Apache
从 Flink 到 Doris 的实时数据写入实践 —— 基于 Flink CDC 构建更实时高效的数据集成链路
本文将深入解析 Flink-Doris-Connector 三大典型场景中的设计与实现,并结合 Flink CDC 详细介绍了整库同步的解决方案,助力构建更加高效、稳定的实时数据处理体系。
4115 0
从 Flink 到 Doris 的实时数据写入实践 —— 基于 Flink CDC 构建更实时高效的数据集成链路
|
编解码 搜索推荐
视频播放器-支持 MP4/AVI/FLV 万能格式视频播放器,Player视频播放器,附下载地址,多功能超清格式视频播放器
PotPlayer是一款功能强大的多媒体播放器,支持4K、HDR及蓝光原盘播放,拥有硬件加速与madvr视频渲染功能。界面简洁、操作简单,内置丰富编码器,启动迅速且播放稳定。它可自定义皮肤与配色,支持实时字幕翻译,并提供滤镜功能以增强画质。通过添加外部滤镜如madVR和LAVFilters,用户能进一步优化体验,但需权衡性能消耗。适合高清影片爱好者使用。
1539 1
|
消息中间件 数据采集 移动开发
数仓建模—埋点设计与管理
开始之前我们先看一下我们为什么要收集埋点数据,埋点都可以做什么,埋点主要用于记录用户行为,几乎是应用必不可少的功能.埋点的作用包括但不限于
1744 0
数仓建模—埋点设计与管理
|
开发者 Python
Python教程:你一定要知道的26个Python魔术方法(快记下来)
Python中的魔术方法是指以双下划线 __ 开头和结尾的特殊方法,也被称为特殊方法或魔术方法。这些方法在类中具有特殊的用途,它们可以让你自定义类的行为,使得你的对象可以像内置类型一样工作。
884 3
|
SQL 关系型数据库 MySQL
|
机器学习/深度学习 人工智能 算法
算法金 | 一文彻底理解机器学习 ROC-AUC 指标
```markdown # ROC曲线与AUC详解:评估分类模型利器 本文深入浅出解释ROC曲线和AUC,通过实例和代码帮助理解其在模型评估中的重要性,旨在提升对分类模型性能的理解和应用。 ```
3226 13
算法金 | 一文彻底理解机器学习 ROC-AUC 指标