ELB
ELB的作用和特性
- 负载均衡器
- 通过负载均衡还可以提供HA
- 可以跨AZ转发
- 支持4层的TCP流量,和7层的http/https, ssl流量
- 提供一个CNAME入口
- 提供健康检查,保证不会将优良发往有问题的后端节点
ELB的种类
按照是否连接外网分为两种
- internal LB 内网LB
- internet facing LB 面向internet的LB
HTTPS 的负载均衡
- https 需要在ELB上配置ssl证书,这样ELB才能在中间成功的截断前端流量,再代理到后端。
- ELB不支持SNI,(server name indication) 所以如果需要在多个网站上使用一个证书的话,需要提供SAN(subject alternative name)
监听
每个监听器包的配置包含面向两个方向的4项
前端------协议/端口[监听器]协议/端口-------后端
最佳实践
- 使用DNS来表示服务,不用IP。因为DNS更加灵活。
配置LB的注意事项
关于超时
- ELB有一个默认的空闲超时时间。是60秒。但是如果连接的时间超过60秒,即使还有数据传输,依然会导致断开连接。如果有需要长时间传输的文件,最好把这个项目调大
- 如果有http/https的LB,建议在EC2的instances上打开keepalive选项,这样LB复用之前的HTTP的session,减少CPU负载
- 如果要确保LB会主动负责关闭和后端的连接,请保证EC2的keep alive 时间长于LB上的keep alive时间
关于跨AZ
Connection Draining
用于在后端节点出问题的时候,踢出负载均衡群。有一个参数可以一个节点出问题之后,LB依然在一定时间内保持连接。从1到3600秒,默认300秒。超过这个时间之后,LB会强制断开连接。
是保持已有的连接,但是不再产生新的连接,还是依然保持节点在群里?按照逻辑来说应该是前一个
代理
对于TCP和SSL,默认请求的包头在LB的过程中不会变化。但是如果开启Proxy Protocol,会在请求包里增加一个人可读的包头,包含原目IP端口等信息。
注意确认请求是否还会被其他的开启proxy protocol的节点处理。如果还有其他节点的话,请求会被加两层头部。可能导致后端服务正常处理请求
sticky session
对于有cookie之类的。类似与nginx的IP hash
健康检查
可以用
- ping
- connection attempt
- healthcheck page
CloudWatch
基础监控 VS 详细监控
基础监控 | 详细监控 |
---|---|
免费 | 收费 |
30分钟一采样 | 1分钟一采样 |
N/A | 可以聚合一个region内的数据 |
CloudWatch Logs
可以用来收集,存储和访问其他AWS资源产生的日志。类似于一个日志服务。也支持将日志文件按照生命周期,存储在不同类型的存储中。
通过CLoudWatch Logs Agent发送日志到AWS CloudWatch
Agent是一个可以安装的软件。可以安装到instance里面
限制项
项目 | 数量 |
---|---|
报警数量 | 5,000/账户 |
监控数据保存时间 | 默认写入后两周 |
AutoScaling
AutoScaling 计划
- 保持现有实例级别,保证健康实例数量不会下降
- 手动扩容
- 计划扩容
- 动态扩容,通过预设的规则进行自动的扩容。
AutoScaling 组件
Launch Configuration
用于创建新实例的模板。
默认的launch configurations 是每个region100个
AutoScaling Group
每个AutoScaling组都包含本组扩容的配置。什么时候扩容,什么时候杀掉实例
参数包括
- 最小实例数
- 最大实例数
- 需求容量(desired capacity)。既需要一直存在的实例的数量。如果不单独设定,这个值就是最小实例数。
如果最小实例数和需求容量数不一致,会有什么动作。