AWS Amazon EC2 Auto Scaling AS 相关(EC2,ELB,NLB)

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