提供了编程的基础技术教程

zl程序教程

您现在的位置是：首页 >  工具

当前栏目

ASG 目标跟踪缩放政策 Target tracking scaling policies 笔记

笔记 目标 跟踪 Target 缩放 政策 Tracking
2023-09-14 09:12:59 时间

ASG 目标跟踪缩放政策 Target tracking scaling policies

今天详细介绍 Auto Scaling Group 的 Target tracking scaling policies，下图为我们要实作的环境，为安全考虑我们将 Auto Scaling Group 放到私有子网，而 ELB 则是需要对外开放所以放在公有子网，考虑容错，所以跨两个可用区。

具有自动扩展功能的应用程序架构
图 1. 具有自动扩展功能的应用程序架构

Aoto Scaling Group 建置

有接下来的操作其实跟 Auto Scaling Up/Down 自动扩展或缩减笔记类似，可以参照该网址，但为方便起见我们还是操作一遍

  1. 建置 VPC 与相关的子网 - 请参阅 Amazon VPC 实操。
  2. 新增 EC2 实例 - 请参阅 Amazon Elastic Compute Cloud (EC2) 笔记。
  3. 新增 AMI - 建置一个 AMI 模板供后续的 Launch Configuration 使用

根据以上所建立的 EC2 实例，我们必须在该实例上进行一些雏型系统配置，作为将来检验之用

系统设定

# 安装套件 httpd php  
sudo yum -y install httpd php 
# 启动 Web Server
sudo systemctl start httpd
# 设定 Web Server 为系统服务，可在下次重开机时自动启动
sudo systemctl enable httpd

应用程序设定
首页程序 index.php，可以增加主机CPU负载的链结

<center>
<p>
<a href="put-cpu-load.php" target="_blank">Increase CPU Load</a>
</p>
<table class='table table-bordered'>
<tr><th>Meta-Data</th><th>Value</th></tr>
<?php
  #The URL root is the AWS meta data service URL where metadata
  # requests regarding the running instance can be made
  $urlRoot="http://169.254.169.254/latest/meta-data/";
  $instanceId = file_get_contents($urlRoot . 'instance-id');
  $availabilityZone = file_get_contents($urlRoot . 'placement/availability-zone');
  # Get the instance ID from meta-data and print to the screen
  echo "<tr><td>InstanceId</td><td><i>" . $instanceId . "</i></td><tr>";
  # Availability Zone
  echo "<tr><td>Availability Zone</td><td><i>" . $availabilityZone . "</i></td><tr>";
?>
</table>
</center>

产生 CPU 负载的程序 put-cpu-load.php

<?php
  # Start PHP Session to keep track of whether or not load is getting generated
  session_start();
  
  echo "<meta http-equiv=\"refresh\" content=\"5,URL=./put-cpu-load.php\" />";

  $idleCpu = exec('vmstat 1 2 | awk \'{ for (i=1; i<=NF; i++) if ($i=="id") { getline; getline; print $i }}\'');

  if ($idleCpu > 50) {

    echo exec('dd if=/dev/zero bs=100M count=500 | gzip | gzip -d  > /dev/null &');
    echo "Generating CPU Load! (auto refresh in 5 seconds)";
  }
  else {
    echo "Under High CPU Load! (auto refresh in 5 seconds)";
  }
  echo "<br /><p>Current CPU Load: <b>"; 
  echo 100-$idleCpu;
  echo "%</b></p>";
?>

透过浏览器确认功能无误，确认首首以及产生 CPU 负载测试页均可正常运行，如下图显示

确认 EC2 实例的功能符合要求
图 2. 确认 EC2 实例的功能符合要求

到 EC2 控制台，选择左边选单中的 实例，再选择刚刚建立的 EC2 实例，按鼠标右建，选择 Image > Create Image，接着输入以下内容建可以建立一个 AMI Image

Image name : ithomeAMI
Image description : ithome Web Server AMI

新增 AMI
图 3. 新增 AMI

输入 AMI 信息
图 4. 输入 AMI 信息

  1. 新增 Application Load Balancer (ALB) - 原则上跟 Elastic Load Balancing (ELB) 笔记很类似，只有第五个步骤 Register Targets，有所不同，原来的步骤是

Register Targets: 指定目标群的内容，将先前设定的两个 EC2 实例指定到上面新建立的目标群

指定负载平衡器目标群内容
图 5. 指定负载平衡器目标群内容

但因为这次的目标群是不固定的，会在下一个步骤再设定，所以应该是不要指定，如下图

负载平衡器目标群内容不指定
图 6. 负载平衡器目标群内容不指定

  1. 新增 Launch Configuration - 设定目标群内的 EC2 实例的启动组态

到 EC2 控制台，选择左边选单中的 Launch Configuration，按下右边的建立启动组态按钮

建立启动组态
图 7. 建立启动组态

完成启动组态设定

名称 : ithomeLC
AMI : ithomeAMI
实例类型 : t2.micro (1 vCPU, 1 GiB, 仅 EBS)
监控 (Monitoring) : 在 CloudWatch 中启用 EC2 实例详细监控 #重要！!!启用详细监控之后，当您使用此启动组态时，Auto Scaling 群组可以具备相关扩展政策，以 1 分钟的频率在 Amazon EC2 实例指标上扩展。
指派安全群组 :
选取现有的安全群组
ithome_web_SG
密钥对选项 :
选择现有的密钥对
ithome

启动组态设定画面
图 8. 启动组态设定画面

  1. 新增 Auto Scaling Group

到 EC2 控制台，选择左边选单中的 Auto Scaling 群组，按下右边的建立 Auto Scaling 群组按钮，接下来需要完成七个步骤来完成Auto Scaling 群组的设定

步骤 1. 选择启动模板或组态

Auto Scaling 组名 : ithomeACG
启动组态 : ithomeLC (记得一定要先按下转换至启动组态，才会切换到选择启动组态)

选择启动组态
图 9. 选择启动组态

步骤 2. 进行设定
选择私有子网

VPC : vpc-0bb7004b67556d0da (172.16.0.0/16) | ithomeVPC
子网 :
ap-southeast-1a | subnet-0c60019adc4bec5f6 (ithome private subnet 1) 172.16.1.0/24
ap-southeast-1b | subnet-0b047b309432d952c (ithome private subnet 2) 172.16.2.0/24

网络组态设定
图 10. 网络组态设定

步骤 3 (选用) 设定进阶选项

负载平衡
勾选 启用负载平衡
_Application Load Balancer _
为您的负载平衡器选择目标组 : ithomeTargetGroup
监控 : 勾选 在 CloudWatch 中启用群组指针集合

负载平衡设定
图 11. 负载平衡设定

步骤 4 (选用) 设定群组大小和扩展政策

群组大小 - 选用
变更所需的容量，以指定 Auto Scaling 群组的大小。您也可以指定最小和最大容量限制。所需的容量必须在限制范围内。
所需容量 : 2 # 指的是一开始启动 Auto Scaling Group 会启动的 EC2 实例数量
容量下限 : 1 # 指的是 Auto Scaling Group 最少正在执行的 EC2 实例数量
容量上限 : 10 # 指的是 Auto Scaling Group 最多正在正常执行的 EC2 实例数量

扩展政策 - 选用
选择 目标追踪扩展政策
选择所需的结果，并将其保留至扩展政策中，视需要新增和移除容量，以实现该结果。
扩展政策名称: itHomePolicy
指标类型 : 平均 CPU 使用率
目标数值 : 50
纳入指标之前的暖机秒数 : 120

这个设定的意思是说当整个 Auto Scaling Group 的平均 CPU 使用率为 50% 的话，会扩展一台新的 EC2 实例来降低整个系统的负荷
纳入指标之前的暖机秒数这个数字是说，当新增一台新的 EC2 实例，从启动到可以被注册到目标群的时间

设定群组大小和扩展政策
图 12. 设定群组大小和扩展政策

步骤 5 (选用) 新增通知

没有设定

步骤 6 (选用) 新增标签

标签
密钥 : Name # 注意大小写是不同的
数值 : itHomeWebServer

设定新启动的 EC2 实例的名称
图 13. 设定新启动的 EC2 实例的名称

步骤 7. 检阅

再次确认上述数据有无错误后，确认新增

观察目标追踪扩展政策的运作

当完成上述步骤后就算是完成 Auto Scaling Group 的建置，但问题是他是如何运行的，让我们再看一次他的运行架构，下图描述了 AWS 自动扩展或缩减架构， ELB 对外提供服务，透过 Cloud Watch 来监控 ELB 目前的状态，根据使用者是先定义好的 Auto Scaling Policy 来通知 Auto Scaling 是否要新增 EC2 实例，如果需要，则从 Launch Configuration 所定义好的 EC2 实例进行启动，并放置到 ELB 的 target group 中。

AWS 自动扩展或缩减架构
图 14. AWS 自动扩展或缩减架构

简单来说，驱动整个 Auto Scaling Group 运行的关键服务其实是 CloudWatch 警示，我们切换到 CloudWatch 的控制台看看，根据刚刚建立的目标追踪扩展政策，产生了甚么影响。按下上方的服务按钮，选择 CloudWatch ，进入CloudWatch控制台后，按下右方功能选单警示，应该可以看到两个刚刚建立的 CloudWatch 警示，分别是 TargetTracking-ithomeASG-AlarmLow-xxx , TargetTracking-ithomeASG-AlarmHigh-xxx ，这两个警示是设定目标追踪扩展政策后，系统自动生成的。

目标追踪扩展政策建立的 CloudWatch 警示
图 15. 目标追踪扩展政策建立的 CloudWatch 警示

检视这两个警示可以发现一些细节，我们先看一下底下这张扩展政策触发示意图，当我们预期的事件发生时，比方说平均 CPU 使用率 60% 是 9:00:20，而我们设定的 CloudWatch 监控周期是 1 分钟，所以会在 9:01:00， CloudWatch 才发现目前的平均 CPU 使用率已经超过 60% ，但请注意，并不是现在就发出 CloudWatch 警示，请注意看上图，它触发的条件为 CPUUtilization > 50 (适用于 3 分钟 内的 3 数据点) ，我们忽略 CPU 使用率的值，关注后面的 3 分钟 内的 3 数据点，这说明系统发出 CloudWatch 警示的时间会是在9:03:00，另一个是 CloudWatch 警示并没有在设定中是系统自动生成，会在监控到 CPUUtilization < 42.5 后连续 15 分钟，才发出 CloudWatch 警示通知关闭 EC2 实例。

扩展政策触发示意图
图 16. 扩展政策触发示意图

接下来我们来确认这样的想法是否正确，于是在13:33分拉高 CPU 使用率，预期应该会在 3~4 分钟左右，约 13:37 ，发出 CloudWatch 警示。我们来实际验证一下，到 EC2 控制台，选择左边选单中的 Auto Scaling Groups，选择指定的自动缩放群 ithomeASG ，按下下方的 活动(Activation) 页签，在这个页签会找到活动历史记录。如下图所示

Auto Scaling Group 活动历史记录
图 17. Auto Scaling Group 活动历史记录

我们列出目前的设定

  • 在 Auto Scaling Group 中 － 冷却时间: 120 秒、运作状态检查宽限期: 150 秒；
  • 在 目标追踪扩展政策中 － 暖机时间: 120 秒
  • CloudWatch － 监控周期: 60 秒
  • 实例启动时间 － 变动的

2020 九月 14, 01:37:19 下午 +08:00 － 触动 CloudWatch 警示，启动 1 个新实例， 主机从 1 > 2
2020 九月 14, 01:39:51 下午 +08:00 － 主机 2 启动完成，实例启动时间 2:32
2020 九月 14, 01:40:19 下午 +08:00 － 触动 CloudWatch 警示，启动 2 个新实例， 主机从 2 > 4
2020 九月 14, 01:42:50 下午 +08:00 － 主机 3 启动完成，实例启动时间 2:31
2020 九月 14, 01:43:18 下午 +08:00 － 触动 CloudWatch 警示，启动 4 个新实例， 主机从 4 > 8

从上面这些时间，我们可以发现每次触动 CloudWatch 警示的时间间隔是有规律的，约 3 分钟左右，这主要的影响因子是暖机时间跟实例启动时间。另外一个发现是启动主机数量是呈现倍数 1 > 2 > 4，这符合官方手册说明的方式：为了确保应用程序可用性，Auto Scaling Group 可以按比例快速地向外扩展到指标，但向内扩展时会比较平缓。

透过下图的 CloudWatch 仪表板，可以看出整个系统在 13:43 CPU使用率就下降为 0，依照 CloudWatch 警示的设定，应该会在 15 ~ 16分后开始进行向内扩展，观察活动历史记录可以发现以下数据，说明在时间上的确如此。接着我们观察关机时间，却发现比开机时间还长，约5 ~ 6 分钟，原因应该是受冷却时间与 Deregistration delay ，可以看图 19 ，在 Target group 中对于每个实体要解除这个目标群时，有个解除注册延迟( Deregistration delay )，预设的解除注册延迟为 300 秒，约 5 分钟。

2020 九月 14, 01:59:51 下午 +08:00 － 触动 CloudWatch 警示，关闭 1 个新实例
2020 九月 14, 02:05:36 下午 +08:00 － 关闭主机完成，关闭时间 5:45

CloudWatch 仪表板
图 18. CloudWatch 仪表板

Target group 设定
图 19. Target group 设定

References

  • Target tracking scaling policies for Amazon EC2 Auto Scaling, https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html

相关文章