首页 > 代码库 > Hadoop-2.4.1学习之容量调度器
Hadoop-2.4.1学习之容量调度器
调度器在计算机世界中占有重要地位,从操作系统到大型应用系统都可见其身影,做为分布式应用系统的典范Hadoop以可插拔的方式提供了调度器的功能,这为实现自定义的调度器提供了接口。Hadoop内置了两种类型的调度器,分别为:CapacityScheduler<和FairScheduler,本篇文章将学习CapacityScheduler。CapacityScheduler允许多个用户共享一个大的集群,并为每个用户分配指定的容量,这样每个用户的应用程序就可以在所分配的容量范围内快速获得资源,CapacityScheduler还可以最大化集群的吞吐率和使用率。
考虑下面的场景,假设存在这样的一个公司或者组织,该组织拥有自己的计算集群,该集群拥有充足的容量在峰值或接近峰值时满足该组织的SLA(服务等级协议)。由于只有该组织使用该集群,尽管某些时刻集群的使用率会很高(峰值),但也会出现使用率偏低的情况,此时集群中的资源将处于闲置的状态,而我们所希望的是尽可能地压榨集群的计算能力,显然存在浪费资源的情况。另外如果还有其它集群,那么还需要付出额外的精力管理维护其它集群。如果能够将上述两种情况结合起来,即将集群的数量降为一个,将所有集群上的应用转移到该单一的集群上,并合理在应用间分配资源,那么既可以降低维护管理成本由提高了集群的吞吐率和使用率。以上场景也使用于多个阻止共享集群的情况,并且由于不用建设私有集群而降低了资金投入,但是不同组织之间可能担心由于其它组织对资源的占用而影响他们自身的SLA。
针对上述场景,CapacityScheduler能够在提供容量保证的同时确保不同组织或用户共享集群的资源。除此之外,CapacityScheduler还能够使组织或用户访问没有被其它组织或用户使用的额外容量,这显然更加高效地使用了集群的资源,并且对于用户来说,在投入有限的情况却享受到了额外的资源。CapacityScheduler提供了严格的限制确保单个程序、用户或者队列不能够消耗集群中不成比例的资源,为已经初始化或者挂起的程序也做了限制以确保集群的公平性和稳定性。
CapacityScheduler机制中主要的抽象概念是队列,提交的作业将加入相应的队列中。CapacityScheduler具有下面的特征:
- 层次化的队列:队列的层次化确保了子队列能够先于其它队列共享资源,这提供了更多对共享资源的控制和可预测性。
- 容量保证:队列将被分配一定额度的容量,这样所有提交到该队列的应用将访问分配给该队列的容量,管理员可以为每个队列分配的容量设置soft限制和可选的hard限制。
- 安全性:每个队列都有严格的ACL控制着哪个用户可以向队列提交应用程序,还有防护措施以保证用户不能查看或者修改其他用户的应用,最后还支持队列管理员角色。
- 灵活性:空闲的资源可以分配给任何队列,即使超出了该队列所能够分配的容量。假设有一个队列在将来的某个时刻请求这些空闲的资源,一旦被调度使用这些资源的任务完成后,这些资源将被分配给请求对列。这确保了资源以可预测和灵活的方式队列使用。
- 多租户:hadoop提供了全方位的设置阻止单一应用、用户和队列独占队列或集群的资源以确保集群不会不堪重负。
- 可操作性:管理员可以在运行时安全地修改队列的定义和诸如容量、ACL等属性,并将对用户的影响降到最低。管理员还可以在运行时增加队列,但不可以在运行时删除队列。用户和管理员还可以通过控制台查看当前分配给各个队列的资源。管理员可以在运行时停止队列以确保正在退出的应用在完成退出前,新的应用程序不能够提交到该队列。如果队列处于STOPPED状态,新应用程序不能够被提交到该队列及其子队列,正在退出的应用继续完成退出过程。管理员还可以启动已经停止的对列。
- 基于资源的调度:支持资源密集的应用程序,应用程序可指定高于默认值的资源需求,这样应用程序可以有不同的资源需求。当前只支持内存和虚拟CPU内核等资源的设置。
在概述了CapacityScheduler的基本特征后,接下来学习如何配置CapacityScheduler。首先在yarn-site.xml中配置使用哪个调度器,该参数为yarn.resourcemanager.scheduler.class,而默认的调度器就是CapacityScheduler。在确定了调度器后,就可以在capacity-scheduler.xml中对CapacityScheduler进行个性化设置,比如增加队列,资源的分配等。在详细描述相关的配置参数前,先了解对列路径的概念,对列路径用于管理队列的层次结构,因此一个对列路径就是对列层级结构的完整路径,以root开始,使用点号(.)为分隔符。之所以以root开头,是因为CapacityScheduler存在一个预定义的队列root,系统中的所有队列都是该root队列的子队列,root队列的队列路径就为root。系统默认设置参数yarn.scheduler.capacity.root.queues的值为default,即预先设置了root队列的默认子队列为default,要想设置多个root子队列,只需要添加队列名称,并用逗号分隔即可。使用yarn.scheduler.capacity.<queue-path>.queues设置某个队列的子队列,如下所示:
<property> <name>yarn.scheduler.capacity.root.queues</name> <value>a,b</value> </property> <property> <name>yarn.scheduler.capacity.root.a.queues</name> <value>a1,a2</value> </property> <property> <name>yarn.scheduler.capacity.root.b.queues</name> <value>b1,b2,b3</value> </property>
接下来就是与资源分配,访问权限等的参数了,具体见下表:
参数 | 用途 | 描述 |
yarn.scheduler.capacity.<queue-path>.capacity | 资源分配 | 用浮点数表示的队列容量的百分比,同一层级所有队列该值的和应为100,假如某一层级只有一个队列,那么该队列的该值就为100。如果存在空闲资源,该队列的应用程序可能消耗多于该值的资源。 |
yarn.scheduler.capacity.<queue-path>.maximum-capacity | 资源分配 | 用浮点数表示的队列最大容量的百分比,该参数限制了队列容量的灵活性,默认-1表示禁用该参数。 |
yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent | 资源分配 | 每个队列在分配给用户的资源上强制限制的百分比,该参数的类型为int。用户限制在最小值和最大值之间变化。最小值由该参数设置,最大值取决于提交应用的用户数量。比如,该参数的值为25(即25%),如果两个用户向队列提交应用,最大值则为50%,即每个用户都不能使用多于50%的队列资源,如果三个用户提交应用,每个用户不能使用多于33%的队列资源,如果4个用户的话,每个用户不能使用多于25%的队列资源。默认值为100,意味着没有应用用户限制。 |
yarn.scheduler.capacity.<queue-path>.user-limit-factor | 资源分配 | 队列容量的倍数(浮点数),该参数允许单个用户请求更多的资源,默认值为1,表示无论集群多么空闲,单个用户都不可以获得对于队列容量的资源。 |
yarn.scheduler.capacity.maximum-applications / yarn.scheduler.capacity.<queue-path>.maximum-applications | 应用控制 | 系统中可以同时处于运行和待定状态的应用程序的最大数量。每个队列的该限制与该队列的容量和用户限制成正比的。该参数是hard限制,一旦达到该限制,再提交应用程序将被拒绝,默认值为10000。可以使用yarn.scheduler.capacity.maximum-applications 为所有的队列设置该限制,也可以使用yarn.scheduler.capacity.<queue-path>.maximum-applications 为特定队列设置该限制。 |
yarn.scheduler.capacity.maximum-am-resource-percent / yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent | 应用控制 | 集群中用于运行ApplicationMaster的最大资源比例,控制并发运行的应用程序的数量。每个队列的该限制与该队列的容量和用户限制成正比的。该参数的类型为浮点数,如0.2=20%,默认值为0.1=10%。第一个参数用于所有队列,第二参数针对特定队列。 |
yarn.scheduler.capacity.<queue-path>.state | 队列状态 | 该参数的值为RUNNING 或STOPPED,表示队列的状态。如果队列处于STOPPED,将不能向该队列及其子队列提交新的应用程序,因此如果root处于STOPPED,则不能向整个集群提交应用程序。 |
yarn.scheduler.capacity.root.<queue-path>.acl_submit_applications | 应用的提交ACL | 可以向指定队列提交应用程序的用户ACL,如果给定的用户或组在给定的队列或任意父队列拥有必需的ACL,则可以提交应用程序。如果未指定ACL,则从父队列继承ACL。 |
yarn.scheduler.capacity.root.<queue-path>.acl_administer_queue | 应用的管理ACL | 可以管理指定队列中应用程序的用户ACL,如果给定的用户或组在给定的队列或任意父队列拥有必需的ACL,则可以管理应用程序。如果未指定ACL,则从父队列继承ACL。 |
yarn.scheduler.capacity.resource-calculator | 资源计算器 | 调度器中用于比较和操作资源的ResourceCalculator,默认为org.apache.hadoop.yarn.util.resource.DefaultResourseCalculator,该类仅比较了内存资源,而DominantResourceCalculator则比较了内存、CPU等多维资源 。 |
yarn.scheduler.capacity.node-locality-delay | 数据本地化 | 在CapacityScheduler尝试调度本地机架的容器后,错失的调度机会的数量。通常将该参数设置为集群中的节点数量,默认为40。 |
本文中ACL的格式为"user1,user2 group1,group",user和group之间使用空格风格,*表示任何人都可以提交和管理应用,空格表示没人可以提交和管理应用。
前面曾经提到可以在运行时修改队列,而要实现该目的只需要修改capacity-scheduler.xml中的相关配置,然后运行yarn rmadmin –refreshQueues。最后在ResourceManager的web页面中看一下默认情况下CapacityScheduler的显示:Hadoop-2.4.1学习之容量调度器