跳转到内容
搜索文档

端点与池如何变为不健康

最后更新 查看 MarkdownAgent 设置

当我们谈论动态负载均衡时,意味着负载均衡器仅将请求导向能够处理流量的端点。

但负载均衡器如何_知道_哪些端点能够处理流量?我们通过监视器、健康监视器和池系统来确定。


动态负载均衡

动态负载均衡通过监视器健康检查的组合实现。

    flowchart RL
      accTitle: 负载均衡监控流程
      accDescr: 监控器发出健康检查请求,以验证每个池内服务器的当前状态。
      Monitor[监控器] -- 健康检查 ----> Endpoint2
      Endpoint2 -- 响应 ----> Monitor
      subgraph Pool [池]
      Endpoint1((端点 1))
      Endpoint2((端点 2))
      end

端点如何变为不健康

Health checks are requests issued by a monitor at regular interval and — depending on the monitor settings — return a pass or fail value to make sure an endpoint is still able to receive traffic.

Each health monitor request is trying to answer two questions:

  1. Is the endpoint offline?: Does the endpoint respond to the health monitor request at all? If so, does it respond quickly enough (as specified in the monitor's Timeout field)?
  2. Is the endpoint working as expected?: Does the endpoint respond with the expected HTTP response codes? Does it include specific information in the response body?

If the answer to either of these questions is "No", then the endpoint fails the health monitor request.

对于 pool 的 Health Monitor Regions(健康监视器区域) 中选择的每个选项,Cloudflare 会从该 region 内的三个独立数据中心发送健康 monitor 请求。

运行状况监视请求来自每个所选区域中的三个数据中心。

如果该 region 的大多数数据中心通过健康 monitor 请求,则该 region 被视为健康。如果大多数 region 健康,则 endpoint 本身将被视为健康。

Load balancing Analytics 和日志仅显示全局健康状态变更。

为了在更改端点健康状态时获得更高的准确性和一致性,您还可以通过 Create Monitor API 端点设置 consecutive_upconsecutive_down 参数。要从健康变为不健康,端点必须被连续标记为健康一定次数(由 consecutive_down 指定)。从不健康变为健康同样适用于 consecutive_up


池如何变为不健康

单个端点变为不健康时,可能会影响任何关联池的健康状态(在仪表板中可见):

  • Healthy(健康):所有端点均为健康。
  • Degraded(降级):至少一个端点为不健康,但池仍被视为健康,可能仍在接收流量。
  • Critical(严重):池已低于其 Health Threshold(健康阈值) 中指定的可用端点数量,不会从负载均衡器接收流量(除非其他池也不健康且此池被标记为 Fallback Pool(回退池))。
  • Health unknown(健康状态未知):池端点未附加监视器,或监视器尚未确定端点健康状态。
  • No health(无健康状态):保留给负载均衡器的 Fallback Pool(回退池)

流量分配

当 pool 达到 Critical 健康状态时,负载均衡器将根据其流量导向策略开始分流流量:

  • Off

    • 如果活动 pool 变为不健康,流量会按顺序转到下一个 pool。
    • 如果非活动 pool 变为不健康,流量仍会继续发往活动 pool(但在故障转移顺序中会跳过不健康的 pool)。
  • 所有其他方法:流量根据流量导向策略分配到所有剩余 pool。

回退池

此 pool 旨在作为最后手段 pool,意味着在定向流量时不考虑其健康状态。

Fallback pool 很重要,因为即使所有 pool 都不可达(已禁用或不健康),流量仍可能到达负载均衡器。负载均衡器需要将这些流量路由到某处,因此会将其发送到 fallback pool。


负载均衡器如何变为不健康

当一个或多个池变为不健康时,负载均衡器在仪表板中也可能显示不同的状态:

  • Healthy(健康):所有池均为健康。
  • Degraded(降级):至少一个池为不健康,但流量尚未进入 回退池
  • Critical(严重):所有池均为不健康,流量进入 回退池

如果负载均衡器达到 Critical(严重) 健康状态,且作为回退池的池也被禁用:

  • 如果 Cloudflare 代理您的主机名,您将看到 530 HTTP/1016 Origin DNS failure。
  • 如果 Cloudflare 不代理您的主机名,您将看到 SOA 记录。

这篇文档对您有帮助吗?