1. 背景 在离线集群中，有些冷数据集群专用于存放HDFS数据，很少用来提供计算操作，这些机器的计算资源都浪费了，它们的典型特征是：只启动datanode服务，不启动nodemanager服务。为了提高这些机器的资源利用率，希望在其他计算集群需要资源的时候，resourcemanager可以在冷数据集群中启动NodeManager服务，最大化利用计算资源。 2. 整体设计 如下所示，通过NodeM
1. 背景 随着业务的增长，Yarn集群也不断扩展。节点数增多、请求增多、队列增多，造成调度性能线性下降。如下是三个集群的性能数据： 集群 队列数量 平均调度耗时 最大每秒调度数量CPS 集群A 2706 3.8 ms 483 集群B 620 940 微秒 1150 集群C 399 676 微秒 1013 对于集群A，其调度耗时已经非常高了，吞吐量也是腰斩。最大内存使用
1. 背景 默认情况下，FairScheduler对资源进行调度时，会使用FSParentQueue.assignContainer先对队列进行排序，然后再调度应用： TreeSet<FSQueue> sortedChildQueues = new TreeSet<>(policy.getComparator()); readLock.lock(); try
1. 背景 在https://blog.51cto.com/u_15327484/7920197文章中，将调度器从FairScheduler迁移到CapacityScheduler。 CapacityScheduler在默认情况下，当接受到NodeManager心跳请求时，会调用nodeUpdate方法开始进行资源调度，这种调度方式称为心跳调度，也称同步调度。 心跳调度实现起来简单，但是有很大的弊
在 https://blog.51cto.com/u_15327484/7894282文章中，介绍了Yarn的两种调度器。在 https://blog.51cto.com/u_15327484/7920197文章中，介绍了FairScheduler迁移Capacity Scheduler的迁移实践。在实际迁移之前，必须要确保Capacity Scheduler能够达到足够的收益，即吞吐率或调度时间等指标都有所优化，才能开启迁移操作。 而为了评估迁移收益，很难直接通过搭建1k+个NodeManager的Yarn集群来测试调度器性能，这样太浪费成本。为了解决这个问题，Hadoop官方提供了Scheduler load Simulator工具，可以用它在单机上模拟超大Yarn集群，测试调度器性能。
1. 背景 需求一 当前线上集群A还是使用fair scheduler，当调度请求量大时，经长发生pending： 观察队列使用情况，发现队列并没有用满，这说明是调度性能问题。 Capacity Scheduler由于使用了细粒度锁、异步调度等特性，吞吐量能够提升5-10倍。因此希望集群能够升级调度器为Capacity Scheduler。 需求二 对于运行在AWS上的nodemanager，为
1. 背景 NodeManager中，将机器的CPU资源抽象为vcore，将内存资源抽象为memory。例如机器为102核、256GB内存，希望赋予NodeManager196GB内存和72核CPU，用于给container分配资源。其配置如下： <property> <name>yarn.nodemanager.resource.memory-mb<
1. 背景 一年前写过的一篇文章：https://blog.51cto.com/u_15327484/5046768，介绍了ResourceManager的启动流程。文章中介绍了ResourceManager的选举流程，但是行文逻辑较混乱。本文在此基础上，更清晰地介绍了resourcemanager的高可用原理，希望能够达到小白也能看懂的程度。 2. Zookeeper相关背景知识 2.1 Wat
1. 背景 此前写过两篇文章，分别介绍了应用提交到ResourceManager的事件流程，Resourcemanager命令Nodemanager启动container流程。 其中，https://blog.51cto.com/u_15327484/7790888介绍了应用提交到ResourceManager的事件流程。其中包含存储application信息到zk中，将application信息
1. 背景 之前写过Yarn状态机的两篇文章。 https://blog.51cto.com/u_15327484/4940200介绍了AsyncDispatcher线程，它提供以下机制： 通过调用它的register()方法注册不同类型事件对应的处理器，放入Map中。 通过调用它的handle()方法将具体的事件放入到事件队列BlockingQueue中。 内部eventHandlingThr
Yarn Active ResourceManager启动框架分析
1.前言上一篇文章介绍了Yarn事件驱动模型框架分析(https://blog.51cto.com/u_15327484/4940200)，了解到Yarn基于生产者消费者模式处理事件。基于GenericEventHandlerhandle生产事件；通过自定义的Handler实现类消费事件。其中，在消费事件时，会导致Yarn中对象状态的变化，将对象所有状态的变化情况汇总起来就是状态机。本文将介绍Ya
Yarn Service框架分析
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
