参考资料
-
https://docs.amazonaws.cn/en_us/batch/latest/userguide/job_queue_parameters.html#job_queue_scheduling_policy
-
https://docs.amazonaws.cn/en_us/batch/latest/userguide/scheduling-policies.html
-
https://catalog.us-east-1.prod.workshops.aws/workshops/c3d652f2-6de1-4014-9a1b-c1b3c8f08b8d/en-US/
我们可以为任务队列设定调度策略,调度策略决定了资源在不同用户和工作负载的分配方式。
队列默认使用FIFO调度策略,如果没有设置调度策略则之后无法修改。设置调度策略后可以调换但不能删除
FIFO调度策略
下图是单队列环境下任务调度的逻辑。
- 调度程序从队列头部获取任务,尝试将任务放置在计算环境中
- 提交作业的顺序就是执行顺序,头部任务按顺序后移
对于多队列来说,调度逻辑如下图
-
评估周期循环从队列头部获取任务进行评估
-
高优先级的队列首先被评估和调度(队列1的优先级为2,高于队列1)
-
调度器接受的任务数量取决于账户的每秒可处理最大事务数(TPS)
https://docs.amazonaws.cn/batch/latest/userguide/service_limits.html
然而,FIFO策略会导致不公平,后提交的任务始终需要在前面任务完成后,才能执行
https://catalog.us-east-1.prod.workshops.aws/workshops/c3d652f2-6de1-4014-9a1b-c1b3c8f08b8d/en-US/fifo/unfair
实际测试下FIFO调度策略的效果
-
创建max为56个vcpu的fargate计算环境
-
创建两个任务队列queue1(优先级为1)和queue2(优先级为2)
-
创建任务定义,这里使用busybox将任务停止60s,这里指定所需cpu为8,计算环境最多容纳7个任务
https://docs.aws.amazon.com/cli/latest/reference/batch/register-job-definition.html
需要注意:fargate类型的任务,vcpu和memory只能指定符合规范的值,否则可能会报错
"message": "Error executing request, Exception : Fargate resource requirements (16.00 vCPU, 16384 MiB) not valid., RequestId: 45905a0c-23cd-4339-a15a-8dae5af79776"
-
向队列1提交任务
for x in {1..10}; do aws batch submit-job --job-definition test-job:3 --job-name "test-job1-${x}" --job-queue first-fargate-queue |jq '.jobName' done
-
向队列2提交任务
for x in {1..10}; do aws batch submit-job --job-definition test-job:3 --job-name "test-job2-${x}" --job-queue second-fargate-queue |jq '.jobName' done
-
列出任务的状态
// listqueue.sh queuename=$1 echo "### Queue: ${queuename}" for STATUS in RUNNABLE RUNNING SUCCEEDED FAILED;do aws batch list-jobs --job-queue=${queuename} --job-status=${STATUS} |jq --arg s "$STATUS" '.jobSummaryList[]| "["+$s+"] "+.jobName' done listBatchQueue first-fargate-queue listBatchQueue second-fargate-queue
调度效果
-
对不同队列来说,优先级高的队列先调度,已经运行的任务不会被抢断
-
对同一队列来说,先来的先调度
Fair Share调度策略
公平调度策略允许对任务进行更细粒度的调度控制
调度策略可以设置的参数如下
share identifier
调度策略允许使用 share identifier
在不同用户或工作负载之间分配作业队列中的计算资源。Amazon Batch 根据所有最近使用的公平共享标识符的总权重为每个公平共享标识符分配一个共享。这定义了具有公平共享标识符的作业可使用的总资源量。
调度程序通过使用vcpu_used_over_time X overridden_ weight_factor
公式跟踪每个公平共享标识符的使用情况,从share idenifier
中选择使用率最低的作业。
{
"name": "multiWorkloadSP",
"fairsharePolicy": {
"computeReservation": 0,
"shareDecaySeconds": 0,
"shareDistribution": [{
"shareIdentifier": "blueSP1"
},{
"shareIdentifier": "greenSP1"
}]
}
}
例如下图中,blue和green两个标识符,默认权重为1,因此平分计算资源,两个标识符的任务交错调度
weight factor
权重因子决定 batch 分配share identifier
的可用资源的数量。
weight factor
是一个介于0和1000之间的数字,默认值为1,值越低分配的运行时反而会越多
priority
提交任务时,可以选择任务的优先级,优先级的任务不需要等待前面的任务完成,能够插队调度
Compute reservation
计算资源的预留 (0% -> 99%)比例为 (computeReservation/100)^ActiveFairShares,其中ActiveFairShares
为公平标识符的数量
例如下图所示,设定预留比率为50,存在2个标识符,因此最终计算资源的比例为25%。即使当前没有blue任务,仍旧有一个计算资源留存,不参与green任务的调度,反之亦然。
Decay factor
https://catalog.us-east-1.prod.workshops.aws/workshops/c3d652f2-6de1-4014-9a1b-c1b3c8f08b8d/en-US/fair/decay
衰减因子决定了调度器用来计算公平标识符计算资源使用时间的范围,设置为0表示只考虑当前使用率
之前提到调度器会选择当前使用率较低的标识符任务,设定较大的衰减因子,使得之前运行过的标识符任务,在之后的一段时间获得较少的执行时间
调度效果
-
对于同一identifier的任务,共享identifier的计算资源
-
对于不同identifier,按照权重在identifier之间分配计算资源,调度取决于过去的计算资源使用情况
-
优先级高的任务先调度
-
资源预留能够为每个标识符留存资源避免其他标识符的任务调度