外部应用负载均衡器故障切换

本页介绍外部应用负载均衡器故障切换的工作原理。故障切换配置涉及两个负载均衡器：主负载均衡器和备用负载均衡器。在本讨论中，主负载均衡器是您要为其配置故障切换的负载均衡器。备用负载均衡器是在主负载均衡器开始无法通过健康检查时接收连接的负载均衡器。

故障切换和故障恢复是将流量路由到负载均衡器和从负载均衡器路由流量的自动过程。当 Cloud DNS 检测到服务中断并将流量从主负载均衡器路由到备用负载均衡器时，相应过程称为“故障切换”。当 Cloud DNS 反转此操作并将流量重定向到主负载均衡器时，相应过程称为“故障恢复”。

故障切换的工作原理

外部应用负载均衡器的全球到区域级故障切换的处理方式是在您希望将流量故障切换到的区域中创建两个或更多区域级外部应用负载均衡器。只有区域级外部应用负载均衡器可用作备用负载均衡器。区域级外部应用负载均衡器不仅在各个 Google Cloud 区域内独立运行，而且与同一区域中运行的任何全球外部应用负载均衡器或传统应用负载均衡器基础架构隔离。

区域级外部应用负载均衡器最适合用作全球外部应用负载均衡器的故障切换负载均衡器，因为它们都基于 Envoy 代理，并且处理流量的方式非常相似。这与传统应用负载均衡器截然不同，后者在流量处理方式方面存在明显差异。

总的来说，支持以下故障切换场景：

从全球外部应用负载均衡器到区域级外部应用负载均衡器
从区域级外部应用负载均衡器到区域级外部应用负载均衡器
从传统应用负载均衡器到区域级外部应用负载均衡器

故障切换和故障恢复工作流

以下设置演示了如何从一个全球外部应用负载均衡器故障切换到两个区域级外部应用负载均衡器（全球负载均衡器在其中部署了后端的每个区域中各一个）。

以下部分介绍了故障切换配置中涉及的不同组件的典型工作流。

检测主负载均衡器中的故障

Google Cloud 使用健康检查来检测主外部应用负载均衡器是否健康状况良好。您可以将这些健康检查配置为从三个来源区域发送探测。这三个来源区域必须代表客户端将从中访问负载均衡器的区域。例如，如果您有一个全球外部应用负载均衡器，并且大多数客户端流量来自北美和欧洲，则可以配置来自北美的两个区域和欧洲的一个区域的探测。

如果来自其中两个或更多区域的健康检查失败，系统会触发到备用区域级外部应用负载均衡器的故障切换。

补充说明：
- 在创建健康检查时，您必须正好指定三个来源区域。只有全球健康检查才能指定来源区域。
- 支持 HTTP、HTTPS 和 TCP 健康检查。
- 健康检查探测实际上来自互联网上与已配置的 Google Cloud 来源区域相距不远的入网点 (PoP)。
将流量路由到备用负载均衡器

如果主负载均衡器开始无法通过健康检查，Google Cloud 会使用 Cloud DNS 故障切换路由政策来确定如何将流量路由到备用负载均衡器。

服务中断的时长（或者流量从主负载均衡器故障切换到备用负载均衡器所需的时间）取决于 DNS TTL 值、健康检查间隔时间以及健康检查的健康状况不佳阈值。如需了解推荐的设置，请参阅最佳实践。
故障恢复到主负载均衡器

再次开始通过健康检查后，系统会自动故障恢复到主负载均衡器。由于备用负载均衡器和主负载均衡器都会处理流量，因此在故障恢复期间预计不会出现任何停机时间。
定期测试故障切换

我们建议您定期测试故障切换工作流，以此作为业务连续性计划的一部分。请确保测试从主负载均衡器到备用负载均衡器的流量逐步转移和瞬时转移。验证故障切换是否正常运行后，触发故障恢复以验证流量是否按预期重新路由回主负载均衡器。

配置故障切换

如需配置故障切换，请执行以下步骤：

查看现有的主负载均衡器配置，并检查主负载均衡器使用的功能（例如安全功能、流量管理和路由功能以及 CDN）是否可与备用区域级外部应用负载均衡器搭配使用。如果没有类似功能可用，则此负载均衡器可能不适合进行故障切换。
创建备用区域级外部应用负载均衡器，其配置应尽可能镜像主负载均衡器。
创建健康检查和 DNS 路由政策以检测服务中断情况，并在故障切换期间将流量从主负载均衡器路由到备用负载均衡器。

查看主负载均衡器配置

在开始之前，请验证备用区域级外部应用负载均衡器是否支持当前与主负载均衡器搭配使用的所有功能。

如需避免流量中断，请查看以下差异：

GKE 部署。GKE 用户应注意，与使用 GKE Ingress 控制器部署的负载均衡器相比，使用 GKE 网关部署的负载均衡器与此故障切换机制更兼容。这是因为 GKE 网关支持配置全球和区域级外部应用负载均衡器。但是，GKE Ingress 控制器仅支持传统应用负载均衡器。

如需获得最佳结果，请使用 GKE 网关部署主负载均衡器和备用负载均衡器。
Cloud CDN。区域级外部应用负载均衡器不支持 Cloud CDN。因此，如果发生故障，依赖于 Cloud CDN 的所有操作也会受到影响。如需提高冗余性，我们建议配置可用作 Cloud CDN 后备的第三方 CDN 解决方案。
Google Cloud Armor。如果您为主负载均衡器使用 Google Cloud Armor，请确保在配置备用区域级外部应用负载均衡器时也配置相同的 Google Cloud Armor 功能。Google Cloud Armor 在区域范围和全球范围内提供的功能有所不同。如需了解详情，请参阅 Google Cloud Armor 文档中的以下部分：
- 区域级 Google Cloud Armor 安全政策
- 全球 Google Cloud Armor 安全政策
SSL 证书。如果您想为主负载均衡器和备用负载均衡器使用通用 SSL 证书，请确认与主负载均衡器搭配使用的 SSL 证书类型与备用区域级外部应用负载均衡器兼容。请查看可与全球负载均衡器、区域级负载均衡器和传统负载均衡器搭配使用的 SSL 证书之间的差异。如需了解详情，请参阅以下各部分：
- Compute Engine SSL 证书
- Certificate Manager SSL 证书
后端存储桶。区域级外部应用负载均衡器不支持将 Cloud Storage 存储桶用作后端。您无法使用后端存储桶为负载均衡器设置故障切换。

配置备用负载均衡器

备用负载均衡器是希望在发生故障时将流量重定向到的区域中配置的区域级外部应用负载均衡器。

配置备用负载均衡器时，请注意以下注意事项：

您必须将备用区域级外部应用负载均衡器的功能配置为与主负载均衡器尽可能相似，以便在两个部署中以类似方式处理流量。
- 全球外部应用负载均衡器。区域级外部应用负载均衡器支持与全球外部应用负载均衡器相同的大多数功能，但有一些例外情况。区域级负载均衡器还支持与全球负载均衡器相同的高级流量管理功能，这有助于更轻松地在主负载均衡器和备用负载均衡器之间实现等效。
- 传统应用负载均衡器。使用传统应用负载均衡器时，主负载均衡器和备用负载均衡器之间更难实现对等的功能，因为区域级外部应用负载均衡器是一种基于 Envoy 的负载均衡器，以不同的方式处理流量。请确保在部署到生产环境之前全面测试故障切换和故障恢复。
如需查看区域级应用负载均衡器、全球应用负载均衡器和传统应用负载均衡器的具体功能，请参阅“负载均衡器功能比较”页面。

我们建议您使用 Terraform 等自动化框架，以帮助在主部署和备用部署之间实现并维护负载均衡器配置的一致性。
我们建议您在具有后端的每个区域中都设置备用区域级外部应用负载均衡器。例如，如果您从在五个区域中具有实例组的全球部署故障切换到仅处于三个区域中的备用区域级负载均衡器，则可能会导致这三个区域中的后端服务过载，而其余两个区域中的后端服务处于空闲状态。

此外，我们建议您配置 Cloud DNS，以便在将故障切换流量从主全球负载均衡器重新路由到这些备用区域级负载均衡器时使用加权轮循政策。通过考虑不同区域中后端实例组的大小上限，为每个备用负载均衡器分配权重。
区域级外部应用负载均衡器支持 Network Service Tiers 高级层级和标准层级。如果延迟时间不是您在故障切换期间的主要问题，我们建议您使用标准层级设置备用区域级外部应用负载均衡器。使用标准层级基础架构可进一步与全球外部应用负载均衡器使用的高级层级基础架构隔离。
如果要为主负载均衡器和备用负载均衡器使用相同的后端，请在后端所在的区域中创建备用区域级外部应用负载均衡器。如果您为后端实例组启用了自动扩缩功能，则必须满足跨部署共享后端的要求。
如果需要，请为区域级外部应用负载均衡器预留额外的 Envoy 代理，以帮助确保在发生故障切换事件时，额外的流量不会中断同一区域中的任何其他负载均衡器部署。如需了解详情，请参阅预留额外的代理专用子网容量。

如需了解如何配置区域级外部应用负载均衡器，请参阅使用虚拟机实例组后端设置区域级外部应用负载均衡器。

预留额外的代理专用子网容量

一个区域和 VPC 网络中的所有基于 Envoy 的区域级负载均衡器都共享同一个 Envoy 代理池。在故障切换事件中，备用区域级外部应用负载均衡器的代理使用量会增加，以处理来自主负载均衡器的故障切换流量。如需确保备用负载均衡器始终有足够的容量可用，我们建议您检查代理专用子网的大小。我们建议您计算在指定区域中处理流量所需的代理数量估算值，并根据需要增加容量。这还有助于确保故障切换事件不会中断同一区域和网络中的其他基于 Envoy 的区域级负载均衡器。

通常，一个区域级外部应用负载均衡器代理最多可管理：

每秒 600 个 (HTTP) 或 150 个 (HTTPS) 新连接
3000 个活跃连接
每秒 1,400 个请求

如果您使用 DNS 政策在不同区域中的多个备用负载均衡器之间拆分流量，则必须在估算每个区域和网络的代理要求时考虑到这一点。较大的代理专用子网使 Google Cloud 在必要时可以向负载均衡器分配较多的 Envoy 代理。

扩展代理专用子网的方式与扩展主要地址范围的方式不同（使用 expand-ip-range 命令）。您必须创建满足您需求的备用代理专用子网，然后将其提升为活跃角色。

如需了解如何更改代理专用子网的大小，请参阅更改代理专用子网的大小或地址范围。

在主负载均衡器和备用负载均衡器之间共享后端

如需实现完整的基础架构冗余，您必须同时在负载均衡器级层和后端级层引入冗余。这意味着您必须使用与主负载均衡器不重叠的后端（实例组或网络端点组）配置备用区域级外部应用负载均衡器。

但是，如果您的确想要在主负载均衡器和辅助负载均衡器之间共享后端实例组，并且为实例组启用了自动扩缩，则必须满足以下要求，以帮助确保执行适当的故障切换：

必须使用多个信号设置自动扩缩器。我们建议您为实例组结合使用 CPU 扩缩信号和负载均衡器利用率信号。
全球后端服务和区域级后端服务都必须仅使用 UTILIZATION 均衡模式。不建议使用 RATE 均衡模式，因为在故障切换过程中，您的实例可能会同时从全球负载均衡器和区域级负载均衡器接收 2 倍的流量。
必须配置缩容控制机制，以防止自动扩缩器在流量从全球负载均衡器切换到区域级负载均衡器的停机时间内过早地对组进行缩容。此停机时间可以高达 DNS TTL 与配置的健康检查时间间隔之和。

如果未正确设置自动扩缩，可能会导致在故障切换期间发生次要服务中断，因为全球负载均衡器流量损失会导致实例组快速缩减。

配置 Cloud DNS 和健康检查

本部分介绍如何使用 Cloud DNS 和 Google Cloud 健康检查配置 Cloud Load Balancing 环境，以检测服务中断并将流量路由到备用负载均衡器。

请按照以下步骤配置所需的健康检查和路由政策：

为主负载均衡器的转发规则 IP 地址创建健康检查。
```
gcloud beta compute health-checks create http HEALTH_CHECK_NAME \
    --global \
    --source-regions=SOURCE_REGION_1,SOURCE_REGION_2,SOURCE_REGION_3 \
    --use-serving-port \
    --check-interval=HEALTH_CHECK_INTERVAL \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --request-path=REQUEST_PATH
```
替换以下内容：
- HEALTH_CHECK_NAME：健康检查的名称
- SOURCE_REGION：在其中执行健康检查的三个 Google Cloud 区域。您必须正好指定三个来源区域。
- HEALTH_CHECK_INTERVAL：从一个探测器发出的一次探测开始到同一探测器发出的下一次探测开始之间的时间量（以秒为单位）。支持的最小值为 30 秒。如需了解建议的值，请参阅最佳实践。
- HEALTHY_THRESHOLD 和 UNHEALTHY_THRESHOLD：虚拟机实例被视为健康状况良好或健康状况不佳时必须成功或失败的连续探测次数。如果省略了其中任何一项，Google Cloud 使用的默认阈值为 2。
- REQUEST_PATH：Google Cloud 要向其发送健康检查探测请求的网址路径。如果省略，Google Cloud 会将探测请求发送到根路径 /。如果要进行健康检查的端点是专用端点（这对于外部转发规则 IP 地址来说并不常见），您可以将此路径设置为 /afhealthz。
在 Cloud DNS 中创建 Cloud DNS 记录集，并对其应用路由政策。路由政策必须配置为将您的域名解析为主负载均衡器的转发规则 IP 地址，或是在健康检查失败时解析为备用负载均衡器的转发规则 IP 地址之一。
```
gcloud beta dns record-sets create DNS_RECORD_SET_NAME \
    --ttl=TIME_TO_LIVE \
    --type=RECORD_TYPE \
    --zone="MANAGED_ZONE_NAME" \
    --routing-policy-type=FAILOVER \
    --routing-policy-primary-data=PRIMARY_LOAD_BALANCER_FORWARDING_RULE \
    --routing-policy-backup-data_type=GEO \
    --routing-policy-backup-data="BACKUP_REGION_1=BACKUP_LOAD_BALANCER_1_IP_ADDRESS[;BACKUP_REGION_2=BACKUP_LOAD_BALANCER_2_IP_ADDRESS;BACKUP_REGION_3=BACKUP_LOAD_BALANCER_3_IP_ADDRESS]" \
    --health-check=HEALTH_CHECK_NAME \
    --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO
```
替换以下内容：
- DNS_RECORD_SET_NAME：要添加的记录集的 DNS 或域名，例如 test.example.com
- TIME_TO_LIVE：记录集的存留时间 (TTL)，以秒为单位。如需了解建议的值，请参阅最佳实践。
- RECORD_TYPE：记录类型，例如 A
- MANAGED_ZONE_NAME：您要管理其记录集的代管区域的名称，例如 my-zone-name
- PRIMARY_LOAD_BALANCER_FORWARDING_RULE：主负载均衡器的转发规则名称
- BACKUP_REGION：部署备用负载均衡器的区域
- BACKUP_LOAD_BALANCER_IP_ADDRESS：与每个区域对应的备用负载均衡器的转发规则 IP 地址
- BACKUP_DATA_TRICKLE_RATIO：发送到备用负载均衡器的流量的比率（即使主负载均衡器健康状况良好）。该比率必须介于 0 和 1 之间，例如 0.1。默认值设为 0。

最佳做法

在配置 Cloud DNS 记录和健康检查时，请记住以下一些最佳实践：

流量从主负载均衡器故障切换到备用负载均衡器所需的时间（即服务中断的时长）取决于 DNS TTL 值、健康检查间隔时间和健康检查的健康状况不佳阈值参数。

使用 Google 的 Cloud DNS 时，此时间段的上限可通过以下公式计算：
```
Duration of outage = DNS TTL + Health Check Interval * Unhealthy Threshold
```
对于故障切换配置，我们建议将 DNS TTL 设置为 30-60 秒。较高的 TTL 会导致停机时间较长，因为即使 DNS 已故障切换到备用区域级外部应用负载均衡器，互联网上的客户端仍会继续访问主外部应用负载均衡器。
配置健康检查中的健康状况良好和健康状况不佳阈值参数，以便避免由暂时性错误导致的不必要的故障切换。较高的阈值会增加流量故障切换到备用负载均衡器所需的时间。
如需帮助确保故障切换设置按预期工作，您可以将 DNS 路由政策设置为始终将一小部分流量发送到备用负载均衡器（即使主负载均衡器健康状况良好）。您可以在创建 DNS 记录集时使用 --backup-data-trickle-ratio 参数来完成此操作。

可以将发送到备用负载均衡器的流量的百分比配置为 0 到 1 之间的小数。典型值为 0.1，但 Cloud DNS 允许您将 100% 的流量发送到备用 VIP 地址，以手动触发故障切换。