AWSAutoScaling组是一个极好的功能，该自动化系统负责管理服务器停机时间并为用户提供自动扩展服务。连接到ElasticLoadBalancer的AutoScaling组可以轻松确保应用程序始终正常运行。管理员可以指定一个AmazonWebServices(AWS)AutoScaling组来使用ElasticLoadBalancing(ELB)健康检查，这将确保服务在服务器上运行——而不仅仅是服务器本身。这会快速自动地替换任何行为不当的服务器，杀死坏服务器并用干净的好服务器替换它们。使用ELB健康检查很重要，而不仅仅是ElasticComputeCloud(EC2)健康检查。我遇到过服务器仍在运行的问题，但服务器上的服务已经死亡并且无法重新启动。ELB与服务器断开连接，因为它不再为请求提供服务，但AWSAutoScaling组不会替换它，因为服务器仍在运行。最终所有服务器都出现了同样的问题，服务停止工作。然后，我收到来自Pingdom的警告，通知我Web服务无法正常工作。AWSAutoScaling小组一直认为所有服务器都是健康的，而没有检测到实际的Web服务已经死亡并且无法重新启动。***为每个生产服务使用一个缩放组，即使它们并不真正需要自动缩放。我的大多数AWSAutoScaling组都被简单地描述为“始终保持X数量的服务器运行”。这意味着如果出现问题并且其中一台服务器出现故障，则该服务器将被终止并自动更换。这并不意味着我需要根据负载自动增加服务器数量。但这使得自动执行一些简单的DevOps任务（例如重启服务器）变得更加容易。什么地方出了错？关于AWSEC2定价的一个事实需要稍微讨论一下，那就是用户为每台运行不到一小时的服务器付费。这意味着如果用户启动服务器，然后在五分钟内将其关闭，他仍需按整整一小时付费。这似乎是可以接受的，但如果用户关闭一台服务器并将其替换为完全相同类型和位置的新服务器，则此操作会使成本加倍。起初，我启动了一台服务器，收取了一台费用，五分钟后关闭了那台服务器，又得到了另一台。但是我被收取了2倍的费用，因为服务器要在第一个服务器启动后的一个小时内运行（图1）。当您将该计费模型与AWSAutoScaling组不断终止和重新启动服务器的错误结合使用时，成本只会不断上升。AutoScaling终止一个实例并在五分钟后启动另一个实例。就我而言，AutoScaling组的配置存在问题，并且在出现问题的同一区域中，服务器不断被杀死并重新启动。这意味着每五分钟就会启动一台新服务器并更换旧服务器，从而导致每小时12个实例小时的费用——即使在任何时候只有一个实例在运行。而且该实例甚至无法正常工作。起初我没有注意到，直到我拿到账单清单，因此额外收取了1200的费用。此时，我联系了AWS支持。当我发现这个问题时，我非常沮丧，但亚马逊修复了它，并为损坏的AutoScaling组给予了额外的奖励。AWS还检测到该问题并为我提供2个月的AutoScaling组失控积分。回想起来，我应该为AutoScaling组设置通知，我应该验证AutoScaling的行为不超过每15分钟一次。通过这些更改，最多只能达到正常充电的四倍。那仍然很糟糕，但还不到原来的12倍。我应该验证服务器在所有区域都正常启动。如何防止AutoScaling失败首先，订阅AutoScaling组通知——即使只是使用电子邮件地址，因为使用分页可能有点极端。管理员还应该小心该组突然“跑掉”。如果确实发生了某些事情并且AWSAutoScaling组不断启动并更换服务器，管理员可以禁用可用性区域或阻止该组执行任何操作。将“冷却”时间增加到15分钟可能是个好主意，以防止完全失控地发生类似错误。***，确保服务器启动后给ELB足够的时间来决定最终是否正常启动。如果服务通常需要5分钟才能成功启动，则给它15分钟。如果开发人员检查他至少有2个服务器在ELB后面运行，则运行的服务器必须能够处理新服务器启动时的负载。提供额外的容量总是一个好主意，因为用户在解决问题时可能需要关闭一些服务器。请记住，AWSElasticBeanstalk在内部使用AutoScaling组，因此您也可以订阅它们的通知（如果已设置）。原文链接：http://www.searchcloudcomputing.com.cn/showcontent_91495.htm
