构建弹性架构组件—ELB和ASG
1 ELB负载均衡器
-
纵向扩展：提高实例本身的硬件配置，使其提高性能以处理更多的并发访问
-
横向扩展：采用更多的同类型同配置的实例来共同处理用户的访问，在前面再使用一个负载均衡器以保证用户访问的是同一个接口同时提供健康检查
-
特征：
- ELB自动将进站的流量分发到多个目标，包括EC2、容器、ip地址、Lambda功能组件等等
- 使用ELB可以增加系统高可用性和可扩展性
- 提供统一的访问节点，并支持在同一地区不同AZ的目标
- 使用监听器来监听进站流量请求
- ELB对注册的目标进行健康检查，并保证只将流量导向健康的目标，当其中一台实例down后，ELB会将该实例从组中删除，当其恢复后，再将其加入组中
- 支持SSL/TSL协议，对网络流量进行加密（https）
- 本身是高可用的，对单个LB的SLA承诺可用性达到99.99%；ELB本身就是一个绝对高可用，永不宕机的分布式软件，用户不需要考虑ELB的高可用性，不需要为其设计高可用的架构设计。而且ELB不是单点故障
- ELB具有弹性，能自动对自身进行性能的提升，即可以理解为ELB能处理无穷无尽的数据请求。扩容的过程需要一定的时间（1到7分钟）
- 能和AWS弹性伸缩（Auto Scaling）集成，从而能保证后台运行的EC2实例能满足流量的需求
- 默认情况下，ELB的流量转发规则是 TCP 侦听器使用轮询路由（Round Robin）算法，对 HTTP 和 HTTPS 侦听器使用最少未完成请求路由算法。
- ELB只在一个特定的AWS区域中工作，不能跨区域（Region），但可以跨可用区（AZs）
-
类型：
- 应用负载均衡器：新版本第二代的LB，运行在OSI模型第七层；它使用目标组来转发流量请求；它支持http、https、SNI（客户端在请求ssl证书时，会把hose放在sni变量中，如此就可以允许多个网站存放在同一个ip地址里面）、http2等协议；支持基于url的路径转发功能（通过用户的url决定转发到那个目标组中）；支持基于http头部的主机名称转发功能；支持容器化应用；在应用程序负载均衡器中，引入了规则这个概念。ELB在收到请求之后，会按照优先顺序评估侦听器的规则，然后根据定义的规则将流量转发到特定的目标组中
- 网络负载均衡器：新版本的LB，运行在OSI模型的第四层；支持tcp、udp和tls协议；具有处理每秒百万请求的能力；支持容器化的应用；NLB可以基于协议、源 IP 地址、源端口、目标 IP 地址、目标端口和 TCP 序列号，使用流式哈希算法选择目标。
- 经典负载均衡器：是传统的第一代LB，其主要是为了实现和第一代的EB2-Classic网络兼容；它支持http/https和TCP网络流量（一般不考也很少用）
2 ELB创建
- 首先创建实例，在第三步的subnet处选择2b区域，在user data处安装并配置httpd服务并在其默认发布目录下放入两个发布页面，在第六步安全组处允许22和80端口访问；再做同样的配置分别在2a和2c区域再建立实例；这三台实例作为后端的目标组来处理客户端的流量
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable --now httpd
avzone=`curl http://169.254.169.254/latest/meta-data/placement/availability-zone`
echo "<html><h1>welcome to visit my web server at <font color="red">$avzone</font></h1></html>" > /var/www/html/index.html
echo "i am alive" > /var/www/html/health.html
-
创建完成后，在浏览器处访问处于2b区域的实例，输入ip，此时就可以看到发布页面的内容；再ip后面再加/health.html就可以访问到该健康页面
-
在EC2页面的左侧导航栏处找到load balancers ，点击create load balancer ，进入后有三种不同类型的负载均衡器可供选择，此处选应用型负载均衡器，进入后自定义名称；在scheme处选择第一个 internel-facing，表示面向互联网的；ip 就选择4；下面的listeners处表示要监听的端口，此处默认已经有了 http-80；在下面的av-zone处，将三个区域的实例都选中；到第三步安全组配置时，创建一个新的安全组，自定义名称，此处只保留80端口即可；第四步创建目标组 在name处自定义名称，type处选择实例，在health checks处的path处将创建好的健康页面写入【/health.html】，在健康检查设置处，将healthy threshold改为2，表示当2次没有回应就认为down，将 unhealthy threshold 改为2，表示2次成功后就恢复到目标组里，timeout改为2，表示两次没有回应就是down，interval改为5，表示每次检查间隔时间；第五步，将三个实例都选中，点击 add to registered 进行注册；最后点击create
- 此时负载均衡器就创建完成了，选中该负载均衡器就可以在下面看到其详细信息，将其dns名称复制，这就是用户访问时的节点，用户直接在浏览器输入该名称就可以访问到后端实例了，此时使用浏览器刷新，可以看到其是被均衡调度的
3 ELB健康检查
-
使用命令行的方式任意登录到其中一台实例上，
sudo -s，使用root身份，cd /var/www/html/ls，此时可以看到 index和health页面，将health页面修改，mv health.html unhealthy.html，此时去访问其health页面是无法找到的，那么此时其页面找不到，就会将该实例的状态定义为unhealthy（可以再target group页面的targets中看到其状态），此时在输入dns访问实例，此时负载已经没有down掉的那一台了，只有其他两台做负载；将其文件恢复后，检测到就会将其再自动加入目标组中，进行轮询
-
为了保证安全，可以创建一个安全组，在左侧导航栏找到安全组没进入后点击创建，自定义名称，add rule 【http ，在source处将创建负载均衡器时所使用的的安全组设为源】即可；进入ec2界面，将所有实例，点击actions–> 安全–>change security group -->选择刚才创建的安全组。此时无法直接通过ip地址去访问，只能通过域名访问，达到保护安全的作用
4 ELB会话保持
- 粘性会话：是用于将请求转发到目标组中的同一目标的机制，对于需要维护状态信息以便向客户端提供持续体验的服务器比较有用。该机制要求客户端必须支持cookies
- 流程：在初次收到客户端请求时，负载均衡器使用一个cookie并把它回应给客户端。客户端会将该cookie放在后续的请求中，一旦负载均衡器检测到该cookie就会将请求转发到相同的目标上。该功能由应用及经典负载均衡器支持
- 实验：
-
在EC2的管理界面，左侧导航栏处的target groups处，进入其属性并编辑 ，点击进入，在弹出的页面中有一个stickness，选中enable，在显示出的框中输入会话保持的时间，可以输入30秒方便观察实验效果，保存即可
-
此时刷新浏览器，会默认在同一台实例上，直到会话保持的时间过去，再刷新，其访问的实例就会发生改变。
-
5 EC2 ASG自动扩展组
- 概念：能自动地增加/减少EC2实例的数量，从而让你的应用程序一直能保持可用的状态。
- 启动配置：是弹性伸缩组用来启动EC2实例的时候所使用的模板，启动配置包含了镜像文件（AMI），实例类型、密钥对、安全组和挂载的存储设备；一个启动配置可以关联多个Auto Scaling组；启动配置一经创建不能被更改，只能删除重建
- 特点：
- 自动扩展确保有正确数量的实例来应付应用负载
- 更好的容错能力，高可用性和成本管理
- 无附加费用，用户只需要支付使用到的实例和负载均衡器
- 总是维持当前实例级别（例如组中总的有两个实例，如果一台实例故障，就会自动根据配置末模板再配置一个实例添加到组中）
- 手动扩展（自动改变组中实例多少）
- 日程计划扩展（定义某个时间段进行自动的扩展）
- 动态扩展（按照负载情况）
- 实验：
-
进入EC2的管理界面，使用前面已经创建好的组和负载均衡器，注意在目标组界面的最下面处，点击 edit attribute ，将 deregistration delay 修改为30，表示当目标组中有实例故障后，只需要等待30秒的时间，就会去创建一个新的实例加入进来。注意如果上面的实验中，没有将会话保持取消记得要取消
-
在左侧导航栏，选则启动模板 ，点击create。第一步选择 Amazon linux 2 AMI 的镜像，第二步选择实例类型如下。第三步输入自定义名称，IAM role指定为none，在user data处写入上面实验相同的脚本，其他默认即可；在第五步安全组处选择已存在的安全组，开放80和22端口的；最后完成创建即可
-
点击左侧导航Auto scaling，选中其子菜单 auto scaling，点击create进入，进入后选择刚才自己创建的configuration进入第一步，自定义名称，group size 选择1表示从一个实例开始，在subnet处将三个av-zone的子网都选择。点击展开 advanced details，选中load balancing后面的框，将其展开的目标组选择为之前创建好的目标组，在health check grace period 处将实例热身启动的时间设置为60秒（注意如果实例中需要启动的服务比较多，该时间可以给的长一些，以保证实例中的服务正常开启），其他默认；
-
进入左侧导航栏的 instance界面，在这里可以看到自动创建的实例；进入左侧导航栏的 load balances 复制其dns，然后去浏览器访问是可以的。从左侧导航栏进入 target group 的 targets中可以看到自动创建的实例已经加入到了目标组
-
在左侧导航栏的instances中将该实例terminate，此时再回到 Auto scaling group中观察，可以看到会自动的再创建一台实例
-
6 EC2 ASG扩展策略
-
手动扩展
-
进入ASG的管理界面，在actions–>edit ，将Max改为3台，desired capacity 修改为2台（希望有的台数），然后保存
-
此时在下面的 activity history 处就可以看到变化，看到又添加了一台实例到目标组中。也就是算上前面的实验，现在目标组中一共有两台自动添加的实例，我们可以去浏览器访问域名，可以看到两台实例时均衡被调度的
-
再次进入ASG的管理界面，在actions–>edit ，将desired capacity 修改为1台，然后保存
-
此时在下面的 activity history 处就可以看到变化，会自动的结束一台实例。此时再去浏览器访问会看到只有一台实例被调度
-
-
创建 scaling policies
-
在ASG页面下面的scaling polices处，点击 add policy ，这里policy会有三种不同的规则。点开后默认的第一种规则处的 metric type 可以选择一些参数，ASG会自动的去跟踪这些参数；第二种是创建简单的policy规则，该方式是可以选择参数的阈值，当达到阈值后就会增加或收缩实例的数量同时也会产生告警信息；第三种是在第二种的基础上添加一些步骤，也就是在达到多少的阈值后会添加新的policy，变成以步骤的方式进行。
-
点击 add policy ，创建第一张默认的跟踪目标组方式的policy。自定义名称、metric type 处选择 average cpu u……，表示当cpu的使用达到阈值后、target value 为50，表示当cpu的使用达到百分之50时会创建的新的实例，当低于50时，会将多余的实例终止。点击保存
-
此时使用命令行的方式登录到当前的一台实例上，输入
sudo -syes > /dev/null &，此时该命令就会使得cpu产生负载，此时输入top会查看到cpu的使用情况一定是大于50的 -
此时可以看到ASG界面正在创建新的实例，而且自动将期望实例个数从1调整为3。等三台实例都为运行状态后，去浏览器上刷新访问就会自动实现负载，因为它检测到需要在再添加两台实例才能达到cpu的使用率下降到50以下
-
此时进入命令行，输入
pkill yes，将产生负载的命令删除，此时再输入top可以看到cpu的使用率下降至50以下 -
此时再去ASG界面，可以看到自动将两台实例停止。在去浏览器访问就可以看到只有一台实例被调度
-
-
注意：实验完成后，将ASG删除，删除后，实例会被自动删除。将负载均衡器删除