腾讯云 EMR 基于 YARN 针对云原生容器化的优化与实践
作者:互联网
导语 | 传统 HADOOP 生态系统使用 YARN 管理/调度计算资源,该系统⼀般具有明显的资源使⽤周期。实时计算集群资源消耗主要在⽩天,而数据报表型业务则安排在离线计算集群中。离在线业务分开部署的首要问题就是资源使用率低,消耗成本⾼。随着业务的增⻓和突发的报表计算需求,为了解决为离线集群预留资源,腾讯云 EMR 团队和容器团队联合推出 Hadoop Yarn on Kubernetes Pod,以提⾼容器资源使用率,降低资源成本,将闲时容器集群 CPU 使⽤率提升数倍之多。本文主要介绍 HADOOP 资源调度器 YARN 在容器环境中的优化与实践。
一、Hadoop Yarn on Kubernetes Pod 混合部署模式
Hadoop Yarn on Kubernetes Pod 方案提供弹性扩缩容和离在线混合部署两项功能。弹性扩缩容主要聚焦于如何利⽤云原生资源,快速扩容资源以补充算力。离在线混合部署模式的目的是为了充分使用在线集群的空闲资源,尽可能减少为离线集群预留空闲资源的频次。
EMR 弹性扩缩容模块(yarn-autoscaler)提供按负载和按时间弹性伸缩两种扩缩容方式。对于按负载伸缩,用户可以对不同指标设置阈值来触发扩缩容,比如设置 Yarn 队列中 availablevcore、 pending vcore、available mem、pending mem。亦可以使用时间扩缩规则,按天、按周、按月等规则指定触发。
当弹性规则被触发后,离在线部署模块获取当前在线 TKE 集群中可以提供的闲置算力的规格及数量,调用 Kubernetes api 创建对应数量的资源,ex-scheduler 扩展调度器确保 Pod 被创建在剩余资源更多的节点上,该 POD 负责启动 YARN 的服务。
通过该方案,Yarn 的 NodeManager 服务可以快速部署到 POD 节点中。但也 Yarn 原生调度没有考虑异构资源,由此引发了两个问题:
1. AM 的 POD 被驱逐,导致 APP 失败
在 node 节点的资源紧缺的条件下,kubelet 为了保证 node 节点的稳定性,会触发主动驱逐 pod 的机制。如果该节点存在 AM 服务,则整个 Application 就要被视为失败,ResourceManager 此时会重新分配 AM。对于计算量很大的任务,Application 重跑的代价不可承受。
2. Yarn 原生非独占分区资源共享局限性
Yarn 的标签分区特性⽀持独占分区(Exclusive),非独占分区(Non-exclusive)。
-
独占分区(Exclusive):例如指定独占分区 x,Yarn 的 container 只会分配到该 x 分区。
-
非独占分区(Non-exclusive):例如非独占分区 x,x 分区的资源可以共享给 default 分区。只有当指定分区 default 时,default 上运⾏的 Application 可以使⽤分区 x 的资源。
但是在实际使⽤场景中,⽤户要给各个业务部门分配各自的独占分区资源,同时会划分出供各部门使用的 default 分区。default 分区资源会比较充足,业务部门希望能够使用自己的独占分区和同时充分利用 default 分区资源,独占分区资源和 default 分区都不够用的时候,才会触发弹性扩容,往属于自己的独占分区中扩容资源。
二、对 Yarn 改造带来的挑战
对上述 feature 的开发,除了需求技术本⾝的难度。还需要考虑到尽可能降低用户存量集群稳定性的影响,减少用户业务侧改造成本。
-
集群稳定性:Hadoop Yarn 作为大数据系统中的基础调度组件,如果改动过多,引发的故障几率就会增大。同时引入的 feature,必然需要升级存量集群的 Haoop Yarn。升级操作要做到对存量业务集群无感知,不能影响到当天的业务。
-
业务侧使用成本:引入的新 feature 也必须符合原⽣yarn 的使用习惯,方便业务侧用户理解,同时降低业务侧对代码的改造。
1. AM 自主选择存储介质
目前 Yarn 的社区没有考虑云上异构资源混合部署的特点。在线 TKE 集群中,当资源紧张时会对容器进行驱逐。为了避免 Appliction 重新计算,浪费资源的现象,必须提供 AM 可以指定能否分配到 POD 类型资源。
自主选择存储介质中,使用配置化标识,由 NodeManager 通过 RPC 上报能否将资源提供给 AM 使用,ResourceManager 通过上报信息决定将 Application 的 AM 分配到稳定资源介质中。由 NodeManager 通过配置化上报信息的好处是显而易见的:
-
去集中化:减少 ResourceManager 处理逻辑。否则,扩容资源时,还需将资源信息通过 RPC/配置流入到 ResourceManager 中。如无必要,勿增实体,对 ResourceManager 的改造应该轻量化。
-
集群稳定性:存量业务集群对 Yarn 升级后,需要重启 NodeManager, 只需要重启 ResourceManager。Yare 的高可用特性可保证升级过程对业务无影响。无需重启 NodeManager 的原因是,NM 默认将本机资源视为可分配。
-
简单易用:用户可以通过配置⾃由决定任务资源拥有分配 AM 的权利,不单单局限 POD 容器资源。
2. 多标签动态分配资源
Yarn 的原生标签设计中,提交任务时的标签表达式中只能含有单个标签。如果为了提⾼利用率,同时使用多个分区资源,就必须将非 default 分区设置为 Non-exclusive 特性。标签表达式必须解决如下三个问题:
-
资源隔离:分区 A 设置 Non-exclusive 后,资源被其他分区上的 APP 占用后,无法及时交换给分区 A 的 App。
-
自由共享资源:只有 default 分区才有资格申请 Non-exclusive 分区资源。
-
动态选择分区资源:多分区资源共享时,无法根据分区剩余资源大小选择可用区,影响任务执行效率。
腾讯云 EMR 团队通过支持扩展表达式语法,增加对逻辑运算符表达式的支持,使 App 可以申请多个分区资源。同时开发资源统计模块动态统计分区可用资源,为 App 分配最合适的分区。
三、实操演练
测试环境:指定 172.17.48.28/172.17.48.17 的 NodeManager 为 default 分区,172.17.48.29/172.17.48.26 的 NodeManager 为 x 分区。
队列设置:
复制代码<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet type="text/xsl" href="configuration.xsl"?><configuration><property><name>yarn.scheduler.capacity.root.queues</name><value>a,b</value></property>
<property><name>yarn.scheduler.capacity.root.accessible-node-labels.x.capacity</nam e><value>100</value></property>
<property><name>yarn.scheduler.capacity.root.accessible-node-labels.y.capacity</nam e><value>100</value></property>
<!-- configuration of queue-a --><property><name>yarn.scheduler.capacity.root.a.accessible-node-labels</name><value>x</value></property>
<property><name>yarn.scheduler.capacity.root.a.capacity</name><value>50</value></property>
<property><name>yarn.scheduler.capacity.root.a.accessible-node-labels.x.capacity</n ame><value>100</value></property>
<!-- configuration of queue-b --><property><name>yarn.scheduler.capacity.root.b.accessible-node-labels</name><value>y</value></property>
<property><name>yarn.scheduler.capacity.root.b.capacity</name><value>50</value></property>
<property><name>yarn.scheduler.capacity.root.b.accessible-node-labels.y.capacity</n ame><value>100</value></property>
</configuration>
1. 规定 AM 只能分配在 172.17.48.28
对另外三个节点的 NodeManager 节点配置如下配置项:
yarn.nodemanager.am-alloc-disabled = true
复制代码
配置后,提交的 Application 的 AM 只能在 172.17.48.28 节点启动。
2. 使用组合标签
通过 mapreduce.job.node-label-expression 指定标签表达式,x||表示同时使用 x/default 分区。
hadoop jar /usr/local/service/hadoop/share/hadoop/mapreduce/hadoop-mapredu ce-examples-3.1.2.jar pi -D mapreduce.job.queuename="a" -D mapreduce.job. node-label-expression="x||" 10 10
复制代码
使用该命令提交后,观察到 Application 的 container 被分配在 x/default 分区。
四、Hadoop Yarn on Kubernetes Pod 最佳实践
该客户大数据应用和存储跑在 Yarn 管理的大数据集群,在生产环境中,面临诸多问题,主要体现在大数据的算力不足和在线业务波谷时资源的浪费。如离线计算在算力不足时,数据准时性无法得到保证,尤其是当遇到随机紧急大数据查询任务,没有可用的计算资源,只能停掉已有的计算任务,或者等已有任务完成,⽆论哪种⽅式,总体任务执行的效率都会大打折扣。
基于 Hadoop Yarn on Kubernetes Pod 方案,将离线任务自动扩容至云上集群,与 TKE 在线业务集群混合部署,充分利用云上波谷时段的闲置资源,提高离线业务的算力,并利用云上资源快速的弹性扩容能力,及时补充离线计算的算力。
通过 Hadoop Yarn on Kubernetes Pod ⽅案对客户的在线 TKE 集群资源使用进行优化后,集群闲时 CPU 使用率能提高 500%。
在线集群闲时 CPU 占用
离在线混部后 CPU 占用
五、总结
本文提出了基于 YARN 针对云原生容器化的优化与实践,在混合部署云原生环境中,极大地提高了任务运行的稳定性,高效性,有效提高了集群资源利用率,节约硬件成本。在未来,我们会探讨更多大数据云原生场景,为企业客户带来更多的实际效益。
作者简介
张翮,腾讯云高级工程师,目前主要负责腾讯云大数据产品弹性 MapReduce 的管控相关模块和重要组件 Hive 的技术研发。向 Apache Hive,Apache Calcite 开源项目贡献过代码,毕业于电子科技大学。
关注“腾讯云大数据”公众号,技术交流、最新活动、服务专享一站 Get~
标签:default,分区,EMR,Yarn,集群,YARN,scheduler,腾讯,资源 来源: https://www.cnblogs.com/TXcloudbigdata/p/14944679.html