文章目录
- 一.task1
- 1.1 手动实现
- 1.1.1创建两个安全组
- 1.1.2 测试
- 1.2代码自动控制
- 二. task2
主要介绍负载均衡相关
一.task1
填写目标代码,使其能够自动新增web server 以提供更高的的处理数据能力
1.1 手动实现
1.1.1创建两个安全组
LoadGenerator HTTP Sec Group 负载均衡服务器
webServer Group 服务器
使用cmu提供的两个AMI进行启动, 一个做负载均衡,一个做数据处理
安全组可以直接编辑入站出站规则 方便管理
1.1.2 测试
在LoadGenerator下 输入课程给的用户名密码 以及webServer的服务器DNS,即可开始进行测试
可以看到 随着webserver的增加, rps(每秒访问数)的上限也会增加, 也就是说负载的上限在进行增加。
1.2代码自动控制
task1的目标就是通过代码自动进行控制这一过程,自动增加web server以达到相应的rps。
使用python开源项目botto进行自动控制
二. task2
这个模块task要求使用aws的自动缩放群组
由loader服务器 —> 负载均衡器 ——> 目标群组 发送大量数据流, 要求调试集群,能够在efficiency和cost之间取得一个比较好的平衡。
在使用负载均衡的时候, 建一个新的scailing group。
在创建scailing group的时候要创建一个实例模板, 当要扩展的时候,就会自动以该模板进行新建实例。且会需要链接到一个elb，这个时候可以选择创建新的elb并创建新的target group。
在此项目中, 流量发送为 loader - > 负载均衡器 -> target grout
target group的控制交给 auto scaling group的Policy去做 而主要工作其实就是调试policy
关于scailing group和target group之间的联系
loadbalancer要去listen target group
ASG创建的时候需要一个launch configuration，说是configuration其实就是一个已经存在的实例, 传入instance_id就行，未来进行动态扩展就会往target group里加这个实例
在选择进行自动扩展的时候,选择simple policy由自己使用cloud watch对其进行自定义。
Target groups are just a group of Ec2 instances. Target groups are
closely associated with ELB and not ASG.ELB -> TG - > Group of Instances We can just use ELB and Target groups
to route requests to EC2 instances. With this setup, there is no
autoscaling which means instances cannot be added or removed when your
load increases/decreases.ELB -> TG - > ASG -> Group of Instances If you want autoscaling, you
can attach a TG to ASG which in turn gets associated to ELB. Now with
this setup, you get request routing and autoscaling together. Real
world usecases follow this pattern. If you detach the target group
from the Auto Scaling group, the instances are automatically
deregistered from the target group
之后便是配置ASG的过程
所需容量 是一开始就会达到的容量
最小容量 是当负载降低后嫩减少实例到的最低数量
最大容量 是负载增加所能达到的最大容量
