区域级外部应用负载均衡器的高可用性

本页面介绍了如何配置具有区域级外部应用负载均衡器的高可用性部署。如需实现高可用性，请在最支持应用流量的区域中部署多个单独的区域级外部应用负载均衡器。之所以能实现这一点，是因为不同区域中的区域级外部应用负载均衡器不仅彼此隔离，而且与同一区域中运行的任何全球外部应用负载均衡器或传统应用负载均衡器基础设施也隔离。

使用 Cloud DNS 地理定位路由政策可将流量路由到位于不同区域的两个或更多负载均衡器。该政策会根据客户端请求的来源将流量路由到最近的可用区域。我们还建议您使用健康检查，以便 Google Cloud 可以检测任何区域级服务中断，并且仅将流量路由到健康状况良好的负载均衡器。

以下示例设置展示了位于两个不同区域的两个区域级外部应用负载均衡器。

使用两个区域级外部应用负载均衡器实现高可用性。
使用两个区域级外部应用负载均衡器实现高可用性（点击可放大）。

以下部分介绍了包含此配置中涉及的不同组件的典型工作流。

  1. 使用健康检查检测区域级故障

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

    补充说明：

    • 在创建健康检查时，您必须正好指定三个来源区域。 只有全球健康检查才能指定来源区域。
    • 支持 HTTP、HTTPS 和 TCP 健康检查。
    • 健康检查探测实际上源自互联网上与已配置的 Google Cloud 来源区域相距不远的入网点 (PoP)。

  2. 将流量路由到健康状况良好的负载均衡器

    Google Cloud 使用 Cloud DNS 地理定位路由政策将流量引导至负载均衡器。如果所有负载均衡器都健康状况良好，Cloud DNS 会将流量路由到地理位置最靠近客户端请求来源的负载均衡器。

    如果特定区域中的负载均衡器开始无法通过健康检查，系统会将流量路由到其他区域中健康状况良好的可用负载均衡器。

  3. 故障恢复至使用所有负载均衡器

    再次开始通过健康检查后，系统会自动进行故障恢复。由于所有可用的负载均衡器都会处理流量，因此在故障恢复期间预计不会出现任何停机时间。

配置跨区域负载均衡

请执行以下步骤以配置有助于实现高可用性的跨区域部署：

  1. 在您确定最支持应用的流量的区域中创建区域级外部应用负载均衡器。其中的每个负载均衡器都必须具有相同的流量管理和安全配置。
  2. 创建健康检查和 DNS 路由政策，以便根据客户端位置将流量引导至负载均衡器，并在发生服务中断时将流量从健康状况不佳的负载均衡器移出。

在多个区域中创建负载均衡器

在配置其他冗余负载均衡器时，请注意以下事项：

  • 配置所有具有类似功能的区域级外部应用负载均衡器，以便无论哪个负载均衡器处理请求，系统都会以一致的方式处理流量。例如，您必须确保为所有区域级外部应用负载均衡器使用相同类型的 SSL 证书、相同的 Google Cloud Armor 政策以及相同的流量管理设置。

    我们建议您使用 Terraform 等自动化框架，以帮助在不同的区域级部署之间实现并维护负载均衡器配置的一致性。

  • 我们建议您在确定最支持应用的流量的每个区域中设置区域级外部应用负载均衡器。

  • 区域级外部应用负载均衡器支持 Network Service Tiers 高级层级和标准层级。我们建议您在高级层级中设置其他区域级外部应用负载均衡器，以确保低延迟。

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

配置 Cloud DNS 和健康检查

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

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

  1. 为主负载均衡器的转发规则 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。

  2. 在 Cloud DNS 中，创建记录集并对其应用地理定位路由政策。

    gcloud beta dns record-sets create DNS_RECORD_SET_NAME \
    --ttl=TIME_TO_LIVE \
    --type=RECORD_TYPE \
    --zone="MANAGED_ZONE_NAME" \
    --routing-policy-type="GEO" \
    --routing-policy-data="FORWARDING_RULE_NAME_A@REGION_A;FORWARDING_RULE_NAME_B@REGION_B[,;FORWARDING_RULE_NAME_C@REGION_C]" \
    --health-check=HEALTH_CHECK_NAME

    替换以下内容：

    • DNS_RECORD_SET_NAME：要添加的记录集的 DNS 或域名，例如 test.example.com
    • TIME_TO_LIVE：记录的存留时间 (TTL)，以秒为单位。如需了解建议的值，请参阅 DNS 注意事项。
    • RECORD_TYPE：记录类型，例如 A
    • MANAGED_ZONE_NAME：您要管理其记录集的托管式可用区的名称，例如 my-zone-name
    • FORWARDING_RULE_NAME：每个 REGION 中负载均衡器的转发规则的名称
    • REGION：在其中部署每个负载均衡器的区域

最佳做法

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

  • 流量从健康状况不佳的负载均衡器路由到健康状况良好的负载均衡器所需的时间（即服务中断的时长）取决于 DNS TTL 值、健康检查间隔时间和健康检查的健康状况不佳阈值参数。

    使用 Google 的 Cloud DNS 时，此时间段的上限可通过以下公式计算：

    Duration of outage = DNS TTL + Health Check Interval * Unhealthy Threshold

    我们建议将 DNS TTL 设置为 30 到 60 秒。较高的 TTL 会导致停机时间较长，因为即使 DNS 已故障切换到其他区域，互联网上的客户端仍会继续访问健康状况不佳的负载均衡器。

  • 配置健康检查中的健康状况良好和健康状况不佳阈值参数，以避免因暂时性错误而导致不必要的突然流量重路由。较高的阈值会增加流量转移到其他区域中的负载均衡器所需的时间。