在不可预测的时间(用户请求)我需要运行内存密集型作业。为此,我获得了一个现场或按需实例,并使用标记non_idle
标记它。当工作完成(可能需要数小时)时,我会给它标记idle
。由于AWS的每小时计费模型,我希望保持该实例处于活动状态,直到另一个作业进入另一个可计费小时为止。如果有工作进入,则应重复使用该实例并将其标记为non_idle
。如果在此期间没有工作,实例应该终止。
AWS是否为此提供了现成的解决方案?据我所知,CloudWatch无法设置应在特定时间运行的警报,更不用说使用CPUUtilization或实例的标签了。否则,也许我可以简单地为每个创建的实例设置一个java计时器或scala actor,它在创建实例后每小时运行一次,并检查标记idle
。
答案 0 :(得分:4)
此细粒度优化没有现成的AWS解决方案,但您可以使用现有的构建块根据当前实例的启动时间构建您自己的(请参阅Dmitriy Samovskiy的推理智能解决方案) How Long Ago Was This EC2 Instance Started?)。
Shlomo Swidler在他的文章Play “Chicken” with Spot Instances中探讨了这种优化,尽管Amazon EC2 Spot Instances背景下的动机略有不同:
AWS Spot实例具有一个有趣的经济特征 使系统游戏成为可能。像所有EC2实例一样, 当您启动竞价型实例的终止时,您将产生一个 即使您使用不到一个小时,也会收取整个小时的费用。 但是,当AWS由于现货价格超过而终止实例时 出价,您不需要支付当前时间。
当然,机制是相同的,所以你可以简单地重用他组装的脚本,即执行这个脚本而不是标记实例idle
或者除此之外:
#! /bin/bash
t=/tmp/ec2.running.seconds.$$
if wget -q -O $t http://169.254.169.254/latest/meta-data/local-ipv4 ; then
# add 60 seconds artificially as a safety margin
let runningSecs=$(( `date +%s` - `date -r $t +%s` ))+60
rm -f $t
let runningSecsThisHour=$runningSecs%3600
let runningMinsThisHour=$runningSecsThisHour/60
let leftMins=60-$runningMinsThisHour
# start shutdown one minute earlier than actually required
let shutdownDelayMins=$leftMins-1
if [[ $shutdownDelayMins > 1 && $shutdownDelayMins < 60 ]]; then
echo "Shutting down in $shutdownDelayMins mins."
# TODO: Notify off-instance listener that the game of chicken has begun
sudo shutdown -h +$shutdownDelayMins
else
echo "Shutting down now."
sudo shutdown -h now
fi
exit 0
fi
echo "Failed to determine remaining minutes in this billable hour. Terminating now."
sudo shutdown -h now
exit 1
一旦作业进入,您可以取消预定的终止,而不是使用non_idle
标记实例,或者除此之外:
sudo shutdown -c
这也是“红色”按钮&#39;测试/操作期间的紧急命令,参见例如Shlomo的警告:
在使用之前,请确保您真正了解此脚本的功能 它。如果你错误地安排一个实例关闭,你可以 使用此命令取消它,在实例上运行:sudo shutdown -c
您可以通过与最近为Amazon CloudWatch添加选项的Use Amazon CloudWatch to Detect and Shut Down Unused Amazon EC2 Instances进行整合,进一步采用Shlomo的自包含方法,有关详细信息,请参阅介绍性博客文章Amazon CloudWatch - Alarm Actions:
今天,我们为您提供了停止或终止您的EC2的能力 触发CloudWatch警报时的实例。你可以用这个作为 故障安全(检测异常情况,然后采取行动)或作为其一部分 您的应用程序的处理逻辑(等待预期的条件和 然后行动)。 [强调我的]
您的用例特别列在应用程序集成部分中:
您还可以根据您的Custom Metrics创建CloudWatch警报 在逐个实例的基础上观察。例如,你可以 衡量对您自己的Web服务API,页面请求或消息的调用 每分钟发布一次,并根据需要做出回应。
因此,您可以通过Publishing Custom Metrics利用此新功能向CloudWatch指示实例是否应根据Dmitriy的启动时间检测终止(idle
)并再次重置指标一个作业进入并且一个实例应该继续运行(non_idle
) - 就像EC2将负责终止一样,3个自动化步骤中的2个将从实例转移到自动化流程的运营环境和管理以及可见性也相应提高。