问题标签 [autoscaling]

这是Activity 数据类型的文档。

但是，我想我已经看到了 4 个响应状态代码：

还有其他人吗？

我已经阅读了几乎整个文档，甚至超出了 AWS AS API 以了解所有 AS 内容。

但是我仍然想知道（我还没有实际使用过 API，因为我想先从某人那里找到这个）我的场景是否适用于 AS。

假设我在一个 AS 组中设置了一堆工作服务器，每个服务器都在从事一项工作，然后突然到了（我不知道，AVG CPU 大于或在另一种情况下小于 80%）的时候来扩大或缩小规模。

我主要担心的是失去一份正在进行的工作。也许用一个例子可以更好地解释这一点：

• 我启动了 5 个作业服务器，上面有 5 个作业
• 一个作业完成并在 Amazon API 中触发缩减触发器
• 亚马逊开始缩小它们的规模
• 我失去了一个实际上正在运行作业的作业服务器（完成 90% 必须重新开始）

考虑到这一点，我最好只使用 Amazon Spot Instance/EC2 API 并管理我自己的扩展，还是我在 Amazon API 如何判断服务器终止方面缺少一些东西？

老实说，我宁愿缩放到 SQS 等待量而不是服务器上的一些健康数据：

• 每等待 100 条消息，集群容量增加 20%

但这对于 AS 似乎也不太可行。

那么 AWS AS API 不是正确的解决方案，还是我错过了一些关于它如何工作的重要信息？

谢谢，

我对小于 1e-10 的数字的 y 缩放有问题：它们都出现在同一水平线上。

这是一个可重现的示例：

如您所见，使用基本绘图功能，点可以正确显示，而使用 ggplot2 它们显示在水平线上。

我在 2011 年 5 月的邮件列表上看到了一个类似的帖子，Hadley 回答说它与 ggplot2 的开发版本一起工作。但是，使用下面描述的 R 版本我仍然得到错误。

有人有线索吗？

先感谢您 ！蒂博·鲁勒

当您将实例设置为自动缩放并设置最小和最大限制时，它是否会缩放到最大值，或者是否检查 as 创建的每个实例的阈值，然后生成？

如中，1 个实例触发 90% cpu 使用率的警报 -> AutoScale 再创建 1 个实例（共 2 个）-> does it check for 90% cpu usage on both the instances & THEN create new instances or does it create new instances anyway after the cooldown time？

有没有办法让添加到自动缩放组的新实例与弹性 IP 关联？我有一个用例，我的自动缩放组中的实例需要在远程服务器上列入白名单，因此它们需要具有可预测的 IP。

我意识到有一些方法可以使用 API 以编程方式执行此操作，但我想知道是否还有其他方法。CloudFormation 似乎可以做到这一点。

我有一个 ec2 实例为 apache 提供网页服务。我在启动配置中使用此实例的 AMI 创建了一个自动缩放组。一旦 CPU 超过 80% 并且自动缩放策略运行，就会创建一个新实例。但是我的原始实例的 CPU 继续上升，而我的新实例的 CPU 保持在 0%。

新实例未提供网页。我猜这是因为 apache 并没有随着图像的启动而启动。我尝试通过 ssh 进入新实例以运行“service httpd start”，但出现以下错误：

为什么我不能 ssh 进入？如何配置自动缩放以在启动时自动启动 apache？

您如何配置 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 快多少？

我已经使用这些步骤设置了自动缩放...

$ elb-create-lb autoscalelb --headers --listener "lb-port=80,instance-port=80,protocol=http" --listener "lb-port=443,instance-port=443,protocol=tcp" --availability-zones us-east-1d

$ elb-describe-lbs 自动缩放lb

$ elb-register-instances-with-lb autoscalelb --instances i-ee364697

$ elb-configure-healthcheck autoscalelb --headers --target "TCP:80" --interval 5 --timeout 3 --unhealthy-threshold 2 --healthy-threshold 4

$ as-create-launch-config autoscalelc --image-id ami-baba68d3 --instance-type t1.micro

$ as-create-auto-scaling-group autoscleasg --availability-zones us-east-1d --launch-configuration autoscalelc --min-size 1 --max-size 5 --desired-capacity 1 --load-balancers自动缩放lb

$ as-describe-auto-scaling-groups autoscleasg

$ as-put-scaling-policy MyScaleUpPolicy --auto-scaling-group autoscleasg --adjustment=1 --type ChangeInCapacity --cooldown 300

$ mon-put-metric-alarm MyHighCPUAlarm --comparison-operator GreaterThanThreshold --evaluation-periods 1 --metric-name CPUUtilization --namespace "AWS/EC2" --period 600 --statistic Average --threshold 80 --alarm -actions arn:aws:autoscaling:us-east-1:616259365041:scalingPolicy:46c2d3b3-7f29-42b6-ab64-548f45de334f:autoScalingGroupName/autoscleasg:policyName/MyScaleUpPolicy --dimensions "AutoScalingGroupName=autoscleasg"

$ as-put-scaling-policy MyScaleDownPolicy --auto-scaling-group autoscleasg --adjustment=-1 --type ChangeInCapacity --cooldown 300

$ mon-put-metric-alarm MyLowCPUAlarm --comparison-operator LessThanThreshold --evaluation-periods 1 --metric-name CPUUtilization --namespace "AWS/EC2" --period 600 --statistic Average --threshold 50 --alarm -actions arn:aws:autoscaling:us-east-1:616259365041:scalingPolicy:30ccd42c-06fe-401a-8b8f-a4e49bbb9c7d:autoScalingGroupName/autoscleasg:policyName/MyScaleDownPolicy --dimensions "AutoScalingGroupName=autoscleasg"

在此之后我运行这个命令：

$ as-describe-auto-scaling-groups autoscleasg --headers

回复：

AUTO-SCALING-GROUP GROUP-NAME LAUNCH-CONFIG AVAILABILITY-ZONES LOAD-BALANCERS MIN-SIZE MAX-SIZE DESIRED-CAPACITY AUTO-SCALING-GROUP autoscleasg autoscalelc us-east-1d autoscalelb
1 5 1 实例实例 ID 可用性-区域状态状态 LAUNCH-CONFIG 实例 i-acf48bd5 us-east-1d InService 健康 autoscalelc

接着：

$ elb-describe-instance-health autoscalelb --headers

表明：

INSTANCE_ID INSTANCE_ID 状态描述
原因代码 INSTANCE_ID i-ee364697 InService N/A
N/A INSTANCE_ID i-acf48bd5 OutOfService 实例至少连续失败了 UnhealthyThreshold 数量的健康检查。实例

我的第一个问题是：

当 Main 实例没有负载时，它会自动创建一个额外的实例。

其次，新创建的实例总是 OutOfService。

如果我使用以下命令将 Min Size 更改为 0：

$ as-update-auto-scaling-group autoscleasg --launch-configuration autoscalelc --availability-zones us-east-1d --min-size 0 --max-size 5

并尝试使用 xen 加载实例：

hg 克隆http://xenbits.xensource.com/xen-unstable.hg

自动缩放不创建任何实例。即使我在最多 5 个会话上运行以上命令，CPU 利用率也达到 100%，但仍然没有创建实例。

请帮我...

我有一个在亚马逊弹性豆茎上运行的网站，其流量模式如下：

• 通常约 50 个并发用户。
• 发布到 Facebook 页面时，约 2000 个并发用户 1/2 分钟。

亚马逊网络服务声称能够快速扩展以应对此类挑战，但 cloudwatch 的“大于 x 超过 1 分钟”设置对于这种流量模式似乎不够快？

通常在几秒钟内所有 ec2 实例崩溃，杀死所有 cloudwatch 指标，整个站点停机 4/6 分钟。到目前为止，我还没有找到适用于这个场景的配置。

这是一个较小的事件的图表，该事件也杀死了该站点：

我们正在研究使用 EC2 自动缩放来处理负载峰值。在我们的例子中，我们希望根据 SQS 队列大小扩大实例，然后随着队列大小缩小规模，重新得到控制。每条 SQS 消息都定义了一个可能长时间运行的作业（有时每条消息最长 20 分钟），该作业必须在实例终止之前完成。

我们的软件会优雅地处理关闭过程，因此发布sudo service ourapp stop将等待应用程序完成后再返回。

我的问题; 当自动缩放开始缩小时它会发出终止（显然就像按下电源按钮），它会等待我们的应用程序在实例“关闭”之前完全退出吗？

https://forums.aws.amazon.com/message.jspa?messageID=180674 <- 我发现的其他事情似乎表明它没有