确定性地创建和标记EC2实例

Question

我正在创建3个EC2实例,然后迭代并标记每个实例.有时标签请求会失败,尽管后来的实例似乎正在运行.

这可能是一个时间问题吗？在标记之前我应该​​在创建实例后等待几秒钟吗？有没有确定的方法等待它开始？

Answer 1

更新20140512

AWS同时添加了有关故障排除API请求错误的更详细文档,其中包括一个解决最终一致性的部分,该部分基本上在下面的初始答案中确认了分析:

由于支持API的系统的分布式特性,Amazon EC2 API遵循最终的一致性模型.这意味着您运行的API命令的结果可能不会立即对您运行的所有后续命令可见,这会影响您的Amazon EC2资源.[...]

[...]例如,[...] 如果您运行命令来修改或描述您刚刚创建的资源,则其ID可能不会在整个系统中传播,并且您将收到错误响应该资源的错误不存在.

要管理最终一致性,您可以执行以下操作:

• 在运行命令进行修改之前,请确认资源的状态.使用指数退避算法运行相应的Describe命令,以确保您有足够的时间让前一个命令在系统中传播.[...]

• 在后续命令之间添加等待时间,即使Describe命令返回准确的响应也是如此.应用指数退避算法,从几秒钟的等待时间开始,逐渐增加到大约五分钟的等待时间.

[强调我的]

请注意:大多数AWS开发工具包同时自动应用这些建议,包括调整默认重试策略或甚至添加自定义实现的选项 - 请参阅AWS中的错误重试和指数退避,以获取有关如何自行实施(如果需要)的指导.

更新20130719

各种大规模AWS用户越来越多地遇到AWS API的最终一致设计,他们自然需要深入了解并相应地解决它,例如参见以下文章:

• 处理AWS EC2 API中的最终一致性(作者:Martin Englund,Cloud Foundry)
• 处理不一致的EC2 API(由Aaron Staley,PiCloud提供)

初步答复

正如@datasage 已经评论过的那样,AWS API显然通常只需要被视为最终一致 - 这在第一次遇到时肯定是出乎意料的,但实际上对于事后的大规模服务来说并不太令人惊讶,即工程设备.操作权衡以解决CAP定理.

另请参阅我对Alex Ciminian关于实施AWS竞价型实例请求的幂等性的问题的评论,其中他讨论了有关类似一致性问题的测试结果:

有趣的问题 - [...]我在Bamboo AWS插件的上下文中遇到了各种类似的API延迟,并得出结论认为AWS API需要被视为最终只能全面一致 ; 例如,我甚至遇到过我从创建调用中收到资源ID的情况,可以根据其id来标记资源,但之后还没有描述它,因为据说它还不存在(还).

• 我在这里描述的似乎表明,每个单独的API动作实际上都是由AWS完全独立运行的(并且不仅在外部可见的服务中,甚至在EC2中的单个服务中),因此可能会受到最终的一致性和必须得到相应的待遇.

有关上述案例的详细信息,您可能需要查看AWS API的频繁轮询导致限制,我总结了我们的分析和方法,通过AWS SDK for Java中可用但有限的重试/退避功能改进处理- 解决方案几乎是理想的,但它似乎暂时大大改善了一切.

类似的说明,重新设计的AWS SDK为PHP 2推出专用的"服务员"的对象,让你查询的资源,直到它处于理想状态来解决这个问题,见服务员的内快速启动的详细信息:

SDK提供的高级抽象之一是"服务员"的概念.服务员通过提供一种通过轮询资源等待资源进入特定状态的简单方法,有助于更轻松地使用最终一致的系统.[...]任何以"waitUntil"开头的@method标签都会使用服务员.

$client->waitUntil('BucketExists', array('Bucket' => 'my-bucket'));