aws-弹性负载均衡器：ELB, ALB, NLB, CLB（aws负载均衡器原理）

aws-弹性负载均衡器：ELB, ALB, NLB, CLB（aws负载均衡器原理）

弹性负载均衡器是aws HA的非常重要的对多台云服务器进行流量分发的服务。负载均衡可以通过流量分发扩展应用系统对外的服务能力，通过消除单点故障提升应用系统的可用性。

提高可用性和访问速度，在单个可用区或多个可用区内的多个目标之间自动分配流量。运行状况检查，检测无法正常运行的目标、停止向它们发送流量，然后将负载分散到剩余的正常运行的目标上。安全性功能，创建和管理与负载均衡器关联的安全组，以提供更多联网和安全选项。TLS 终止，提供集成化证书管理和 SSL/TLS 解密，可以灵活地集中管理负载均衡器的 SSL 设置，并从应用程序上卸载 CPU 密集型工作。ELB是第一道防线（比如DDoS）ELB只在一个特定的AWS区域中工作，不能跨区域（Region），但可以跨可用区（AZs）默认情况下，ELB的流量转发规则是 TCP 侦听器使用轮询路由（Round Robin）算法，对HTTP 和 HTTPS 侦听器使用最少未完成请求路由算法（LOR）。通过此算法，当新请求传入时，负载均衡器会将其发送到未完成请求数最少的目标。处理长期请求或处理能力较低的目标不会担负更多的请求，负载均匀地分布在各个目标上。这也有助于新目标有效地减少过载目标的负载。

DNS解析

​​ELB会以DNS (Domain Name System)的形式显示在AWS管理控制台，并且会动态解析不同公网IP地址，我们在使用ELB时要尽量用DNS来对它进行访问，而不是IP地址​在ELB进行弹性扩容的时候，它的DNS记录会被更新，DNS会解析到新的IP地址上（因此这也是上面所说的我们要尽量用DNS名来访问ELB）​DNS记录的TTL时间是60秒​建议客户端（程序）每60秒更新DNS查找记录，以获取最新的ELB地址和最好的ELB性能​

健康检查（Health Check)

ELB在每一个健康检查间隔（HealthCheck Interval）都会向所有已注册的实例发送基于Ping、端口或者（网页）路径的检查数据包，并且在响应超时（Response Timeout）这个时间内等待实例的回复。如果连续没有得到回复的次数超过定义的不健康阈值（Unhealthy Threshold），那么这个实例会被标记为OutofService。如果在连续得到实例回复的次数超过了健康阈值（Healthy Threshold）的话，那么这个实例会被重新标记为Inservice状态。

监听器（Listeners）

Listeners可以用来监听用户对ELB发起的请求，以及ELB和后台EC2实例之间的请求Listeners可以定义监听的协议和端口Listeners支持HTTP, HTTPS, SSL, TCP协议

连接耗尽（Connection Draining）

默认情况下，一个已注册再ELB的EC2实例取消了注册或者进入OutofService状态，那么ELB会马上切断这个实例正在进行的连接。

为了保证Classic Load Balancer中当有实例变成不健康的状态（OutofService）或者正在取消注册，而该实例上已经建立的连接不受影响， 请启用Connection Draining功能。它能保证该不健康的实例在处理完所有已有的连接请求之后，才真正地从ELB内去除，接着ELB不会再转发请求给这个实例。

Connection Draining的可设置时间限制范围是1~3600秒（默认为300秒）。当达到这个最大时限时，不管当前实例是否处理完请求，ELB都会强制关闭与这个实例的连接。

粘性会话/会话关联（Sticky Sessions/Session Affinity）

默认情况下，Classic Load Balancer会将每一个用户请求转发到负载最小的已注册实例上。但是如果启用Sticky Sessions /Session Affinity，则在会话期间ELB会将来自某个用户的所有请求都转发到同一个实例上。

Classic Load Balancer

CLB 也可以叫做 AWS 第一代负载均衡器，是一款比较早的负载均衡器，同时支持 4 层( TCP/SSL ) 和 7 层( HTTP/HTTPS )。 使用 CLB 而不是 ALB 具有以下优势：

支持 EC2-Classic支持 TCP 和 SSL 侦听器支持使用应用程序生成的 cookie 的粘性会话CLB 的价格比较便宜，CLB速度慢于ALB

建议：不推荐继续使用 CLB ，如果能够将业务迁移到 ALB 或者 NLB，建议使用新一代的负载均衡器。

Application Load Balancer

ALB 属于 AWS 对于上一代负载均衡器的改进版，正如 ALB 的名字：应用程序负载均衡器，ALB只支持7层负载均衡( HTTP / HTTPS / WebSocket )，不支持 4 层( TCP/UDP )负载均衡。ALB于2016年8月发布。

ALB 相比 CLB 做了很多改进，如 ALB 的性能更好，支持基于 Host 和 Path 的转发，甚至支持 URL Redirect，后端支持 Target Group ，可以将不同的组件放在不同的 TargetGroup 中，更易于管理。当客户的业务基于 HTTP/Websocket 的时候，要优先考虑使用 ALB。面向交付包括微服务和基于容器的应用程序在内的现代应用程序架构，提供高级请求路由功能。Application Load Balancer 通过确保始终使用最新的 SSL/TLS 密码和协议，简化并提高应用程序的安全性。

优势：支持基于Host和Path的转发；支持粘性会话；性能比CLB好；支持按比例的流量转发；可编辑安全组

Network Load Balancer

NLB 是一个 4 层 TCP/UDP 负载均衡器，也是 AWS 提供唯一一个支持UDP流量的托管的负载均衡器。NLB 的性能非常好，每秒可以处理百万次请求，而不需要进行预热，NLB的IP地址也不会发生变化，所以在一些场景下，NLB 更受客户的青睐。

虽然 NLB 也可以处理 7 层的流量，但是 NLB 不解析 7 层的协议，不会对协议进行任何处理。比如通过 NLB 转发 HTTP/Websocket 流量，所以对于错误的客户端请求，也需要转发到后端由后端的服务器处理，而 ALB 则会将错误的请求直接拒绝掉，不会再转发给后端，从这个角度看 ALB 更适合用来承担 HTTP/Websocket 流量。

网络负载均衡器还经过了优化，能够处理突发的和不稳定的流量模式，同时在每个可用区使用单个静态 IP 地址。它与其他流行的 AWS 服务集成，例如 Auto Scaling、Amazon EC2 Container Service (ECS)、Amazon CloudFormation 和 Amazon AWS Certificate Manager (ACM)。

负载均衡器节点基于协议、源 IP 地址、源端口、目标 IP 地址、目标端口和 TCP 序列号，使用流式哈希算法选择目标。来自客户端的 TCP 连接具有不同的源端口和序列号，可以路由到不同的目标。每个单独的 TCP 连接在连接的有效期内路由到单个目标。

优势：性能最好，每秒支持百万次请求，不需要预热（ALB和CLB流量大的话需要预热扩充负债均衡服务节点）；NLB的ip地址不会改变（CLB和ALB会随着时间改变，另外NLB可以分配固定弹性ip，ALB不能）

Network Load Balancing 为您启用的每个可用区创建一个网络接口。可用区内的每个负载均衡器节点使用该网络接口来获取一个静态 IP 地址。

高度可扩展且低延迟

NLB 在微秒级别提供非常低的延迟，这对于像 Ad Tech 和 IoT 等对延迟敏感的行业客户极为重要。此外，它还可以按需扩展以负载平衡数百万请求/秒。

Route-53 的 DNS 故障转移

如果您的应用程序没有响应，Route 53 将从服务中删除不可用的 NLB 端点，并将流量引导到另一个区域中的备用负载均衡器。同样，如果没有向负载均衡器注册健康的 EC2 实例，或者给定区域中的负载均衡器节点不健康，则 Route-53 会将流量定向到其他可用区中的负载均衡器节点。NLB 可以和 Route 53 结合，无论是该区域的 NLB 下面没有健康的主机，还是该区域的 NLB 发生故障，Route53 都会负责将流量导向其他的 AZ。（Route 53 目前仅由其他全球区域提供服务）

同可用区内分发流量

客户端的流量到达 NLB 在某个可用区提供的 IP 后，NLB 会向相同可用区内的后端实例分发流量，通过避免跨可用区的流量分发能够获得更好的延迟性能。注意：默认情况下 NLB 只会转发给当前添加 AZ 的后端实例，如果需要跨 AZ 转发，需要打开“ Cross-Zone Load Balancing ”的功能。

保留客户端源IP地址

当后端应用程序或服务收到流量时，NLB 会保留客户端源 IP（无需任何自定义标头）。然后，客户可以使用它进行进一步处理。 NLB 会保持客户端的源 IP，不会对通过的数据包做处理。

固定IP支持

NLB 允许客户为负载均衡器分配每个可用区（子网）的弹性 IP，为其提供固定的 IP 功能。如此设计使得 NLB 能够被纳入企业现有的防火墙安全策略中，并且能够避免 DNS 缓存带来的问题。

与 AWS 服务集成

NLB 可轻松与其他 AWS 服务集成，如 Amazon Elastic Container Service（ECS），AWS CloudFormation 和 AWS Elastic BeanStalk。

支持 TCP 长连接

NLB 支持 TCP 长连接，即使是在 NLB 的扩展期间或更新期间也不会断开资源连接，从而能更好地支持包括 IoT、游戏、消息应用等在内的业务场景。

NLB 支持与 Application Load Balancer 相同的资源，其中包括 Listeners、Targets、TargetGroups 和规则。与 Application Load Balancer 不同，规则不会基于内容。NLB 和 ALB 一样支持 Target Group 的配置方式。

兼容所有现在 ELB 的 API

我们将使用与 Application Load Balancer 相同的底层 API。您可以通过调用 elbv2 create-load-balancer API，使用 AWS CLI 创建网络负载均衡器。

支持容器化的应用程序。

计划任务时，Amazon Elastic Container Service（Amazon ECS）可以选择一个未使用的端口，并可以使用此端口向目标组注册该任务。这样可以高效地使用您的群集。

支持单独监控每个服务的运行状况

因为运行状况检查是在目标组级别定义的，而且许多 Amazon CloudWatch 指标也是在目标组级别报告的。将目标组挂载到 Auto Scaling 组的功能使您能够根据需求动态扩展每个服务。

ELB 预热

对于秒杀/抢购类场景，由于是瞬间流量突增，根据流量弹性缓慢扩容来不及处理这么大的流量，有可能还没有扩容完成，秒杀活动就已经结束。因此需要想办法在活动开始之前，就将 ELB 的节点提前预置好，这个过程就叫做 ELB 预热 ( pre-warm )。

只有 CLB 和 ALB 需要进行预热，NLB 提供了固定的 IP 地址，无需预热。在做 ELB 预热的时候，需要客户提供活动的开始时间以及结束时间，以及大概每秒由多少个请求，每个请求多大，是否使用 SSL 和 KeepAlive 等信息，后台团队会根据客户提供的信息来判断给客户预置多少个节点。由于后端团队在国外，在处理速度上会有时差，一般建议客户在活动开始前 5 个工作日提交预热请求。预热的申请可以直接开 Case 给 AWS Support 团队，即使没有订阅付费的 AWS Support 也会受理此请求。

ELB 与 ICP 备案

ELB 作为一个弹性的负载均衡器，会随着流量的变化而增加/删除节点IP地址，所以在客户申请 ICP 备案之前，需要做额外的操作。

NLB 的 IP 地址是固定的，因此可以直接拿 NLB 进行备案，在创建 NLB 的时候，也可以使用 EIP，这样即使不小心将 NLB 删除，也可以使用原来的 EIP 关联到新的 NLB 上，无需重新备案。在 CLB / ALB 申请固定 IP 之后，后台会给一组 IP 地址，IP 地址数目不确定，会根据客户流量大小而有所差异。客户当前可能只使用了这一组 IP 地址中的部分，但一定要将所有的 IP 地址都拿去备案。（可以联系Aws技术支持团队）

如何获取客户端源 IP 地址

一些应用程序（例如，ELB、Web 应用程序防火墙、反向代理、入侵防御系统以及 API Gateway）会将转发请求的 CloudFront 边缘服务器的 IP 地址附加到 X-Forwarded-For 标头的末尾。例如，如果 CloudFront 将 X-Forwarded-For: 192.0.2.2 包含在它转发给 ELB 的请求中，并且 CloudFront 边缘服务器的 IP 地址为 192.0.2.199，则 EC2 实例收到的请求将包含以下标头：

X-Forwarded-For: 192.0.2.2,192.0.2.199

ELB负载不均衡如何处理

ELB 节点负载不均衡

可以启用ELB访问日志，然后观察每一个 ELB 节点收到的请求数，如果发现某一个(些)节点的请求数明显高于/低于其他节点，那么说明 ELB 节点负载不均衡。出现这个情况往往是客户端 DNS 解析有问题或者客户端写死了 ELB 的 IP 地址，导致客户端只向某一个 ELB 节点发请求。要从客户端那边解决问题，比如更新一下客户端 app 或者更新客户端的 dns。

后端实例接收到的请求负载不均衡

跨可用区负载均衡

跨可用区负载均衡的默认状态：ALB 默认启用；NLB 默认禁用；CLB 使用 API 或 CLI 时默认禁用，使用管理控制台时默认启用。

ELB 负载均衡算法

· CLB HTTP Listener 负载均衡算法：最少未处理完成的请求数(注意：并非最少连接数) ；CLB TCP Listener 负载均衡算法：轮询

· ALB 负载均衡算法：先根据 Listener 的 rule 优先级决定路由到哪个 TargetGroup ，然后再 TargetGroup 上可以指定负载均衡算法：轮询或最少未处理完成请求数，默认 TargetGroup 使用轮询算法。

· NLB 负载均衡算法: 使用流哈希(协议/源 IP /源端口/目标 IP /目标端口/ TCP 序列号)选择目标。

ELB如何匹配mobile/pc端的站点

在cloudfront通过user-agent来判断，ELB写正则表达式有些麻烦；或者通过应用程序端来判断。

ELB查问题通用思路

如果客户订阅了AWS Support，建议联系 Support处理；如果没有，可以尝试从以下几个方面排查问题：

检查ELB后端实例是否都是 healthy针对 Internet-Facing ELB , 检查创建 ELB 时所选择的子网是否都是公有子网，即子网路由是否都对 0.0.0.0/0 流量路由到了 igw检查客户端 DNS 解析，是否能正确解析到 ELB 的 IP 地址，是否存在不正确的 DNS 缓存分别在客户端和 EC2 后端实例抓包，观察数据包是否发给后端实例，以及后端实例是否正常响应客户端请求

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。