根据流量 (Traffic) 来进行负载平衡器 (Auto Scaling Group) 的运作

最新推荐文章于 2024-06-04 09:38:12 发布

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

最新推荐文章于 2024-06-04 09:38:12 发布

阅读量517

点赞数

分类专栏： AWS ELB 文章标签：云计算负载均衡 jmeter

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

版权

AWS 同时被 2 个专栏收录

22 篇文章 1 订阅

订阅专栏

ELB

6 篇文章 0 订阅

订阅专栏

根据流量 (Traffic) 来进行负载平衡器 (Auto Scaling Group) 的运作

今天主要要时做的是透过流量来进行 Auto Scaling Group，而流量我们以每一台实例的请求数量 (RequestCountPerTarget) 为警示的标准，扩展策略就使用 Step scaling policies ，下图为我们要实作的环境，为安全考虑我们将 Auto Scaling Group 放到私有子网，而 ELB 则是需要对外开放所以放在公有子网，考虑容错，所以跨两个可用区。

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

Aoto Scaling Group 建置

接下来的操作其实跟 ASG 步进缩放政策 Step 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

<center>
<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

透过浏览器确认功能无误，确认首页正常运行

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

Image name : ithomeAMI
Image description : ithome Web Server AMI

图 2. 新增 AMI

图 3. 输入 AMI 信息

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

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

图 4. 新增负载平衡器

我们选择 Application Load Balancer (ALB)

图 5. 选择 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)

图 6. 设定负载平衡器的涵盖范围

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

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

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

图 7. 设定负载平衡器安全组

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

Target group : New target group
Name : ithomeTargetGroup

图 8. 指定负载平衡器目标群

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

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

步骤 6. Review

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

图 10. 负载平衡器的内容

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

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

图 11. 建立启动组态

完成启动组态设定

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

图 12. 启动组态设定画面

新增 Auto Scaling Group

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

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

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

图 13. 选择启动组态

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

图 14. 网络组态设定

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

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

图 15. 负载平衡设定

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

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

扩展政策 - 选用
选择无

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

图 16. 设定群组大小和暂不设定扩展政策

步骤 5 (选用) 新增通知

没有设定

步骤 6 (选用) 新增标签

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

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

步骤 7. 检阅

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

设定步骤缩放政策 Step scaling policies

使用 Jmeter 产生流量

请参考如何透过 JMeter 产生流量并透过 CloudWatch 监控流量建立一个测试计划，底下简单描述操作步骤。
测试目标： ithomealb-1480018609.ap-southeast-1.elb.amazonaws.com
模拟使用者： 10 个使用者
请求频率： 1,000/minute

步骤 1. 新建 Thread Group
Jmeter 的所有任务都由线程来进行，所有任务都必须在线程组下面创建，在 AWS Test Plan 按左键。

图 18. 新建 Thread Group

线程数量 Number of Threads: 一个用户占一个线程， 10 个线程就是仿真 10 个用户
准备时长 Ramp-Up Period(in seconds): 设置线程需要多长时间全部启动。如果线程数为 10 ，准备时长为 10 ，那么需要1秒钟启动 1 个线程。
Loop Count: 每个线程发送请求的次数。如果线程数为 10 ，循环次数为 10 ，那么每个线程发送10次请求。总请求数为 10*10 = 100 。如果勾选了“永远”，那么所有线程会一直发送请求，直到选择停止运行脚本。

图 19. 设定 Thread Group

步骤 2. 新增 HTTP Request
我们是测试网页所以要建立 HTTP Request，在 线程群组1000 按左键，新增 > 取样 > HTTP要求。

图 20. 新增 HTTP Request

协定： HTTP
主机： ithomealb-1480018609.ap-southeast-1.elb.amazonaws.com

图 21. 设定 HTTP Request

步骤 3. 新增定时器
设定在固定时间内发出特定数量的请求，在 线程群组1000 按左键，新增 > 定时器 > 固定时隔。

图 22. 新增定时器

固定处理量定时器 Constant Throughput Timer：通过计算使总处理量（以每分钟计）尽可能接近给定的数字。当然，如果服务器不能处理它，或者如果其他定时器或耗时的测试原件阻止它，那么处理量将更低。作用在于控制吞吐量，要注意把定时器放在线程群组，并在请求的上面。

目标处理量 Target throughput（in samples per minute）: 1000
Calculate Throughput based on : all active threads in current thread group

图 23. 设定定时器

可以直接按下开始后就会执行测试计划。

建立 CloudWatch Alarm 警示

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

步骤 1. 指定指标和条件

指标值设定为 Singapore > 全部 > ApplicationELB > 每个 AppELB、每个 TG 指标 > RequestCountPerTarget
，要注意要确定看到上面的图型有数据才能确定已经正确找到指标值，因为有时候会有很多个 AppELB 实体，所以需要去找一下ALB ID确认一下

图 24. 设定 RequestCountPerTarget 指标值

因为需要知道 1 分钟内有多少个请求，所以需要把_统计数据_从平均数改成总和，期间 5 分钟改成 1 分钟。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-o5QPtADC-1603507374290)(https://ithelp.ithome.com.tw/upload/images/20200919/20129510OMsHQaSZgI.jpg)]
图 25. 设定 RequestCountPerTarget 图形化指针

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VzdivNTV-1603507374291)(https://ithelp.ithome.com.tw/upload/images/20200919/20129510Y9nelRce0J.jpg)]
图 26. CloudWatch Alarm 指定指标

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-I0agt9OS-1603507374293)(https://ithelp.ithome.com.tw/upload/images/20200919/20129510Thr1g0ZXu7.jpg)]
图 27. CloudWatch Alarm 指定条件

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

图 28. 移除 CloudWatch Alarm 预设通知动作

步骤 3. 新增名称和描述

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

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

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

阈值是每当 RequestCountPerTarget < 300
警示名称: ithomeRequestPerTargetInAlarm
警示描述 - 选用: ithome Step ScalingIn policy Alarm

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

图 29. 新增Auto Scaling Group的扩展政策

建立扩展政策

a. 扩展设定
政策类型: 步进扩展
扩展政策名称: ithomeRequestPerTargetOutPolicy
CloudWatch 警示: ithomeRequestPerTargetOutAlarm
采取行动: 新增
200 群组百分比 >=500
300 群组百分比 >=800
实例需求: 150 纳入指标之前的暖机秒数

b. 缩减设定
政策类型: 步进扩展
扩展政策名称: ithomeRequestPerTargetInPolicy
CloudWatch 警示: ithomeRequestPerTargetInAlarm
采取行动: 移除
50 群组百分比

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-w0CIQNRk-1603507374299)(https://ithelp.ithome.com.tw/upload/images/20200919/201295100EqE6oyqbP.jpg)]
图 30. 步进扩展政策扩展与缩减设定

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

透过 Jmeter 发出 1000 /每分及 3000 /每分的请求

图 31. CloudWatch CloudWatch 扩展警示

因为请求数拉的很快，所以启用的是步进扩展的第二个条件， RequestCountPerTarget >= 800 增加300%的目前群组百分比，从 2 -> 6

图 32. Auto Scaling Group 活动历史记录－扩展

关闭 Jmeter 的请求，可以发现整个请求数，马上从七百多直线下降

图 33. CloudWatch CloudWatch 缩减警示

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

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
根据流量 (Traffic) 来进行负载平衡器 (Auto Scaling Group) 的运作

根据流量 (Traffic) 来进行负载平衡器 (Auto Scaling Group) 的运作今天主要要时做的是透过流量来进行 Auto Scaling Group，而流量我们以每一台实例的请求数量 (RequestCountPerTarget) 为警示的标准，扩展策略就使用 Step scaling policies ，下图为...
复制链接

扫一扫