Auto Scaling EC2 或其他云计算基础设施有哪些实际限制？答案

【问题标题】：What are the practical limitations with auto scaling EC2 or other cloud computing infrastructure?Auto Scaling EC2 或其他云计算基础设施有哪些实际限制？
【发布时间】：2010-11-11 00:50:54
【问题描述】：

我很好奇是否有人在 EC2 或其他云计算基础设施中尝试过 Auto Scaling Web 或 db 层？这在理论上似乎是可能的，但我很好奇实际限制是什么/可能。

谢谢！

【问题讨论】：

标签： amazon-ec2 scalability autoscaling

【解决方案1】：

这更像是一个问题而不是一个答案，但我即将开始自己尝试自动缩放（很可能使用 Amazon CloudFront 工具）并且我认为实例启动时间将是一个因素。我注意到一个新的 EC2 实例可能需要 5 到 20 分钟才能启动，所以当负载增加时，您不能立即添加更多容量；您似乎需要一个或多个空闲实例来运行并准备好承受增加的负载。

【讨论】：

非常真实，我注意到在 Windows 服务器上，尤其是。我想您可能会有 1 或 2 个“等待”在机翼中，并且随着消耗而旋转另一个。您是否正在考虑使用负载均衡器或进行 DNS 循环？
我们计划使用 Amazon 自动扩展工具 (aws.amazon.com/autoscaling)

【解决方案2】：

我们也开始关注自动缩放。

第一个候选方法是使用 Amazon 的 ELB（弹性负载均衡器）和 Cloud Front。但是，我们的流量是一种网络服务。调用者频繁发送 100-Continue http 消息，ELB 无法理解该消息。亚马逊还没有关于什么时候可以解决这个问题的消息。此外，亚马逊论坛中有许多关于 ELB 无法处理重负载的投诉。

LigHTTPD 1.5 看起来像是一个很有前途的部分解决方案，因为它可以检测实例何时无法运行并透明地将其从轮换中移除，并且可以在不重新启动负载平衡器的情况下进行动态重新配置。

还有许多商业解决方案。我们可能会看看 Right Scale。

【讨论】：

【解决方案3】：

后期添加：

同时考虑 SimpleDB...这将消除 DB 扩展方面。

对于自动缩放，我们推出了自己的脚本来监控、启动和配置服务器，是的，整个过程大约需要 7 分钟。我们做了一些预测分析来猜测何时需要新服务器，如果不需要，就将它们分解。总成本：~10 美分。

此外，Scalr 作为一种商业解决方案看起来很有前途（尚未使用过）。

乍得

【讨论】：