3 Hadoop: Capacity Scheduler
3.1 目的
这个文档主要描述CapacityScheduler是一个可拔插的调度器,允许多用户安全的共享巨大的集群,这样他们的应用可以及时的在约束允许的情况下分配资源。
3.2 概述
CapacityScheduler被设计成共享的方式运行Hadoop应用,多用户集群,最大化吞吐量和资源利用。
CapaCityScheduler在提供共享集群资源的情况下,又能提供必要的各个成员的资源保障。并且相对于多个独立的hadoop集群来说,共享资源大集群的维护开销变低。还有个好处就是能提供一部分资源弹性。
CapaCityScheduler引入了一个queue的概念。队列分层的概念可以保障各个子队列的资源。
3.3 特性
CapacityScheduler支持一下特性:
1.分层队列:分层队列是用来保障子队列之间的资源共享,当然如果有空闲的资源也可以被其他队列使用。
2.容量保证:提交的队列的应用可以使用分配给队列的容量。管理员可以配置队列资源的软限制和硬限制。
3.安全性:每个队列有严格的ACL来控制用户提交应用到特定的队列,还可以控制用户是否可以查看,修改其他用户提交的应用。
4.弹性:空闲的资源可以分配给其他队列,这些队列可以突破资源的限制。
5.多用户:所有这些限制是为了防止一个应用,用户,分组占用过多的资源。
6.操作性:
6.1 运行配置:队列的定义和属性比如容量,ACL可以在运行时被修改。控制台也可以查看当前队列中分配的资源。管理员可以在运行时增加,删除队列。
6.2 排出应用:管理可以队列,可以删除被关闭的队列,无法提交新的应用到队列,对于已经在队列的应用会继续直到完成。
7.基于资源的调度:支持资源敏感的应用。
8.基于用户定义或者默认规则的队列映射接口:允许用户把job提交到特定的队列
9.优先级调度:允许用户以不同的优先级调度,值越大优先级越高,只支持FIFO排序规则
10.绝对资源配置:资源配置不再是一个百分比,可以指定需要的资源。
11.动态创建和管理叶队列:主要是和基于用户组的队列映射关联。
3.4 配置
3.4.1 设置启动CapacityScheduler
在conf/yarn-site.xml设置
属性 | 值 |
---|---|
yarn.resourcemanager.scheduler.class | org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler |
3.4.2 设置队列
etc/hadoop/capacity-scheduler.xml是CapacityScheduler的配置文件。
CapacityScheduler有个预定的根队列root。所有的队列都是root的子队列。
其他队列可以yarn.scheduler.capacity.root.queues中配置逗号分开。
CapacityScheduler引入了一个概念叫队列路径,上下级使用点号分割。
给定队列的子队列可以使用
yarn.scheduler.capacity.
<property>
<name>yarn.scheduler.capacity.root.queues</name>
<value>a,b,c</value>
<description>The queues at the this level (root is the root queue).
</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.a.queues</name>
<value>a1,a2</value>
<description>The queues at the this level (root is the root queue).
</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.b.queues</name>
<value>b1,b2,b3</value>
<description>The queues at the this level (root is the root queue).
</description>
</property>
3.4.3 队列属性
1.资源分配
属性 | 值 |
---|---|
yarn.scheduler.capacity. |
队列的容量可以是百分比也可以是绝对资源的最小容量 |
yarn.scheduler.capacity. |
百分比或者绝对值,容量的最大值 |
yarn.scheduler.capacity. |
限制队列中每个用户的资源比率 |
yarn.scheduler.capacity. |
用户限制因子,如果设置为1,不管集群有多空闲用户都不会获取超过队列的容量 |
yarn.scheduler.capacity. |
队列中每个容器的内存分配限制 |
yarn.scheduler.capacity. |
队列中每个容器vcore分配限制 |
yarn.scheduler.capacity. |
队列中用户分配的资源比率 |
2.使用绝对资源配置资源分配 | |
CapacityScheduler支持绝对的资源配置而不是队列容量的百分比。[memory=10240,vcores=12]表示10GB内存和12个VCore。 | |
3.Running和Pending的应用限制 | |
CapacityScheduler支持以下参数控制应用: |
属性 | 值 |
---|---|
yarn.scheduler.capacity.maximum-applications / yarn.scheduler.capacity. |
可以并发的Running和Pending的应用个数 |
yarn.scheduler.capacity.maximum-am-resource-percent / yarn.scheduler.capacity. |
集群中运行application master所占用的资源比率 |
4.队列管理和权限 | |
CapacityScheduler支持以下参数来保证对队列的管理: |
属性 | 值 |
---|---|
yarn.scheduler.capacity. |
队列状态Running或者Stopped |
yarn.scheduler.capacity.root. |
提交队列的权限 |
yarn.scheduler.capacity.root. |
管理队列中的应用的权限 |
注:ACL格式user1,user2 空格 group1,group2,*表示任何人,默认是*。 | |
5.基于用户,分组,应用名或者用户定义的规则映射队列 | |
CapacityScheduler支持以下参数配置队列映射。用户也能定义自己的映射规则: |
属性 | 值 |
---|---|
yarn.scheduler.capacity.queue-mappings | 把用户,分组映射到指定队列 |
yarn.scheduler.queue-placement-rules.app-name | 把应用名映射到指定队列 |
yarn.scheduler.capacity.queue-mappings-override.enable | 用户指定的队列是否可以被覆盖 |
注:队列映射语法 [u or g]:[name]:[queue_name][,next_mapping]* | |
6.应用在队列中的生存时间 | |
CapacityScheduler支持以下参数管理生存时间: |
属性 | 值 |
---|---|
yarn.scheduler.capacity. |
提交到队列之后最大生存时间 |
yarn.scheduler.capacity.root. |
提交到队列之后默认生存时间 |
3.4.4 应用优先级
应用优先级只有在FIFO排序规则下才能使用,默认FIFO。
默认优先级是对于应用程序的不能在集群级别或者队列级别:
1.集群级别优先级
任何应用提交的优先级高于集群最大的优先级,会被重置为集群最大的优先级。在yarn-site.xml配置集群最大优先级。
属性 | 值 |
---|---|
yarn.cluster.max-application-priority | 集群中应用程序最大属性 |
2.叶队列级别优先级 | |
每个叶队列也由管理员提供了优先级,队列默认的优先级是给应用没有提供优先级给与默认优先级。 | |
属性 | 值 |
--- | --- |
yarn.scheduler.capacity.root. |
叶队列默认优先级 |
3.4.5 Capacity Scheduler抢占式容器
CapacityScheduler支持抢占式容器,来自资源使用超过保证的容量的队列。以下yarn-site.xml中的配置支持抢占式容器。
属性 | 值 |
---|---|
yarn.resourcemanager.scheduler.monitor.enable | 启动定期监视器 |
yarn.resourcemanager.scheduler.monitor.policies | 与调度器交互的SchedulingEditPolicy类 |
以下配置参数可以yarn-site.xml配置用来控制抢占式容器,如果以上2个参数已经被配置了。
属性 | 值 |
---|---|
yarn.resourcemanager.monitor.capacity.preemption.observe_only | 如果为ture,运行策略但是不影响集群的枪战和kill event,默认为false |
yarn.resourcemanager.monitor.capacity.preemption.monitoring_interval | ProportionalCapacityPreemptionPolicy的周期 |
yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill | 请求多少时间之后没有响应就会被kill |
yarn.resourcemanager.monitor.capacity.preemption.total_preemption_per_round | 一趟最多能分配的资源百分比 |
yarn.resourcemanager.monitor.capacity.preemption.max_ignored_over_capacity | 最大可以多出多少容量,百分比 |
yarn.resourcemanager.monitor.capacity.preemption.natural_termination_factor | 自然终止因子,给定一个抢占式目标,计算自然死亡的容器,并抢占一个因子的资源 |
注:natural_termination_factor很难理解可以看cloudera的解释 |
yarn.resourcemanager.monitor.capacity.preemption.natural_termination_factor=1.0
Similar to total_preemption_per_round, you can apply this factor to slow down resource preemption after the preemption target is computed for each queue (for example, “give me 5 GB back from queue-A”). For example, if 5 GB is needed back, in the first cycle preemption takes back 1 GB (20% of 5GB), 0.8 GB (20% of the remaining 4 GB) in the next, 0.64 GB (20% of the remaining 3.2 GB) next, and so on. You can increase this value to speed up resource reclamation. The recommended value for this parameter is 1.0, meaning that 100% of the target capacity is preempted in a cycle.
3.4.5 保留属性
1.保留管理和权限
CapacityScheduler一直一下参数来控制,保留的创建,删除,更新和listing。任何用户可以创建,删除,更新和listing他们的保留。如果保留的权限启用,但是没有定义,那么每个用户都可以访问。
属性 | 值 |
---|---|
yarn.scheduler.capacity.root. |
给定队列保留的管理权限 |
yarn.scheduler.capacity.root. |
给定队列保留的list权限 |
yarn.scheduler.capacity.root. |
给定队列保留的提交权限 |
3.4.6 配置CapacityScheduler的ReservationSystem
ReservationSystem允许用户预先保留一份资源。应用程序可以在运行是通过ReservationId请求一份保留资源。yarn-site.xml配置ReservationSystem
属性 | 值 |
---|---|
yarn.resourcemanager.reservation-system.enable | 是否启动保留系统,默认启动 |
yarn.resourcemanager.reservation-system.class | ReservationSystem类名 |
yarn.resourcemanager.reservation-system.plan.follower | PlanFollower类名,运行了一个计时器,用来在CapacityScheduler和Plan之间同步,默认值由调度器决定 |
yarn.resourcemanager.reservation-system.planfollower.time-step | PlanFollower计时器时间 |
保留系统被集成在CapacityScheduler分层队列,并且可以配置叶队列。CapacityScheduler支持以下参数来调整保留系统: |
属性 | 值 |
---|---|
yarn.scheduler.capacity. |
是否可以使用保留系统 |
yarn.scheduler.capacity. |
类名,实现了ReservationAgent把用户的保留请求放到Plan,默认为org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.AlignedPlannerWithGreedy |
yarn.scheduler.capacity. |
当请求过期之后,是否移动,kill到父可保留队列 |
yarn.scheduler.capacity. |
调度器UI是否显示保留队列 |
yarn.scheduler.capacity. |
类名,用于确定SharingPolicy的实现,会验证性的保留会不会侵犯其他的保留。 |
yarn.scheduler.capacity. |
验证保留的时间窗口 |
yarn.scheduler.capacity. |
SharingPolicy允许单个用户保留的最大容量 |
yarn.scheduler.capacity. |
在时间窗口内,每个用户可保留的平均值 |
yarn.scheduler.capacity. |
类名,用来实现,当plan的容量下降是被调用,会扫描plan LIFO的方式删除保留,直到达到plan容量 |
yarn.scheduler.capacity. |
Planner验证plan的约束是否安全的时间窗口 |
3.4.6 动态自动创建和管理叶队列
1.在队列映射启动动态自动创建叶队列
用户组队列映射被列在yarn.scheduler.capacity.queue-mappings需要指定父队列,表示该父队列自动创建也队列。
<property>
<name>yarn.scheduler.capacity.queue-mappings</name>
<value>u:user1:queue1,g:group1:queue2,u:user2:%primary_group,u:%user:parent1.%user</value>
<description>
Here, u:%user:parent1.%user mapping allows any <user> other than user1,
user2 to be mapped to its own user specific leaf queue which
will be auto-created under <parent1>.
</description>
</property>
2.父队列配置动态叶队列的创建和管理
动态队列创建和管理功能是继承在CapacityScheduler分层队列。
属性 | 值 |
---|---|
yarn.scheduler.capacity. |
表示队列启动自动创建叶队列 |
yarn.scheduler.capacity. |
类名,实现AutoCreatedQueueManagementPolicy,管理叶队列并且他们的容量在父队列是动态的 |
3.配置CapacityScheduler的自动创建叶队列 | |
父队列被启动了自动叶队列创建,支持自动创建叶队列的自动配置模板。自动创建叶队列可以配置所有参数除了Queue ACL,绝对资源配置。Queue ACL是从父队列继承的 |
属性 | 值 |
---|---|
yarn.scheduler.capacity. |
自动创建叶队列的最小容量保证 |
yarn.scheduler.capacity. |
可以配置其他所有队列的属性 |
<property>
<name>yarn.scheduler.capacity.root.parent1.auto-create-child-queue.enabled</name>
<value>true</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.capacity</name>
<value>5</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.maximum-capacity</name>
<value>100</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.user-limit-factor</name>
<value>3.0</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.ordering-policy</name>
<value>fair</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.parent1.GPU.capacity</name>
<value>50</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.parent1.accessible-node-labels</name>
<value>GPU,SSD</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.accessible-node-labels</name>
<value>GPU</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.accessible-node-labels.GPU.capacity</name>
<value>5</value>
</property>
4.调度编辑策略配置自动创建叶队列管理
需要为yarn.resourcemanager.monitor.capacity.queue-management.monitoring-interval配置
org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.QueueManagementDynamicEditPolicy
3.4.7 其他属性
1.资源计算
属性 | 值 |
---|---|
yarn.scheduler.capacity.resource-calculator | ResouceCalculator用来在调度器中比较资源 |
2.Data Locality | |
CapacityScheduler使用Delay Scheduling实现地域约束。有3个级别node-local,rack-local和off-switch。调度器会为没有机会调度的应用计数。当计数到达阈值的时候会进入下一个级别。 |
属性 | 值 |
---|---|
yarn.scheduler.capacity.node-locality-delay | 超过阈值之后会在rack-local级别运行 |
yarn.scheduler.capacity.rack-locality-additional-delay | 超过阈值之后会在off-switch运行 |
注:若yarn.scheduler.capacity.node-locality-delay为-1,则地域约束就会被忽略 | |
3.NodeManager心跳的容器分配 | |
CapacityScheduler支持以下参数可以控制每个NodeManager心跳可以控制多少容器 |
属性 | 值 |
---|---|
yarn.scheduler.capacity.per-node-heartbeat.multiple-assignments-enabled | 启动NodeManager心跳分配多个容器 |
yarn.scheduler.capacity.per-node-heartbeat.maximum-container-assignments | 可以有多少个容器 |
yarn.scheduler.capacity.per-node-heartbeat.maximum-offswitch-assignments | 在offswitch下可以有多少个容器 |
3.4.8 CapacityScheduler配置查看
1.使用yarn集群的方式
2.使用ResourceManager的UI
3.在/scheduler网页中
3.5 修改队列配置
有2中方式修改队列或者调度器配置:
1.通过文件方式
2.通过API,API的修改是在内存的不能持久
2.1 leveldb,通过API修改配置,并且保存在leveldb中
2.2 zk,通过API修改配置,并保存在zookeeper中
3.5.1 通过文件修改队列配置
编辑conf/capacity-scheduler.xml,然后运行yarn rmadmin -refreshQueues刷新配置。
1.通过文件删除队列
在删除叶队列之前必须要保证队列里面app并且通过修改队列状态为 BE STOPPED
删除队列,直接修改配置文件并且刷新。
2.通过API修改配置
需要在yarn-site.xml做一些配置
属性 | 值 |
---|---|
yarn.scheduler.configuration.store.class | 使用的存储类型,zk,levedb |
yarn.scheduler.configuration.mutation.acl-policy.class | 关于那些用户可以修改队列配置的权限策略 |
yarn.scheduler.configuration.store.max-logs | 保留多大的日志 |
yarn.scheduler.configuration.leveldb-store.path | levedb存储的路径 |
yarn.scheduler.configuration.leveldb-store.compaction-interval-secs | 使用leveldb 多久保存一次配置 |
yarn.scheduler.configuration.zk-store.parent-path | 使用zk是保存路径 |
3.6 更新容器
一个application master收到一个来自资源管理的容器,可能请求资源管理器更新容器的属性
当前有2个容器修改的类型被支持:
1.资源修改:AM请求RM更新资源
2.执行类型更新:AM可以请求RM更新执行类型
这样AM就引入了一个属性updated_containers,是在
AllocateRequestProto中的一个类型
UpdateContainerRequestProto。
UpdateContainerRequestProto 的值:
message UpdateContainerRequestProto {
required int32 container_version = 1;
required ContainerIdProto container_id = 2;
required ContainerUpdateTypeProto update_type = 3;
optional ResourceProto capability = 4;
optional ExecutionTypeProto execution_type = 5;
}
ContainerUpdateTypeProto 是枚举类型:
enum ContainerUpdateTypeProto {
INCREASE_RESOURCE = 0;
DECREASE_RESOURCE = 1;
PROMOTE_EXECUTION_TYPE = 2;
DEMOTE_EXECUTION_TYPE = 3;
}
AM必须提供最新从RM收到的最新的ContainerProto 。这个就是RM尝试更新的容器。
如果RM可以更新请求的容器,更新容器并且在返回值
AllocateResponseProto的updated_containers 中,类型为UpdatedContainerProto
UpdatedContainerProto 类型:
message UpdatedContainerProto {
required ContainerUpdateTypeProto update_type = 1;
required ContainerProto container = 2;
}
3.7 活动
调度器活动是活动信息用户重要调度路径的调试,以RESTful API暴露。有2个类型的活动,调度器活动,应用程序活动
3.7.1 调度器活动
调度器活动包括调度信息,显示了调度器是如何分配容器的。调度器活动REST API通过了记录调度器活动记录的方式,这些信息可以从cache上获得。
3.7.2 应用活动
应用程序活动就是应用的的调度信息,显示请求是否被满足还是被跳过。也通过REST API暴露。
3.7.3 配置
CapacityScheduler 支持以下参数控制cache大小和过期时间。
属性 | 值 |
---|---|
yarn.resourcemanager.activities-manager.cleanup-interval-ms | 清除cache的时间间隔 |
yarn.resourcemanager.activities-manager.scheduler-activities.ttl-ms | 调度器活动的生存周期 |
yarn.resourcemanager.activities-manager.app-activities.ttl-ms | 应用活动的生存周期 |
yarn.resourcemanager.activities-manager.app-activities.max-queue-length | app活动的最大长度 |