amazon-ec2 - 适用于作业服务器的Amazon Auto Scaling API

Question

我已经阅读了几乎所有的文档，甚至在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是否不是正确的解决方案，或者我是否缺少一些有关其工作原理的重要信息？

谢谢，

Answer 1

经过一番搜索，我发现通常有两种管理作业的AS API或AS的方法:

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

因此，使用这种方法，您将在一段时间内根据您的SQS队列大小制定一个扩展策略(例如，每5分钟SQS消息超过100个，则添加2个服务器；每10分钟SQS消息超过500个) 50％)。缩减将由代码而不是事件策略来处理。

此方法也适用于零群集，因此您可以在不使用群集时将其一直关闭到没有服务器，从而使其具有很高的成本效益。

好处:

易于设置

使用AWS API函数

可能是最快的设置

使用AWS托管API为您管理集群大小

缺点:

如果不使用完整的AWS API很难管理，即在制作新服务器时，如果不执行所有实例ID的完整API命令返回就无法获取它的instanceid。如果您想对集群

进行自我控制，在其他情况下，AWS AS API会给您带来麻烦，并使工作变得更艰难

依靠Amazon知道什么最适合您的钱包。您依靠Amazon API进行正确扩展，这对许多人来说是有利的，但对某些人来说却是不利的。

工作程序必须包含一些服务器池代码，这意味着工作程序不是通用的，并且如果不进行某些配置更改就不能立即将其移动到另一个集群。

考虑到这一点，还有第二种选择，DIY。您可以使用EC2竞价型实例和按需实例API根据您的自定义规则制作自己的AS API。这很容易解释:

您有一个cli脚本，当运行开始时，例如10台服务器

您有一个cronjob，当检测到某些条件满足时，它会使服务器宕机或启动更多

好处:

轻松干净地管理您的最终

可以使通用 worker

服务器池可以开始管理许多群集

您可以制定规则，从AWS上的指标中获取数据并将其与比较和时间范围一起使用以了解情况是否应该更改，这并不是很复杂的事情。

缺点:

很难获得多区域(对于SQS来说并不难，因为SQS是单个区域)

难以处理区域容量和工作负载中的错误

您必须依赖自己的服务器正常运行时间和自己的代码，以确保cronjob可以按预期运行，并按需配置服务器，并在应有的情况下将其中断。

因此，对于最终用户而言，似乎确实是一场较轻松的战斗。我个人仍在考虑这两者，并创建了一个小型的自托管服务器池器，该池器对我有用，但与此同时，我很想尝试使其在AWS自己的API上起作用。

希望这对人们有帮助，

编辑:请注意，使用这两种方法中的任一种，您仍然需要一侧的功能来预测出价方式，因此，您将需要在竞价类型(EC2类型)上调用出价历史记录API并计算出价方式。

另一个编辑:自动检测系统冗余的另一种方法是检查SQS队列的空响应度量。这是您的工作人员对队列执行ping操作并且未收到任何响应的次数。如果您在 worker 使用期间在应用程序中使用排他锁，这将非常有效。