从可用区域中断自动恢复？

Question

在可用区域遭受Amazon Web Services/EC2中断的情况下,是否有任何工具或技术可用于在不同的可用区域中自动创建新实例？

我想我了解如何在可用区域(AZ)中断时自动进行故障转移,但是从停机中自动恢复(在新的AZ中创建新实例)怎么办？那可能吗？

示例场景:

1. 我们有一个三实例集群.
2. ELB循环到群集的流量.
3. 我们可以丢失任何一个实例,但不能丢失集群中的两个实例,并且仍然可以完全正常运行.
4. 由于(3),每个实例都在不同的AZ中.称他们为亚洲A,B和C.
5. ELB运行状况检查已配置,以便ELB可以确保每个实例都运行正常.
6. 假设由于AZ A中的AZ中断导致一个实例丢失.

此时,ELB将看到丢失的实例不再响应运行状况检查,并将停止将流量路由到该实例.所有请求都将转到剩下的两个健康实例.故障转移成功.

恢复是我不清楚的地方.有没有办法自动(即没有人为干预)替换新AZ中的丢失实例(例如AZ D)？这将避免具有中断(A)的AZ并且不使用已经具有实例的AZ(AZs B和C).

AutoScaling群组？

AutoScaling Groups似乎是一个很有前途的开始,但我不知道他们是否可以正确处理这个用例.

问题:

在AutoScaling组中,似乎没有办法指定应该在新的AZ中创建替换死/不健康实例的新实例(例如,在AZ D中创建它,而不是在AZ A中创建).这是真的吗？在AutoScaling组中,似乎没有办法告诉ELB删除失败的AZ并自动添加新的AZ.是对的吗？

AutoScaling群组中存在这些真正的缺点,还是我错过了什么？

如果使用AutoScaling组无法完成此操作,是否还有其他工具会自动为我执行此操作？

2011年,FourSquare,Reddit和其他人因依赖单一可用区而陷入困境(http://www.informationweek.com/cloud-computing/infrastructure/amazon-outage-multiple-zones-a-smart-str/240009598) .从那时起,工具似乎已经走过了漫长的道路.缺乏自动恢复解决方案让我感到惊讶.每个公司都只是自己动手解决方案和/或进行恢复吗？或者也许他们只是掷骰子并希望它不会再次发生？

更新:

@Steffen欧宝,感谢您的详细解释.自动缩放组看起来更好,但我认为与ELB一起使用时仍存在问题.

假设我创建了一个自动缩放组,其最小值,最大值和期望值设置为3,分布在4个AZ中.自动缩放将在3个不同的AZ中创建1个实例,第4个AZ保留为空.如何配置ELB？如果它转发到所有4个AZ,那将无法工作,因为一个AZ将始终具有零实例,并且ELB仍将路由流量到它.这将导致在流量进入空AZ时返回HTTP 503.我过去经历过这一点.这是我之前看到的一个例子.

这似乎需要手动将ELB的AZ更新为那些在其中运行实例的AZ.每次自动缩放导致不同的AZ混合时,都需要进行此操作.是的,或者我错过了什么？

Answer 1

有没有办法自动(即没有人为干预)替换新AZ中的丢失实例(例如AZ D)？

Auto Scaling确实是适合您用例的服务 - 回答您各自的问题:

在AutoScaling组中,似乎没有办法指定应该在新的AZ中创建替换死/不健康实例的新实例(例如,在AZ D中创建它,而不是在AZ A中创建).这是真的吗？在AutoScaling组中,似乎没有办法告诉ELB删除失败的AZ并自动添加新的AZ.是对的吗？

您不必明确指定/告知任何内容,它隐含在Auto Scaling的工作方式中(请参阅Auto Scaling概念和术语) - 您只需配置一个Auto Scaling组,其中包含a)您要运行的实例数(通过定义组必须具有的最小,最大和所需运行的EC2实例数量)和b)哪些AZ是您的实例的适当目标(通常/理想情况下,您的帐户中某个区域内可用的所有AZ).

然后Auto Scaling负责a)启动所请求的实例数量,以及b)在配置的AZ中平衡这些实例.自动处理AZ中断,请参阅可用区和区域:

通过Auto Scaling,您可以跨区域内的多个可用区域划分Auto Scaling组,从而充分利用地理冗余的安全性和可靠性.当一个可用区变得不健康或不可用时,Auto Scaling会在未受影响的可用区中启动新实例.当不健康的可用区恢复到正常状态时,Auto Scaling会自动在所有指定的可用区中均匀地重新分配应用程序实例.[强调我的]

后续部分跨多个区域的实例分布和平衡进一步解释了算法:

Auto Scaling尝试在为Auto Scaling组启用的可用区之间均匀分布实例.Auto Scaling通过尝试使用最少的实例在可用区中启动新实例来实现此目的.但是,如果尝试失败,Auto Scaling将尝试在其他区域中启动,直到成功为止.[强调我的]

请查看链接的文档以获取更多详细信息以及如何处理边缘情况.

更新

关于关于AZ数量高于实例数量的后续问题,我认为您需要采用务实的方法:

您只需选择一个等于或低于您想要运行的实例数的AZz数; 在AZ中断的情况下,自动缩放会很乐意在剩余正常AZS平衡你的情况下,这意味着你能够生存下来的2出3 AZS停运你的榜样,而且还有所有 3个实例中运行的剩余AZ.

请注意,虽然使用尽可能多的AZ可能很有趣,但新客户只能访问美国东部(弗吉尼亚北部)的三个EC2可用区和两个美国西部(北加利福尼亚州)(参见全球基础设施),即只有较旧的帐户实际上可以访问所有5个AZ us-east-1,其中一些只有4个,最新的3个最多.

• 我认为这是一个遗留问题,即AWS显然正在使旧的AZ停止运行.例如,即使您可以访问所有5个AZ us-east-1,实际上某些实例类型也可能不可用(例如,新EC2第二代标准实例 m3.xlarge,m3.2xlarge并且仅在其中一个中的5个AZ中可用我正在使用的帐户).

换句话说,2-3个AZ被认为是区域内容错的一个相当好的折衷方案,如果任何跨区域容错可能是我要担心的下一件事.