AWS Amazon EC2 Auto Scaling AS 相关(EC2,ELB,NLB)
20180724 Chenxin
实际使用中的注意事项
结合ELB
要在您的 Auto Scaling 组的各实例之间分配流量，可在您的架构中引入一个负载均衡器。
创建AS
AS(auto scaling)在EC2里.
首先创建"启动配置"(模板)
再创建"Auto Scaling 组"(组配置)
拉起EC2条件
在as里的EC2,当我们执行terminate的时候后,as会自动拉起1个新的EC2.
在as里的EC2,当我们执行stop的时候后,as也会自动拉起1个新的EC2.被我们手动stop的EC2保持一段时间的stop状态,约20分钟后会自动进入terminate状态.
AS和ELB跨区域
ELB和AS结合使用的时候,在我们选择a,b,c3个可用区的时候,记得在ELB属性里,将"垮区域"选项打钩(这里应该是控制台翻译错了,应该是AZ).否则,ELB无法垮可用区.默认只会落在某单个可用区.
Auto Scaling 组不能跨多个区域(region),只能垮多个可用区(AZ).ELB应该也是.
扩展策略
ASG除支持这种动态扩展的方式外,还支持"计划的操作",按照类似crontab的方式来扩展.
如果指定了扩展策略，则 Auto Scaling 可以在您的"应用程序的需求"增加或降低时启动或终止实例.
AS中我们配置最小2个,最大4个.并且在"扩展策略"中,设置CPU阀值在10(平均CPU利用率10%以上),就会自动拉起新的EC2.直到将平均CPU利用率降低到10%以内,或者达到"4"的最高限额.
这里我们实验情况是:
原先ELB中有2个实例,然后将该ELB与AS关联,AS拉起的EC2数量在2-4之间(这样,这个ELB最多可以拥有6个EC2).
我们登陆AS初始拉起的2台EC2中的1个,并将CPU耗用99%(死循环),然后等待大约5分钟左右(默认有个300秒),AS会再次拉起2个EC2(即便这样,CPU平均利用率还是超过10%的,但AS拉起的数量达到4了).
当我们终止掉那个shell死循环,CPU回归合理值.大约等待了20分钟,个别EC2在AS中的状态由"可用"变更为"正在等待终止",大约又经过10分钟左右,AS会terminate掉2台EC2.保持资源最小化(最小容量配置的是2).
扩展策略的选项
默认是"目标追踪扩展策略",扩展策略的选择可以配置的项目:这里的"扩展策略"可以选择4种类别,
CPU平均利用率,
每个目标应用程序负载均衡器请求计数,(这个只适用于Application Auto Scaling,如ECS等)
平均网络输入(字节),
平均网络输出(字节).
这里的目标追踪扩展策略,比如选择CPU利用率平均值10%作为阀值.当ASG中的几个实例CPU平均超过10%后,ASG会拉起新的实例,直到平均值低于10%为止.
除此之外,还可以选择简单扩展策略,步进扩展策略(比如CPU达到90%后,拉起多少个实例)
更加具体的选项:如果希望添加内存报警触发扩展,那么可以在"创建扩展策略"中,选择"创建目标跟踪扩展策略"或者"创建一个带有步骤的扩展策略".里面可以添加具体某个EC2内存或CPU,或磁盘达到阀值,触发拉起多少个EC2.
ASG容量
修改asg"详细信息"的所需容量,最小,最大
将所需容量和最小调整为1,原先保持运行状态的2个EC2中的1个进入"正在等待终止"状态,大约经过7分钟左右,该EC2消失.
默认冷却时间,默认300秒.
扩展活动完成到其他扩展活动开始之间的秒数。这段时间也称为“冷却时间”。
冷却时间是 Auto Scaling 组的一个可配置设置，可以帮助确保在上一扩展活动生效前不会启动或终止其他实例。在 Auto Scaling 组使用简单扩展策略动态扩展后，它会等待冷却时间完成，然后再继续扩展活动。在手动扩展 Auto Scaling 组时，默认设置是不等待冷却时间，但您可以覆盖默认设置并采用冷却时间。如果实例运行状况不佳，Auto Scaling 组不会等待冷却时间完成才替换运行状况不佳的实例。
运行状况检查宽限期,默认300秒
就是预热的时间(包括拉起实例后,实例内部游戏脚本所做初始化的时间).300秒为了给实例足够的预热时间.
通常，刚刚投入使用的 Auto Scaling 实例需要预热才能通过 Auto Scaling 运行状况检查。Auto Scaling 等运行状况检查宽限期结束才检查实例的运行状况。EC2 状态检查和 ELB 运行状况检查可以在运行状况检查宽限期过期前完成，但 Auto Scaling 直到运行状况检查宽限期过期后才执行这些检查。为了给实例提供足够的预热时间，请确保运行状况检查宽限期包含应用程序的预期启动时间。请注意，如果您通过添加生命周期挂钩在实例启动时执行操作，在完成生命周期挂钩并且实例进入InService 状态后，运行状况检查宽限期才会启动。
计划的操作
按时间表定期扩展，使您得以按照可预测的负载变化来扩展应用程序。例如，您的 Web 应用程序的流量会在每周的星期三开始增加，并在星期四保持高流量状态，然后在星期五开始下降。您可以根据 Web 应用程序的可预测流量模式来计划扩展活动。
生命周期挂钩
生命周期挂钩使您能够在 Auto Scaling 组启动或终止实例时通过暂停实例执行自定义操作。例如，当新启动的实例暂停时，您可以在其上安装或配置软件。
生命周期挂钩可以结合cloudwatch,或者SNS发送通知.或通过cloudwatch触发事件,然后通过lambda函数执行操作系统或数据的维护处理等工作.这些应该属于高级知识.待之后了解.
cloudwatch
ASG默认会在cloudwatch中创建对应的CPU监控项目(无法删除).
空的ELB(NLB)关联ASG
创建1个没有资源的NLB("目标群组"中的"目标"为空,没有EC2实例在里面),然后与ASG进行关联.
这样就可以实现真正的ELB+ASG了.
知识文档(可以不看)
地区/区域 与 可用区概念
地区/区域,指的是region,大型、分布范围广泛的地理位置.如新加坡,加利福尼亚(美西).但控制台里偶尔也指可用区,比如ELB属性里的"跨区域"属性,指的是垮AZ(已测试).
可用区,Available Zone,每个区域含有多个不同的位置，被称为可用区".
AS再平衡活动
再平衡时，Auto Scaling 在终止旧实例之前启动新实例，所以再平衡不会损害应用程序的性能或可用性。
再平衡活动期间，系统可以暂时超出某组的指定最大容量的 10%（或超出 1 个实例，以较大者为准）。该超出状态仅持续重新平衡该组所需的时间（通常为几分钟）。
AS附加实例/分离实例
可以将现有的EC2实例附加到AS里.最初AS"所需容量"配置的是"1",在现有不在AS里的EC2点击"附加到AS",这时AS"所需容量"会自动变成2.如果分离这个EC2,所需容量又会自动变成1.
"附加"操作,大约需要2分钟生效.而"分离"操作,大约需要10分钟左右完成.
配合cloudwatch的事件和lambda函数,制定生命周期挂钩.属于高级知识.
ASG不能垮VPC