快速AWS自动扩展

Question

如何配置AWS自动扩展以快速扩展？我已经设置了一个带有ELB的AWS自动缩放组。一切都运行良好，除了在添加新实例并在线之前需要几分钟。我在关于Puppet和autoscaling的帖子中遇到了以下内容：

  

如果用于一组节点的AMI已经是最新的，则缩放时间可以从几分钟降低到几秒钟。

http://puppetlabs.com/blog/rapid-scaling-with-auto-generated-amis-using-puppet/

这是真的吗？可以缩短时间缩短到几秒钟吗？使用puppet会增加任何性能提升吗？

我还读到较小的实例比较大的实例开始更快：

  

小型实例1.7 GB内存，1个EC2计算单元（1个虚拟核心，1个EC2计算单元），160 GB实例存储，32位平台，基本安装CentOS 5.3 AMI

     

从启动实例到可用性的时间：       5到6分钟us-east-1c

     

大型实例7.5 GB内存，4个EC2计算单元（2个虚拟核，每个2个EC2计算单元），850 GB实例存储，64位平台，基本安装CentOS 5.3 AMI

     

从启动实例到可用性的时间量：
  在11到18分钟之间us-east-1c

     

两者都是使用Amazons工具通过命令行启动的。

http://www.philchen.com/2009/04/21/how-long-does-it-take-to-launch-an-amazon-ec2-instance

我注意到这篇文章已经过时了，我的c1.xlarge实例肯定没有花费18分钟来启动。尽管如此，配置具有50个微实例的自动缩放组（具有100％容量增加的扩展策略）是否会比具有20个大实例的自动缩放组更有效？或者可能创建两个自动缩放组，其中一个用于快速启动时间，另一个用于在几分钟后添加CPU grunt的大型实例？在其他条件相同的情况下，t1.micro上线的速度比c1.xlarge快多少？

Answer 1

你可以通过玩耍来增加或减少自动调节器的反应时间 “--cooldown”值（以秒为单位）。 关于要使用的实例类型，这主要基于应用程序类型，在关闭性能监视器和生产调整之后应该对此主题做出决定。

Answer 2

  

缩放时间可以从几分钟降低到几秒钟   如果您用于一组节点的AMI已经是最新的。这个   当Puppet在启动时运行时，它必须做很少的事情，如果有的话，   使用节点的已分配角色配置实例。

这里的建议是讨论让您的AMI（操作系统的快照）尽可能最新。这样，当自动缩放程序启动新计算机时，Puppet不必像通常在空白AMI上那样安装大量软件，它可能只需要提取一些更新的应用程序文件。

根据Puppet脚本的工作量（apt-get install，编译软件等），这可以节省5-20分钟。

您需要担心的另外两个因素是：

• 您的负载均衡器需要多长时间才能确定您需要更多资源（例如，当CPU超过90％超过5分钟时，应该添加新机器的策略）响应速度会降低，并且更有可能导致超时相比“当CPU超过60％超过1分钟时应添加新机器”）
• 配置新EC2实例需要多长时间（较小的实例类型往往会缩短配置时间）

Answer 3

ASG响应的时间将取决于三件事：

<强> 1。步骤 - 增加多少％或固定数量 - 一大步 - 你可以迅速增加。 ASG将一次性启动整个步骤

<强> 2。冷却期 - 这适用于＆＃39; 多久＆＃39; 下一次增加可能会发生。如果前一个增加步骤仍然在定义的冷却时间（秒）内，ASG将等待并且不对下一次增加采取行动。具有较短的冷却时间将使下一步更快。

3 AMI类型 - AMI启动需要多长时间，这取决于AMI的类型 - 许多因素起作用。所有东西都相同完全烘烤的AMI发射得更快