编辑应用程序负载均衡器的目标组属性 - Elastic Load Balancing
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

编辑应用程序负载均衡器的目标组属性

为应用程序负载均衡器创建目标组后,您可以编辑其目标组属性。

取消注册延迟

Elastic Load Balancing 停止将请求发送到正在取消注册的目标。默认情况下,Elastic Load Balancing 在取消注册过程完成前会等待 300 秒,这有助于完成针对目标的进行中的请求。要更改 Elastic Load Balancing 等待的时间,请更新取消注册延迟值。

取消注册的目标的初始状态为 draining。取消注册延迟结束后,取消注册过程完成,目标状态变为 unused。如果目标是 Auto Scaling 组的一部分,便可以将其终止或替换。

如果取消注册的目标没有进行中的请求且没有活动连接,则 Elastic Load Balancing 将立即完成取消注册过程,而不等待取消注册延迟结束。但是,即使目标注销已完成,目标的状态也会显示为 draining,直至注销延迟超时期限过期。超时期限过期后,目标转换为 unused 状态。

如果正在取消注册的目标在取消注册延迟结束前终止连接,客户端将收到 500 级错误响应。

使用控制台更新取消注册延迟值
  1. 打开 Amazon EC2 控制台,网址为https://console.aws.amazon.com/ec2/

  2. 在导航窗格上的负载均衡下,选择目标组

  3. 选择目标组的名称以打开其详细信息页面。

  4. 组详细信息选项卡的属性部分中,选择编辑

  5. 编辑属性页面上,根据需要更改注销延迟的值。

  6. 选择 Save changes(保存更改)

要更新取消注册延迟值,请使用 Amazon CLI

使用带有deregistration_delay.timeout_seconds属性的modify-target-group-attributes命令。

慢启动模式

默认情况下,目标只要注册到目标组并通过了初始运行状况检查,就会开始接收其完整的请求份额。使用慢启动模式可给目标时间进行预热,然后负载均衡器向其发送完整的请求份额。

为目标组启用慢启动后,当目标组认为其目标正常时,其目标会进入慢启动模式。慢启动模式下的目标在配置的慢启动持续时间过去或目标变得不正常时退出慢启动模式。负载均衡器线性增加它可以向慢启动模式下的目标发送的请求数量。在正常目标退出慢启动模式后,负载均衡器可以向它发送完整的请求份额。

注意事项
  • 为目标组启用慢启动之后,注册到目标组的正常目标不会进入慢启动模式。

  • 当您为空的目标组启用慢启动,然后使用单一注册操作注册目标时,这些目标不会进入慢启动模式。仅当至少有一个正常目标未处于慢启动模式时,新注册的目标才会进入慢启动模式。

  • 如果您在慢启动模式下取消注册目标,目标将退出慢启动模式。如果您再次注册同一目标,则当目标组认为该目标正常时,它将进入慢启动模式。

  • 如果处于慢启动模式的目标变得不正常,则该目标将退出慢启动模式。当目标变得正常时,它将再次进入慢启动模式。

  • 使用最少未完成的请求加权随机路由算法时,您无法启用慢启动模式。

使用控制台更新慢启动持续时间值
  1. 打开 Amazon EC2 控制台,网址为https://console.aws.amazon.com/ec2/

  2. 在导航窗格上的负载均衡下,选择目标组

  3. 选择目标组的名称以打开其详细信息页面。

  4. 组详细信息选项卡的属性部分中,选择编辑

  5. 编辑属性页面上,根据需要更改慢启动持续时间的值。要禁用慢启动模式,请将持续时间设置为 0。

  6. 选择 Save changes(保存更改)

要更新慢速启动持续时间值,请使用 Amazon CLI

使用带有slow_start.duration_seconds属性的modify-target-group-attributes命令。

应用程序负载均衡器目标组的跨区域负载均衡

负载均衡器的节点将来自客户端的请求分配给已注册目标。启用跨可用区负载均衡后,每个负载均衡器节点会在所有已注册可用区中的已注册目标之间分配流量。禁用跨可用区负载均衡后,每个负载均衡器节点会仅在其可用区中的已注册目标之间分配流量。这可能是因为可用区故障域优先于区域性故障域,从而确保运行状况良好可用区不受运行状况不佳可用区的影响,或者改善整体延迟。

对于应用程序负载均衡器,始终在负载均衡器级别启用跨可用区负载均衡,并且无法关闭。对于目标组,默认设置是使用负载均衡器设置,但您可以通过在目标组级别明确关闭跨可用区负载均衡来覆盖默认设置。

注意事项
  • 当跨可用区负载均衡关闭时,不支持目标粘性。

  • 当跨可用区负载均衡关闭时,不支持 Lambda 函数作为目标。

  • ModifyTargetGroupAttributesAPI如果有目标的参数AvailabilityZone设置为,则尝试通过关闭跨区域负载平衡会all导致错误。

  • 注册目标时,AvailabilityZone 参数是必需的。仅当跨可用区负载均衡关闭时,才允许特定可用区值。否则,该参数将被忽略并视为 all

最佳实践
  • 针对每个目标组,在您预期利用的所有可用区内规划足够的目标容量。如果无法为所有参与的可用区规划足够的容量,我们建议您继续启用跨可用区负载均衡。

  • 使用多个目标组配置应用程序负载均衡器时,请确保所有目标组都参与配置区域内的相同可用区。这是为了避免在跨区域负载平衡关闭时可用区为空,因为这会触发进入空可用区的所有HTTP请求的 503 错误。

  • 请避免创建空子网。应用程序负载均衡器通过公开空子网DNS的区域 IP 地址,这会触发 503 请求错误。HTTP

  • 在某些情况下,关闭了跨可用区负载均衡的目标组在每个可用区都有足够的计划目标容量,但可用区中的所有目标都变得不正常。如果至少有一个目标组的所有目标都不正常,则会从DNS中删除负载均衡器节点的 IP 地址。目标组拥有至少一个运行正常的目标后,IP 地址将恢复为DNS。

关闭跨可用区负载均衡

您可以随时对应用程序负载均衡器目标组关闭跨可用区负载均衡。

使用控制台关闭跨可用区负载均衡
  1. 打开 Amazon EC2 控制台,网址为https://console.aws.amazon.com/ec2/

  2. 在导航窗格上的 Load Balancing(负载均衡)下,选择 Target Groups(目标组)。

  3. 选择目标组的名称以打开其详细信息页面。

  4. Attributes(属性)选项卡上,选择 Edit(编辑)。

  5. Edit target group attributes(编辑目标组属性)页面上,为 Cross-zone load balancing(跨可用区负载均衡)选择 Off(关闭)。

  6. 选择 Save changes(保存更改)

要关闭跨区域负载均衡,请使用 Amazon CLI

使用modify-target-group-attributes命令并将load_balancing.cross_zone.enabled属性设置为false

aws elbv2 modify-target-group-attributes --target-group-arn my-targetgroup-arn --attributes Key=load_balancing.cross_zone.enabled,Value=false

以下为响应示例:

{ "Attributes": [ { "Key": "load_balancing.cross_zone.enabled", "Value": "false" }, ] }

启用跨可用区负载均衡

您可以随时对应用程序负载均衡器目标组启用跨可用区负载均衡。目标组级别的跨可用区负载均衡设置会覆盖负载均衡器级别的设置。

使用控制台启用跨可用区负载均衡
  1. 打开 Amazon EC2 控制台,网址为https://console.aws.amazon.com/ec2/

  2. 在导航窗格上的 Load Balancing(负载均衡)下,选择 Target Groups(目标组)。

  3. 选择目标组的名称以打开其详细信息页面。

  4. Attributes(属性)选项卡上,选择 Edit(编辑)。

  5. Edit target group attributes(编辑目标组属性)页面上,为 Cross-zone load balancing(跨可用区负载均衡)选择 On(打开)。

  6. 选择 Save changes(保存更改)

要启用跨区域负载均衡,请使用 Amazon CLI

使用modify-target-group-attributes命令并将load_balancing.cross_zone.enabled属性设置为true

aws elbv2 modify-target-group-attributes --target-group-arn my-targetgroup-arn --attributes Key=load_balancing.cross_zone.enabled,Value=true

以下为响应示例:

{ "Attributes": [ { "Key": "load_balancing.cross_zone.enabled", "Value": "true" }, ] }

自动目标权重 (ATW)

Automation Target Weights (ATW) 持续监控运行应用程序的目标,检测明显的性能偏差,即异常。ATW提供了通过实时数据异常检测动态调整路由到目标的流量的能力。

自动目标权重 (ATW) 会自动对您账户中的每个 Application Load Balancer 执行异常检测。识别出异常目标后,ATW可以自动尝试通过减少其路由的流量来稳定它们,这被称为异常缓解。ATW持续优化流量分布,以最大限度地提高每个目标的成功率,同时最大限度地降低目标组的失败率。

注意事项:
  • 异常检测目前监视来自目标的 HTTP 5xx 响应代码以及与目标的连接故障。异常检测始终处于开启状态,无法关闭。

  • ATW使用 Lambda 作为目标时不支持。

异常检测

ATW异常检测会监视任何表现出与目标组中其他目标行为明显偏差的目标。这些偏差称为异常,通过比较一个目标的百分比误差与目标组中其他目标的百分比误差来确定。这些错误既可以是连接错误,也可以是HTTP错误代码。报告值明显高于对等目标的目标则被视为异常。

异常检测要求目标组中至少有三个运行状况良好的目标。当目标注册到目标组时,它必须首先通过运行状况检查才能开始接收流量。目标接收目标后,ATW开始监视目标并持续发布异常结果。对于没有异常的目标,异常结果为 normal。对于存在异常的目标,异常结果为 anomalous

ATW异常检测独立于目标群体的健康检查。目标可以通过所有目标组运行状况检查,但仍会因错误率升高而被标记为异常。目标变为异常不会影响其目标组运行状况检查状态。

异常检测状态

ATW持续发布其对目标执行的异常检测的状态。您可以使用 Amazon Web Services Management Console 或随时查看当前状态 Amazon CLI。

使用控制台查看异常检测状态
  1. 打开 Amazon EC2 控制台,网址为https://console.aws.amazon.com/ec2/

  2. 在导航窗格上的负载均衡下,选择目标组

  3. 选择目标组的名称以打开其详细信息页面。

  4. 在目标组详细信息页面上,选择目标选项卡。

  5. 已注册目标表中,您可以在异常检测结果列中查看每个目标的异常状态。

    如果未检测到异常,则结果为 normal

    如果检测到异常,则结果为 anomalous

要查看异常检测结果,请使用 Amazon CLI

使用Include.member.N属性值设置为的describe-target-health命令AnomalyDetection

异常缓解

重要

的异常缓解功能ATW仅在使用加权随机路由算法时可用。

ATW异常缓解会自动将流量从异常目标上移开,从而使他们有机会恢复。

缓解期间:
  • ATW定期调整路由到异常目标的流量量。目前,周期为每五秒一次。

  • ATW将路由到异常目标的流量减少到执行异常缓解所需的最低量。

  • 不再被检测为异常的目标将逐渐获得更多路由到它们的流量,直到它们达到与目标组中其他正常目标的同等水平。

开启ATW异常缓解功能

您可以随时启用异常缓解。

使用控制台启用异常缓解
  1. 打开 Amazon EC2 控制台,网址为https://console.aws.amazon.com/ec2/

  2. 在导航窗格上的负载均衡下,选择目标组

  3. 选择目标组的名称以打开其详细信息页面。

  4. 在目标组详细信息页面的属性选项卡上,选择编辑

  5. 编辑目标组属性页面上的流量配置部分的负载平衡算法下,确保选中加权随机

    注意:当最初选择加权随机算法时,异常检测默认处于开启状态。

  6. 异常缓解下,确保选中启用异常缓解

  7. 选择 Save changes(保存更改)

要开启异常缓解功能,请使用 Amazon CLI

使用带有load_balancing.algorithm.anomaly_mitigation属性的modify-target-group-attributes命令。

异常缓解状态

无论ATW何时对目标执行缓解,都可以使用 Amazon Web Services Management Console 或随时查看当前状态 Amazon CLI。

使用控制台查看异常缓解状态
  1. 打开 Amazon EC2 控制台,网址为https://console.aws.amazon.com/ec2/

  2. 在导航窗格上的负载均衡下,选择目标组

  3. 选择目标组的名称以打开其详细信息页面。

  4. 在目标组详细信息页面上,选择目标选项卡。

  5. 已注册目标表中,您可以在有效缓解列中查看每个目标的异常缓解状态。

    如果缓解未在进行中,则状态为 yes

    如果缓解正在进行中,则状态为 no

要查看异常缓解状态,请使用 Amazon CLI

使用Include.member.N属性值设置为的describe-target-health命令AnomalyDetection

Application Load Balancer 的粘性会话

默认情况下,Application Load Balancer 会根据选定负载均衡算法将每项请求单独路由到已注册的目标。但是,您可以使用粘性会话功能(也称为会话关联),使负载均衡器能够将用户会话绑定到特定的目标。这可确保在会话期间将来自用户的所有请求发送到同一目标中。对于维护状态信息以便向客户端提供持续体验的服务器来说,此功能很有用。要使用粘性会话,客户端必须支持 Cookie。

Application Load Balancer 支持基于持续时间的 Cookie 和基于应用程序的 Cookie。粘性会话会在目标组级别启用。您可以在目标组中组合使用基于持续时间的粘性、基于应用程序的粘性以及非粘性。

管理粘性会话的关键是确定负载均衡器一致地将用户请求路由到同一目标的时间长短。如果您的应用程序拥有自己的会话 Cookie,则可以使用基于应用程序的粘性,且负载均衡器会话 Cookie 将会遵循应用程序会话 Cookie 指定的持续时间。如果您的应用程序没有自己的会话 Cookie,则可以使用基于持续时间的粘性来生成具有您指定持续时间的负载均衡器会话 Cookie。

负载均衡器生成的 Cookie 内容使用轮换密钥加密。您无法解密或修改负载均衡器生成的 Cookie。

对于这两种粘性类型,Application Load Balancer 将重置每次请求后生成的 Cookie 的过期期限。如果 Cookie 过期,会话将不再具有粘性,客户端应该从 Cookie 存放区删除 Cookie。

要求
  • HTTP/负HTTPS载均衡器。

  • 每个可用区内至少有一个运行状况良好的实例。

注意事项
  • 如果跨可用区负载均衡禁用,则不支持粘滞会话。禁用跨可用区负载均衡时尝试启用粘滞会话将失败。

  • 对于基于应用程序的 Cookie,每个目标组必须单独指定 Cookie 名称。但是,对于基于持续时间的 Cookie,所有目标组将使用 AWSALB 作为唯一的名称。

  • 如果您使用的是多层 Application Load Balancer,则可以使用基于应用程序的 Cookie 在所有层启用粘性会话。但是,如果使用基于持续时间的 Cookie,您就只能在一个层上启用粘性会话,因为 AWSALB 是唯一可用的名称。

  • 如果应用程序负载均衡器同时收到 AWSALBCORSAWSALB 基于持续时间的粘性 Cookie,则 AWSALBCORS 中的值将优先。

  • 基于应用程序的粘性不能与加权目标组结合使用。

  • 如果您具有一个包含多个目标组的转发操作,并且一个或多个目标组已启用了粘性会话,则必须在目标组级别启用粘性。

  • WebSocket 连接本质上是粘性的。如果客户端请求升级连接 WebSockets,则返回 HTTP 101 状态码以接受连接升级的目标就是 WebSockets连接中使用的目标。 WebSockets 升级完成后,将不使用基于 Cookie 的粘性。

  • Application Load Balancer 使用 Cookie 标头中的 Expires 属性而不是 Max-Age 属性。

  • 应用程序负载均衡器不支持URL编码的 Cookie 值。

基于持续时间的粘性

基于持续时间的粘性使用负载均衡器生成的 Cookie (AWSALB) 将请求路由到目标组中的同一目标。Cookie 用于将会话映射到目标。如果您的应用程序没有自己的会话 Cookie,您可以指定自己的粘性持续时间,并管理负载均衡器一致地将用户请求路由到同一目标的时间长短。

当负载均衡器第一次收到来自客户端的请求时,它会(根据选定算法)将请求路由到目标并生成名为 AWSALB 的 Cookie。它还会对选定目标的有关信息进行编码,加密 Cookie,并在对客户端的响应中包含 Cookie。负载平衡器生成的 Cookie 具有自身的 7 天到期时间,且不可配置。

在后续请求中,客户端应包含 AWSALB Cookie。当负载均衡器收到来自包含 Cookie 的客户端的请求时,它会检测到该请求并将请求路由到同一目标。如果 cookie 存在但无法解码,或者它指的是已取消注册或不正常的目标,则负载均衡器会选择一个新目标并使用有关新目标的信息更新 cookie。

对于跨域资源共享 (CORS) 请求,某些浏览器SameSite=None; Secure需要启用粘性。为了支持这些浏览器,负载均衡器始终会生成第二个粘性 Cookie AWSALBCORS(其中包含与原始粘性 Cookie 相同的信息)和 SameSite 属性。客户会收到两个 Cookie,包括非CORS请求。

使用控制台启用基于持续时间的粘性
  1. 打开 Amazon EC2 控制台,网址为https://console.aws.amazon.com/ec2/

  2. 在导航窗格上的负载均衡下,选择目标组

  3. 选择目标组的名称以打开其详细信息页面。

  4. 组详细信息选项卡的属性部分中,选择编辑

  5. Edit attributes 页上,执行以下操作:

    1. 选择粘性

    2. 对于 Stickiness type(Stickiness 类型),请选择 Load balancer generated cookie(负载均衡器生成的 Cookie)。

    3. 对于 Stickiness duration,指定一个介于 1 秒和 7 天之间的值。

    4. 选择 Save changes(保存更改)

要启用基于持续时间的粘性,请使用 Amazon CLI

使用带有stickiness.enabledstickiness.lb_cookie.duration_seconds属性的modify-target-group-attributes命令。

使用以下命令启用基于持续时间的粘性。

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.lb_cookie.duration_seconds,Value=time-in-seconds

您的输出应类似于以下示例。

{ "Attributes": [ ... { "Key": "stickiness.enabled", "Value": "true" }, { "Key": "stickiness.lb_cookie.duration_seconds", "Value": "86500" }, ... ] }

基于应用程序的粘性

基于应用程序的粘性可以让您灵活地为客户端目标粘性设置自己的标准。启用基于应用程序的粘性时,负载均衡器会根据选定算法将第一个请求路由到目标组内的目标。为启用粘性,目标应设置与负载均衡器上配置的 Cookie 匹配的自定义应用程序 Cookie。此自定义 Cookie 可包含应用程序所需的任何 Cookie 属性。

当 Application Load Balancer 收到来自目标的自定义应用程序 Cookie 时,它会自动生成新加密的应用程序 Cookie,以捕获粘性信息。此负载均衡器生成的应用程序 Cookie 可为每个启用基于应用程序的粘性的目标组捕获粘性信息。

负载均衡器生成的应用程序 Cookie 不会复制目标设置的自定义 Cookie 的属性。它自己的过期期限为 7 天,这是不可配置的。在对客户端的响应中,Application Load Balancer 仅验证在目标组级别配置的自定义 Cookie 的名称,而不验证自定义 Cookie 的值或过期属性。只要名称匹配,负载均衡器即会发送 Cookie、目标设置的自定义 Cookie 以及负载均衡器生成的应用程序 Cookie,来响应客户端。

在后续请求中,客户端必须将两个 Cookie 发送回以保持粘性。负载均衡器会解密应用程序 Cookie,并检查配置的粘性持续时间是否仍然有效。然后,它将使用 Cookie 中的信息将请求发送到目标组中的同一目标,以保持粘性。负载均衡器还会将自定义应用程序 Cookie 代理到目标,而不检查或修改它。在后续响应中,会对在负载均衡器上配置的负载均衡器生成的应用程序 Cookie 的到期期限和粘性持续时间进行重置。为了保持客户端和目标之间的粘性,Cookie 的到期期限和粘性持续时间不会消失。

如果目标失败或者目标运行状况不佳,负载均衡器会停止将请求路由到该目标,并根据选定负载均衡算法来选择新的运行状况良好的目标。现在,负载均衡器将会话视为正在“附加”到新的正常运行目标,并继续将请求路由至新的正常运行目标,即使之前失败的目标已恢复正常运行。

对于跨源资源共享 (CORS) 请求,为了实现粘性,仅当用户代理版本为 Chromium80 或更高版本时,负载均衡器才会将SameSite=None; Secure属性添加到负载均衡器生成的应用程序 Cookie 中。

由于大多数浏览器将 Cookie 的大小限制为 4K,因此负载均衡器会将大于 4K 的应用程序 Cookie 分片为多个 Cookie。Application Load Balancer 支持最大 16K 的 Cookie,因此最多可以创建 4 个分片发送给客户端。客户端看到的应用程序 Cookie 名称以 “AWSALBAPP-” 开头,并包含一个片段编号。例如,如果 Cookie 大小为 0-4K,则客户端会看到 AWSALBAPP -0。如果 cookie 大小为 4-8k,则客户端会看到 AWSALBAPP -0 和- AWSALBAPP 1,依此类推。

使用控制台启用基于应用程序的粘性
  1. 打开 Amazon EC2 控制台,网址为https://console.aws.amazon.com/ec2/

  2. 在导航窗格上的负载均衡下,选择目标组

  3. 选择目标组的名称以打开其详细信息页面。

  4. 组详细信息选项卡的属性部分中,选择编辑

  5. Edit attributes 页上,执行以下操作:

    1. 选择粘性

    2. 对于 Stickiness type(Stickiness 类型),请选择 Application-based cookie(基于应用程序的 Cookie)。

    3. 对于 Stickiness duration,指定一个介于 1 秒和 7 天之间的值。

    4. 对于 App cookie name(应用程序 Cookie 名称),请输入基于应用程序的 Cookie 名称。

      请勿使用 AWSALBAWSALBAPP、或 AWSALBTG 作为 Cookie 名称;它们将保留以供负载均衡器使用。

    5. 选择 Save changes(保存更改)

要启用基于应用程序的粘性,请使用 Amazon CLI

使用具有以下属性的modify-target-group-attributes命令:

  • stickiness.enabled

  • stickiness.type

  • stickiness.app_cookie.cookie_name

  • stickiness.app_cookie.duration_seconds

使用以下命令启用基于应用程序的粘性。

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.type,Value=app_cookie Key=stickiness.app_cookie.cookie_name,Value=my-cookie-name Key=stickiness.app_cookie.duration_seconds,Value=time-in-seconds

您的输出应类似于以下示例。

{ "Attributes": [ ... { "Key": "stickiness.enabled", "Value": "true" }, { "Key": "stickiness.app_cookie.cookie_name", "Value": "MyCookie" }, { "Key": "stickiness.type", "Value": "app_cookie" }, { "Key": "stickiness.app_cookie.duration_seconds", "Value": "86500" }, ... ] }
手动再平衡

向上扩展时,如果目标数量大幅度增加,则可能由于粘性而导致负载分配不均。在这种情况下,您可以使用以下两种方式再平衡目标上的负载:

  • 将应用程序生成的 Cookie 过期期限设置在当前日期和时间之前。这样可以防止客户端将 Cookie 发送到 Application Load Balancer,从而重新启动建立粘性的过程。

  • 对负载均衡器基于应用程序的粘性配置设置非常短的持续时间,例如 1 秒。这样将强制 Application Load Balancer 重新建立粘性,即使目标设置的 Cookie 尚未过期。