【问题标题】:Amazon Auto Scaling API for Job Servers用于作业服务器的 Amazon Auto Scaling API
【发布时间】:2012-06-08 19:56:50
【问题描述】:

我已经阅读了几乎整个文档,甚至超出了 AWS AS API 以了解所有 AS 内容。

但是我仍然想知道(我还没有实际使用过 API,因为我想先从某人那里找到这一点)我的场景是否适用于 AS。

假设我在一个 AS 组中设置了一堆工作服务器,每个服务器都在从事一项工作,突然到了扩大规模的时候了(我不知道,AVG CPU 大于或在另一种情况下小于 80%)或向下。

我主要担心的是失去了一份正在进行的工作。也许这可以用一个例子来更好地解释:

  • 我启动了 5 个作业服务器,上面有 5 个作业
  • 作业完成并在 Amazon API 中触发缩减触发器
  • 亚马逊开始缩小规模
  • 我失去了一个实际上正在运行作业的作业服务器(完成 90% 需要重新开始)

考虑到这一点,我最好只使用 Amazon Spot Instance/EC2 API 并管理我自己的扩展,还是我在 Amazon API 如何判断服务器终止方面缺少一些东西?

老实说,我宁愿缩放到 SQS 等待量,也不愿服务器上的一些健康数据:

  • 每等待 100 条消息,集群容量就会增加 20%

但这对于 AS 似乎也不太可行。

那么 AWS AS API 不是正确的解决方案,还是我错过了一些关于它如何工作的重要信息?

谢谢,

【问题讨论】:

  • 理论上,如果你写一个脚本以干净的方式完成所有工作,然后把它放在/etc/rc0.d中,它不应该工作吗?我只将 AS 用于此类问题并不重要的网络服务器实例,所以我不确定。
  • 有趣的是你说我可以通过添加一个 rc 来阻止 AWS 关闭,是不是我必须检查一下
  • 虽然从根本上说,如果它确实有效,那是一个有点苛刻的解决方案,也许我会更好地管理我自己的工作扩展?正如你所说,你通常只将它用于网络服务器实例
  • 不,这只是因为我还没有另一个自动缩放用例,所以这就是为什么我只有“哑”网络服务器实例的 AS 经验。如果您有 SQS,也许这篇文章会有所帮助:aws.amazon.com/articles/1464
  • 啊,我一定是错过了那篇文章,谢谢,我会好好阅读的 :)

标签: amazon-ec2 amazon-web-services autoscaling


【解决方案1】:

经过一番搜索,我发现有两种公认的方式来管理 AS API 或一般用于作业的 AS:

一种方法是直接从工作器自身内部操纵服务器的运行状况。这是相当多的站点所做的并且它是有效的,当您的工作人员检测到系统中没有更多的工作或冗余时,它会将其所在的服务器标记为不健康。这样,AS API 就会出现并在一段时间后自动将其删除。

因此,使用此方法,您将在一段时间内根据 SQS 队列大小制定扩展策略(例如,每 5 分钟 SQS 消息超过 100 条时添加 2 台服务器;每 10 分钟 SQS 消息超过 500 条网络容量增加 50%)。缩减将由代码而不是活动策略来处理。

此方法也适用于零集群,因此您可以在不使用集群时将集群一直关闭到没有服务器,从而非常经济高效。

优点:

  • 易于设置
  • 使用 AWS API 函数
  • 可能是最快的设置
  • 使用 AWS 托管 API 为您管理集群大小

缺点:

  • 如果不使用完整的 AWS API 就很难管理,即在创建新服务器时,如果不执行所有 instanceid 的完整 API 命令返回,就无法取回它的 instanceid。在其他情况下,如果您想要对集群进行自我控制,AWS AS API 会妨碍您并让生活变得更加困难
  • 依靠亚马逊了解什么最适合您的钱包。您正在依靠 Amazon API 来正确扩展,这对许多人来说是一个优势,但对某些人来说却是一个劣势。
  • worker 必须包含一些服务器池代码,这意味着 worker 不是通用的,不能在不更改配置的情况下立即移动到另一个集群。

考虑到这一点,还有第二种选择,DIY。您使用 EC2 Spot Instance 和 on Demand Instance API 根据您的自定义规则创建自己的 AS API。这很容易解释:

  • 您有一个 cli 脚本,当运行启动时,例如 10 个服务器
  • 您有一个 cronjob,当检测到满足某些条件时,服务器会停机或更多

优点:

  • 轻松干净地管理您的终端
  • 可以做普通工人
  • 服务器池可以开始管理多个集群
  • 您可以制定规则,从 AWS 上的指标中获取数据并使用它们与比较和时间范围来了解事情是否应该改变。

缺点:

  • 很难获得多区域(对 SQS 来说还不错,因为 SQS 是单区域)
  • 难以处理区域容量和工作负载方面的错误
  • 您必须依靠自己的服务器正常运行时间和自己的代码来确保 cronjob 正常运行,并按应有的方式配置服务器,并在应该的时候将其分解。

因此,对于最终用户而言,这似乎是一场更舒适的战斗。我个人仍在考虑这两者,并创建了一个小型的自托管服务器池,它可以为我工作,但同时我很想尝试让它在 AWS 自己的 API 上工作。

希望这对人们有所帮助,

编辑:请注意,使用这两种方法中的任何一种,您仍然需要一个函数来预测您应该如何出价,因此您需要在您的现货类型(EC2 类型)上调用出价历史 API 并计算如何出价。

另一个编辑:在系统中自动检测冗余的另一种方法是检查 SQS 队列的空响应指标。这是您的工作人员 ping 队列但未收到响应的次数。如果您在工作期间在应用中使用排他锁,这将非常有效。

【讨论】:

  • 对于第一个解决方案,您如何处理自动缩放组的所需容量?事实上,如果有一个自动扩展操作(扩展),那么所需的容量设置为 2。如果我们只是关闭实例,那么自动扩展组将重新创建一个新实例。
  • @TalalMAZROUI 实际上,它不会只管理要关闭的服务器的自动缩放大小。如果您制作工作队列,我找到了一个更好的方法,尽管它没有选择性地控制如何关闭服务器。您可以使用 Amazon SQS 的大小来了解是否应缩小缩放组的大小,查看我用于分布式视频编码器的模板:github.com/Sammaye/vidcoder_cloudformation 您将看到我如何在队列以确定自动缩放组大小。
  • @TalalMAZROUI 重新阅读我的答案,第一个场景包括服务器运行状况和 SQS。我还意识到您说的是“所需容量”,在这种情况下,是的,即使您的扩展策略不允许,AWS 也会始终尝试分配两台服务器。如果您希望它与基于零的集群一起使用,那么您需要将所需的集群大小定义为 0。
【解决方案2】:

我刚刚遇到了同样的问题,我和一个亚马逊人谈了谈,他跟我谈了终止保护。 事实上,如果一个实例激活了终止保护,它不能被终止。当触发缩减时,应用程序将从自动缩放组中删除,但不会终止。 要终止它,您必须禁用终止保护,然后终止它(例如,您可以在工作结束时执行此操作)。

总结一下,你要做的是:

  • 在您的 AMI 中添加启动脚本以激活终止保护
  • 保持您的自动缩放规则(放大和缩小)
  • 在正在运行的实例上,一旦可以安全终止实例(作业结束,...),请停用终止保护并终止实例

您可以使用 AWS API 完成所有这些工作。

【讨论】:

  • 是的,终止保护旨在防止终止。事实上,自动缩放的设计目的是在没有终止保护的情况下工作,因为实例应该根据服务器上的某些参数等来随意创建和终止,所以使用带有自动缩放的终止保护有点不合时宜。
  • 是的,但是由于自动缩放不允许我们在某些情况下终止实例,我们必须找到解决方法
  • 这是不正确的,根据:docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/… ------------ "如果你启用了实例终止保护Auto Scaling 组中的按需实例的属性,Auto Scaling 将覆盖该属性并终止实例。”
  • 2015 年 12 月,AWS 为 Auto Scaling 添加了实例保护docs.aws.amazon.com/autoscaling/latest/userguide/…
猜你喜欢
  • 2017-02-01
  • 2015-10-05
  • 2011-11-24
  • 1970-01-01
  • 2018-11-18
  • 2022-01-22
  • 2015-04-21
  • 2014-04-05
  • 1970-01-01
相关资源
最近更新 更多