7

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

如果您用于一组节点的 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

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

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 快多少？

4

3 回答 3

2

您可以通过使用“--cooldown”值（以秒为单位）来增加或减少自动扩缩器的反应时间。关于要使用的实例类型，这主要取决于应用程序类型，并且应该在密切的性能监控和生产调整之后做出关于这个主题的决定。

于 2012-07-25T08:30:02.277 回答
1

如果您用于一组节点的 AMI 已经是最新的，则扩展时间可以从几分钟减少到几秒钟。这样，当 Puppet 在启动时运行时，它只需很少（如果有的话）使用节点分配的角色配置实例。

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

根据您的 Puppet 脚本所做的工作量（apt-get 安装、编译软件等），这可以为您节省 5-20 分钟。

您必须担心的另外两个因素是：

  • 您的负载均衡器需要多长时间才能确定您需要更多资源（例如，规定“当 CPU 超过 90% 超过 5 分钟时应添加新机器”的策略）响应速度较慢，并且更有可能导致超时“当 CPU 超过 60% 超过 1 分钟时，应添加新机器”）
  • 预置一个新的 EC2 实例需要多长时间（较小的实例类型往往需要较短的预置时间）
于 2013-04-08T00:59:14.650 回答
0

ASG 的响应速度取决于三件事：

1. 步长——增加多少%或固定数字——大步长——可以快速增加。ASG 将一次性启动整个 Step

2. 冷却期- 这适用于下一次增加可能发生的“多快” 。如果之前的增加步骤仍在定义的冷却时间（秒）内，ASG 将等待并且不采取行动进行下一次增加。有一个小的冷却时间将使下一步更快。

3 AMI 类型 - AMI 启动需要多长时间，这取决于 AMI 的类型 - 许多因素都在起作用。一切都一样 完全烘焙的 AMI 启动速度更快

于 2017-11-13T18:04:58.670 回答