ASG 步进缩放政策 Step scaling policies

最新推荐文章于 2024-07-11 09:35:51 发布

常信-人工智能名师工作室

最新推荐文章于 2024-07-11 09:35:51 发布

阅读量148

点赞数

分类专栏： AWS 文章标签：云计算负载均衡服务器

原文链接：https://blog.csdn.net/m0_50614038/article/details/109184662?spm=1001.2014.3001.5501

版权

AWS 专栏收录该内容

22 篇文章 1 订阅

订阅专栏

ASG 步进缩放政策 Step scaling policies

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

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

Aoto Scaling Group 建置

接下来的操作其实跟 ASG 目标跟踪缩放政策 Target tracking scaling policies 笔记类似，可以参照该网址，但为方便起见我们还是操作一遍

建置 VPC 与相关的子网 - 请参阅 Amazon VPC 实操。
新增 EC2 实例 - 请参阅 Amazon Elastic Compute Cloud (EC2) 笔记。
新增 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>

 
 
 
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

产生 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” />”;

$KaTeX parse error: Can't use function '\'' in math mode at position 34: …stat 1 2 | awk \̲'̲{ for (i=1; i&l…$ i==“id”) { getline; getline; print $i }}’’);

if ($idleCpu > 50) {

echo exec('dd if=/dev/zero bs=100M count=500 | gzip | gzip -d  &gt; /dev/null &amp;');
echo "Generating CPU Load! (auto refresh in 5 seconds)";

}
else {
echo “Under High CPU Load! (auto refresh in 5 seconds)”;
}
echo “ Current CPU Load: ”;
echo 100-$idleCpu;
echo “%”;
?>

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

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

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

Image name : ithomeAMI
Image description : ithome Web Server AMI

图 3、新增 AMI

图 4、输入 AMI 信息

新增 Application Load Balancer (ALB) - 主要就是完成负载平衡的工作，可以分担流量以及容错。

进入 EC2 控制台，在左手选单下方选择负载平衡器，并在右边按下 Create Load Balancer

图 5、新增负载平衡器

我们选择 Application Load Balancer (ALB)

图 6、选择 Application Load Balancer

接下来需要六个步骤来设定 ALB
步骤 1. Configure Load Balancer : 建议先看一下图一，可以发现负载平衡器会跨越两个可用区，因为唯有如此才能完成高可用性的设定，所以除了设定名字外，记得选择 VPC (PS:一个区域可以有多个 VPC )以及可用区

Name : ithomeALB
Availability Zones
VPC : vpc-0bb7004b67556d0da (172.16.0.0/16) | ithomeVPC
Availability Zones
ap-southeast-1a: subnet-0f1df807467b642f6 (ithome public subnet 1)
ap-southeast-1b: subnet-06f56dccb2a9cfcf0 (ithome public subnet 2)

图 7、设定负载平衡器的涵盖范围

步骤 2. Configure Security Settings : 没有设定

步骤 3. Configure Security Groups : 设定安全组，选择先前设定的安全组，跟原来的 EC2 实例一样

Assign a security group: Select an existing security group
_ithome_web_SG _

图 8、设定负载平衡器安全组

步骤 4. Configure Routing : 设定要将收到的流量转给哪个对象，因为 AWS 会将这些对象设定成一个目标群 (Traget Group) ，所以我们先指定一个目标群，到后面再来设定这个目标群的内容

Target group : New target group
Name : ithomeTargetGroup

图 9、指定负载平衡器目标群

步骤 5. Register Targets : 不要指定目标群的内容，因为目标群的实例将会由 Auto Scaling Group 静态或动态产生，如下图

图 10、负载平衡器目标群内容不指定

步骤 6. Review

完成设定后，记得在回到负载平衡器得主画面，这时候就可以看到刚刚建立的负载平衡器，这时候就可以直接复制 DNS Name 的字段，如下图，当作是网址，直接读取网页，但请注意，要等一段时间，因为 DNS 注册需要一段时间，所以可能要等五分钟后， DNS 的 TTL 到期后会再去抓取的时候，这时候网页才会正常。

图 11、负载平衡器的内容

新增 Launch Configuration - 主要是提供 Auto Scaling Group 启动实例的模板，用来设定目标群内的 EC2 实例的启动组态

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

图 12、建立启动组态

完成启动组态设定

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

图 13、启动组态设定画面

新增 Auto Scaling Group

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

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

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

图 14、选择启动组态

步骤 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

图 15、网络组态设定

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

负载平衡
勾选 启用负载平衡
_Application Load Balancer _
为您的负载平衡器选择目标组 : ithomeTargetGroup
运作状态检查 - 选用
运作状态检查类型 : 勾选 EC2 和 ELB
运作状态检查宽限期 : 150 秒
其他设定 - 选用
监控 : 勾选 在 CloudWatch 中启用群组指针集合

图 16、负载平衡设定

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

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

扩展政策 - 选用
选择无

等一下自行设定步骤缩放政策 Step scaling policies，所以现在先选无

图 17、设定群组大小和暂不设定扩展政策

步骤 5 (选用) 新增通知

没有设定

步骤 6 (选用) 新增标签

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

图 18、设定新启动的 EC2 实例的名称

步骤 7. 检阅

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

设定步骤缩放政策 Step scaling policies

建立 CloudWatch Dashboard 仪表板
按下上方的服务按钮，选择 CloudWatch ，进入 CloudWatch 控制台后，按下右方功能选单仪表板，按下建立仪表板后，输入要观察的衡量指针值－服务的实体总数 (GroupInServiceInstances), CPU 使用率 (CPUUtilization)。

仪表板名称： ithomeSimplePolicyDashboard

图 19、建立 CloudWatch 仪表板画面

图 20、设定 CloudWatch 仪表板中 Widget 类型

Widget 的数据源选择指标值 (Metrics)

图 21、设定 Widget 的数据源

指标值设定为 Singapore > 全部 > Auto Scaling > GroupInServiceInstances，要注意要确定看到上面的图型有数据才能确定已经正确找到指标值

设定哪一个指标值
图 22、设定 GroupInServiceInstances 指标值

指标值设定为 Singapore > 全部 > EC2 > 依照 Auto Scaling 群组 > CPUUtilization

设定哪一个指标值
图 23、设定 CPUUtilization 指标值

设定完毕后，务必记得储存 CloudWatch 仪表板。

图 24、完成 CloudWatch 仪表板设定

建立 CloudWatch Alarm 警示

在 CloudWatch 控制台，按下右方功能选单警示，按下建立警示后，我们建立两个警示一个是新增实例 (Scale out)，阈值是 CPU 使用率 > 60%，一个是减少实例 (Scale In)，阈值是 CPU 使用率 < 30%。建立指标有四个步骤，分别如下：

步骤 1. 指定指标和条件
指定指标的设定方式跟内容跟仪表板一样，唯一需要注意的是期间预设是5分钟，记得改成 1 分钟。

图 25、CloudWatch Alarm 指定指标

条件
阈值类型 : 静态
每当 CPUUtilization 为 : 大于 > 阈值
定义阈值 : 60
要发出警示的数据点 : 1 出于 1 # 这个意思是第一个 1 是得到的数据数，第二个 1 是采样数据的次数，举例来说，如果设定 1 出于 2，表示采样 2 次，只要有一次的 CPUUtilization > 60%，就会发出警示

图 26、CloudWatch Alarm 指定条件

步骤 2. 设定动作
记得移除预设的通知动作，不移除的话也可以，要指定 email 以及到指定的 email 去订阅 SNS (Simple Notification Service) 主题。

图 27、移除 CloudWatch Alarm 预设通知动作

步骤 3. 新增名称和描述

警示名称: ithomeStepScalingOutAlarm
警示描述 - 选用: ithome Step ScalingOut policy Alarm

步骤 4. 预览并建立
再次确认资料是否正确

相同方法在建立另一个警示

阈值是 CPU 使用率 < 30%
警示名称: ithomeStepScalingInAlarm
警示描述 - 选用: ithome Step ScalingIn policy Alarm

建立 Auto Scaling Group 扩展政策
按下上方的服务按钮，选择 EC2 ，进入 EC2 控制台后，按下右方功能选单Auto Scaling Groups，按下刚刚建立的ithomeACG，按下方页签的自动调整规模后，在扩展政策中选择新增政策

图 28、新增Auto Scaling Group的扩展政策

建立扩展政策
政策类型: 步进扩展
扩展政策名称: ithomeStepOutPolicy
CloudWatch 警示: ithomeStepScalingOutAlarm
采取行动: 新增
200 群组百分比
实例需求: 150 纳入指标之前的暖机秒数

图 29、步进扩展政策扩展设定

建立扩展政策
政策类型: 步进扩展
扩展政策名称: ithomeStepInPolicy
CloudWatch 警示: ithomeStepScalingInAlarm
采取行动: 移除
50 群组百分比
实例需求: 150 纳入指标之前的暖机秒数

图 30、步进扩展政策缩减设定

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

我们列出目前的设定

在 Auto Scaling Group 中－冷却时间: 300 秒、运作状态检查宽限期: 150 秒；
在步进扩展政策中－暖机时间: 150 秒
步进扩展政策扩展设定－ CPUUtilization > 60%，新增 200% 的目前容量，举例说目前有 1 台实例，那会再启动 2 台实例
步进扩展政策缩减设定－ CPUUtilization < 30%，移除 50% 的目前容量，举例说目前有 10 台实例，那会移除 5 台实例
CloudWatch 警示设定为适用于 1 分钟内的 1 数据点，也就是只要检查到 1 次就立刻触发扩缩政策
CloudWatch －监控周期: 60 秒
Target groups － Deregistration delay: 120 seconds
实例启动时间－变动的

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

图 31、Auto Scaling Group 活动历史记录－扩展

根据 CloudWatch 仪表板的观察，整个 CPU 使用率在 14:05分下降到 30% 以下，所以应该会在 1~2 分钟左右触发缩减设定，以下两张图说明整个步进扩展政策的执行状况，很明显的使用步进扩展的效能要求以及成本考虑，都比目标追踪扩展政策来的好。

图 32、CloudWatch 仪表板

图 33、Auto Scaling Group 活动历史记录－缩减

步进扩展政策

从实际拉高 CPU 使用率，到扩展到群组最大上限 10 的时间为 13:52 -> 14:04 ~ 12 minutes
发出 CloudWatch 缩减警示，到缩减到群组最小下限 1 的时间为 14:07 -> 14:21 ~ 14 minutes

目标追踪扩展政策

从实际拉高 CPU 使用率，到扩展到群组最大上限 10 的时间为 13:33 -> 13:56 ~ 23 minutes
发出 CloudWatch 缩减警示，到缩减到群组最小下限 1 的时间为 13:43 -> 14:14 ~ 31 minutes

References

Step and simple scaling policies for Amazon EC2 Auto Scaling, https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html#as-step-scaling-warmup
减到群组最小下限 1 的时间为 14:07 -> 14:21 ~ 14 minutes

目标追踪扩展政策

从实际拉高 CPU 使用率，到扩展到群组最大上限 10 的时间为 13:33 -> 13:56 ~ 23 minutes
发出 CloudWatch 缩减警示，到缩减到群组最小下限 1 的时间为 13:43 -> 14:14 ~ 31 minutes

References

Step and simple scaling policies for Amazon EC2 Auto Scaling, https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html#as-step-scaling-warmup

常信-人工智能名师工作室

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
ASG 步进缩放政策 Step scaling policies

ASG 步进缩放政策 Step scaling policies 今天详细介绍 Auto Scaling Group 的 Step scaling policies，下图为我们要实作的环境，为安全考虑我们将 Auto Scaling Group 放到私有子网，而 ELB 则是需要对外开放所以放在公有子网，考虑容错，所以跨两个可用区。...
复制链接

扫一扫