运行状况检查概念

Google Cloud Platform (GCP) 提供了运行状况检查机制,用于确定后端(例如实例组和网络端点组 (NEG))是否正确响应流量。本文讨论了特定于 GCP 及其负载平衡器的运行状况检查概念。

概览

GCP 提供了全球性和区域性的运行状况检查系统,这些系统可以按指定的时间间隔(可配置)定期连接到后端。每次连接尝试称为一次“探测”。GCP 会记录每次探测是成功还是失败。

运行状况检查和负载平衡器可协同工作。GCP 会根据指定的连续成功或失败探测次数(可以配置),评估负载平衡器中每个后端的整体运行状况。在配置的次数内成功做出响应的后端会被视为运行状况良好,而未能在指定的次数内成功做出响应的后端则会被视为运行状况不佳

GCP 会根据每个后端的整体运行状况来确定该后端是否有能力接收新的请求。除了能够配置探测频率和运行状况阈值之外,您还可以配置成功探测标准。本文详细介绍了运行状况检查原理

GCP 会使用未在您的 VPC 网络中定义的特殊路由来执行运行状况检查。如需全面了解相关信息,请参阅负载平衡器返回路径

运行状况检查类别、协议和端口

GCP 按类别和协议组织运行状况检查。

运行状况检查分为两种类别,即非旧版运行状况检查旧版运行状况检查。每种运行状况检查类别都支持一组不同的协议,并且都允许指定用于执行运行状况检查的端口。协议和端口决定了 GCP 运行状况检查系统与您的后端的通信方式。例如,您可以创建一个在 TCP 端口 80 上使用 HTTP 协议的运行状况检查,或者创建一个在实例组配置所指定的端口上使用 TCP 协议的运行状况检查。

大多数 GCP 负载平衡器都需要非旧版运行状况检查,但网络负载平衡需要使用 HTTP 协议的旧版运行状况检查。如需了解有关选择类别和协议以及指定端口的具体指导信息,请参阅选择运行状况检查

您不能将旧版运行状况检查转换为非旧版运行状况检查,反之亦然。

术语运行状况检查并不是指旧版运行状况检查。在本文中,我们会用术语旧版运行状况检查来明确指明此类检查。

选择运行状况检查

运行状况检查必须与负载平衡器的类型及其使用的后端类型(实例组或网络端点组)兼容。在创建运行状况检查时,您必须指定以下三大要素:

  • 类别:非旧版运行状况检查或旧版运行状况检查(必须与负载平衡器兼容)
  • 协议:定义 GCP 系统用于定期探测后端的协议
  • 端口指定方式:定义哪些端口用于运行状况检查的协议

本部分最后的指南总结了对给定负载平衡器类型和后端类型有效的一组运行状况检查类别、协议和端口指定方式。

本部分中使用的术语“实例组”指的是非托管式实例组、地区性托管式实例组或区域性托管式实例组。

类别和协议

负载平衡器的类型及其使用的后端类型决定了运行状况检查的类别。网络负载平衡需要使用 HTTP 协议的旧版运行状况检查,而其他所有负载平衡器类型则需要定期运行状况检查。

您必须从运行状况检查类别所支持的协议列表中选择协议。最好使用与负载平衡器本身相同的协议;不过,这种做法并非强制性要求,也并非总是可行。例如,网络负载平衡器需要旧版运行状况检查,并且要求旧版运行状况检查使用 HTTP 协议,尽管网络负载平衡通常支持 TCP 和 UDP。对于网络负载平衡器,您必须在虚拟机上运行 HTTP 服务器,以便虚拟机能够响应运行状况检查的探测请求。

下表列出了运行状况检查类别以及各类别支持的协议。

运行状况检查类别 支持的协议
非旧版运行状况检查 • HTTP
• HTTPS
• HTTP/2
• SSL
• TCP
旧版运行状况检查 • HTTP
• HTTPS(旧版 HTTPS 运行状况检查不受网络负载平衡器支持,并且不能与其他大多数负载平衡器类型搭配使用。)

类别和端口指定方式

除了协议之外,您还必须为运行状况检查选择端口指定方式。非旧版运行状况检查提供了三种端口指定方法,而旧版运行状况检查仅提供了一种方法。对于每种负载平衡器类型,并非所有端口指定方法都适用。负载平衡器的类型及其使用的后端类型决定了您可以使用的端口指定方法。

运行状况检查类别 端口指定方法及含义
非旧版运行状况检查 --port:指定 TCP 端口号
--port-name:指定在实例组中设置的任何特定端口
--use-serving-port:对于实例组,请使用与后端服务相同的特定端口;对于网络端点组,请使用在每个端点中定义的端口
旧版运行状况检查 --port:指定 TCP 端口号

请注意以下事项:标志 --use-serving-port 适用于 gcloud beta compute health-checks create,但不适用于 gcloud beta compute health-checks update

负载平衡器指南

您可以根据下表为给定的负载平衡器选择正确的运行状况检查类别和协议。

负载平衡器 后端类型 运行状况检查类别和范围 端口指定方式
内部 TCP/UDP 区域性内部后端服务中的实例组 非旧版运行状况检查(全球性) 端口号 (--port) 或特定端口 (--port-name)。
您不能使用 --use-serving-port 标志,因为采用 INTERNAL 负载平衡方案的后端服务不具有特定的关联端口。
内部 HTTP(S) 后端服务中的网络端点组
非旧版运行状况检查(区域性) 端口号 (--port) 或
--use-serving-port
后端服务中的实例组 非旧版运行状况检查(区域性) 端口号 (--port)、特定端口 (--port-name) 或
--use-serving-port
网络 使用目标池的实例组 使用 HTTP 协议的旧版运行状况检查(全球性)
旧版运行状况检查仅支持通过端口号 (--port) 指定端口。
TCP 代理
SSL 代理
HTTP(S) 1
后端服务中的网络端点组
非旧版运行状况检查(全球性) 端口号 (--port) 或
--use-serving-port
后端服务中的实例组 非旧版运行状况检查(全球性) 端口号 (--port)、特定端口 (--port-name) 或
--use-serving-port

1 在以下情况下,您可以(但不建议)对与 HTTP(S) 负载平衡器关联的后端服务使用旧版运行状况检查:

  • 该后端服务使用的后端是实例组,而非网络端点组。
  • 您可以使用 HTTPHTTPS 探测后端虚拟机。

运行状况检查原理

探测

创建非旧版运行状况检查创建旧版运行状况检查时,您可以指定以下标志或接受其默认值。这些标志用于控制每个 GCP 运行状况检查系统对您的实例组或 NEG 后端进行探测的频率。GCP 会使用多个系统来实现探测。

您不能针对每个后端分别配置运行状况检查的设置。对于某些 HTTP(S) 负载平衡器,非旧版运行状况检查会与整个后端服务相关联,而旧版运行状况检查则会与整个目标池或后端服务相关联。因此,探测参数对于给定后端服务或目标池所引用的全部后端来说都是相同的。

配置标志 用途 默认值
检查间隔时间
check-interval
检查间隔时间是指从一个探测系统发出的一次探测开始到由同一系统发出的下一次探测开始之间的时间量。该时间以秒为单位。 如果您省略了此标志,GCP 将使用 5s(5 秒)。
超时
timeout
超时是指 GCP 等待探测响应的时间。其值必须小于或等于检查间隔时间。该时间以秒为单位。 如果您省略了此标志,GCP 将使用 5s(5 秒)。

探测 IP 地址范围

GCP 探测系统的来源 IP 地址取决于负载平衡器的类型。您可以根据下表创建入站流量允许防火墙规则,以允许 GCP 探测系统向后端发送流量。

负载平衡器 探测 IP 地址范围 防火墙规则示例
内部
TCP 代理
SSL 代理
HTTP(S)
内部 HTTP(S)
35.191.0.0/16
130.211.0.0/22
除网络负载平衡器以外的其他所有负载平衡器的防火墙规则
网络 35.191.0.0/16
209.85.152.0/22
209.85.204.0/22
网络负载平衡器的防火墙规则

多重探测和频率

GCP 会通过适当来源 IP 地址范围内的多个冗余系统发送多次运行状况检查探测,而不是通过单个探测系统进行所有探测。使用多个系统同时发出探测请求可以确保 GCP 不会因一个系统的故障而无法跟踪后端运行状况。

您为运行状况检查配置的时间间隔和超时设置会应用于所有探测系统。对于给定的后端,软件访问日志和 tcpdump 中显示的运行状况检查探测频率会比您配置的设置更高。与单探测系统配置相比,使用多个探测系统同时与后端通信会增加运行状况检查探测次数。

这是预期的系统行为,您无法配置 GCP 用于运行状况检查的探测系统数量。不过,您可以通过考虑以下几个因素来估算同时执行多个探测请求所带来的影响:

  • 如需估算每项后端服务的探测频率,请考虑以下事项:

    • 每项后端服务的基本频率:每项运行状况检查都有一个关联的检查频率,此频率与配置的检查时间间隔成反比:

      1(检查时间间隔)

      将运行状况检查与后端服务相关联时,您需要为该后端服务中的后端确立用于每个探测系统的基本频率。

    • 探测比例系数:将后端服务的基本频率乘以 GCP 使用的并发探测系统数量。此数值可能不同,但通常介于 5 到 10 之间。

  • 内部 TCP/UDP 负载平衡器的多个转发规则:如果您配置了多个指向同一区域性内部后端服务的内部转发规则(每个规则具有不同的 IP 地址),GCP 会使用多个探测系统来检查各个 IP 地址。在这种情况下,请将每项后端服务的探测频率乘以配置的转发规则数。

  • 网络负载平衡器的多个转发规则:如果您配置了多个指向同一目标池的转发规则,GCP 会使用多个探测系统来检查各个 IP 地址。在这种情况下,请将目标池中每个后端所识别的探测频率乘以配置的转发规则数。

  • HTTP(S) 负载平衡器的多个目标代理:如果您为 HTTP(S) 负载平衡的同一网址映射配置了多个目标代理,GCP 会使用多个探测系统来检查与各个目标代理关联的 IP 地址。在这种情况下,请将每项后端服务的探测频率乘以配置的目标代理数。

  • SSL 代理和 TCP 代理负载平衡器的多个目标代理:如果您为 SSL 代理或 TCP 代理负载平衡的同一后端服务配置了多个目标代理,GCP 会使用多个探测系统来检查与各个目标代理关联的 IP 地址。在这种情况下,请将每项后端服务的探测频率乘以配置的目标代理数。

  • 对各项后端服务进行求和:如果某个后端(例如实例组)供多项后端服务使用,那么后端实例的探测频率就是各后端服务的运行状况检查频率之和。

    使用网络端点组 (NEG) 后端时,确切的运行状况检查探测次数会更难以确定。例如,同一端点可能位于多个 NEG 中,而这些 NEG 不一定包含同一组端点,并且不同端点可能会指向同一后端。

运行状况检查数据包的目的地

GCP 运行状况检查探测工具会将数据包仅发送到每个后端实例的主要网络接口。这些数据包的目的地 IP 地址取决于负载平衡器的类型:

  • 对于内部 TCP/UDP 负载平衡器和网络负载平衡器,运行状况检查数据包的目的地是负载平衡器转发规则的 IP 地址。如果多个转发规则指向同一个后端服务或目标池,GCP 会向每个转发规则的 IP 地址发送探测请求。这可能会增加探测次数,如上一部分所述。
  • 对于使用实例组作为后端的 HTTP(S)、TCP 代理、SSL 代理和内部 HTTP(S) 负载平衡器,运行状况检查数据包的目的地是与每个后端实例的主要网络接口相关联的主要内部 IP 地址。
  • 对于使用网络端点组作为后端的 HTTP(S)、TCP 代理、SSL 代理和内部 HTTP(S) 负载平衡器,运行状况检查数据包的目的地是端点的 IP 地址,即可以是主要或次要(别名 IP)地址。

基于内容的运行状况检查

您可以选择使用基于内容(请求/响应)的 HTTP(S)、HTTP/2、TCP、SSL 运行状况检查。在基于内容的运行状况检查中,运行状况检查探测工具会向后端发送一个请求字符串。此类运行状况检查已配置为接受特定的探测响应。

HTTP、HTTPS、HTTP/2 成功标准

对于使用 HTTP、HTTPS 或 HTTP/2 协议的运行状况检查,仅当 GCP 在探测超时之前收到其请求的 HTTP 200 (OK) 响应时,来自探测工具的响应才会被视为成功。

请求会被发送到指定的请求路径(可以配置);如果您未指定该路径,则请求会被发送到 /。除非您使用基于内容的检查来提供预期的响应字符串,否则系统会接受任何响应。以下标志可用于控制 HTTP、HTTPS、HTTP/2 运行状况检查成功标准:

配置标志 用途
请求路径
request-path
指定 GCP 要向其发送运行状况检查探测请求的网址路径。
如果您省略了此标志,GCP 会将探测请求发送到根路径 /request-path 选项不支持查询参数。
响应
response
您可以选择使用响应标志来配置基于内容的运行状况检查。预期响应字符串必须小于或等于 1024 个 ASCII(单字节)字符。配置此标志后,GCP 不但会收到 HTTP 200 (OK) 状态,还会在响应的前 1024 字节范围内找到该预期字符串。

使用基于内容的运行状况检查是一项可选操作。无论您是否指定预期的响应字符串,GCP 都要求被检查的后端使用 HTTP 200 (OK) 进行响应。如果您提供了预期响应,每个 GCP 运行状况检查探测工具会搜索您的后端提供的响应,并在返回的前 1024 个字节范围内查找预期响应字符串。如果系统收到 HTTP 200 (OK) 在所返回响应的前 1024 个字节中找到了预期响应,则基于内容的 HTTP 运行状况检查会被视为成功。

SSL 和 TCP 成功标准

默认情况下,对于使用 SSL 和 TCP 协议的运行状况检查,仅当 GCP 能够在探测超时之前成功完成 SSL 或 TCP 握手以建立会话时,来自探测工具的响应才会被视为成功。

除了完成握手之外,您还可以选择提供请求字符串和预期的响应字符串,但每个字符串的长度不应超过 1024 个 ASCII(单字节)字符。如果您配置了预期响应字符串,那么只有在 SSL 或 TCP 握手完成返回的响应字符串与预期响应字符串完全匹配时,GCP 才会认为探测成功。使用 SSL 和 TCP 协议的运行状况检查可以按以下方式使用请求和响应标志:

配置标志 行为
请求和响应均不指定
--request--response 标志均不指定
如果 TCP 或 SSL 会话在探测超时之前建立,则 GCP 会认为探测成功。
同时指定请求和响应
同时指定 --request--response 标志
GCP 会发送您配置的请求字符串,并等待预期的响应字符串。如果 TCP 或 SSL 会话在探测超时之前建立,并且返回的响应字符串与预期响应字符串完全匹配,则探测成功。
仅指定响应
仅指定 --response 标志
GCP 将等待预期的响应字符串。如果 TCP 或 SSL 会话在探测超时之前建立,并且返回的响应字符串与预期响应字符串完全匹配,则探测成功。
只有在负载平衡后端会在握手过程中自动发送响应字符串时,才能单独使用 --response
仅指定请求
仅指定 --request 标志
GCP 会发送您配置的请求字符串。如果 TCP 或 SSL 会话在探测超时之前建立,则探测成功。系统不会检查响应(如果有)。

运行状况

GCP 会根据以下配置标志以及探测成功与否来确定每个负载平衡后端的整体运行状况:

配置标志 用途 默认值
运行状况良好判断阈值
healthy-threshold
运行状况良好判断阈值指定了要将后端视为运行状况良好所需满足的连续成功探测次数。 如果您省略了此标志,GCP 会使用 2 作为阈值。
运行状况不佳判断阈值
unhealthy-threshold
运行状况不佳判断阈值指定了要将后端视为运行状况不佳所需满足的连续失败探测次数。 如果您省略了此标志,GCP 会使用 2 作为阈值。

达到此运行状况良好判断阈值后,GCP 会将后端视为运行状况良好。运行状况良好的后端可以接收新的连接。

达到运行状况不佳判断阈值后,GCP 会将后端视为运行状况不佳。运行状况不佳的后端不能接收新的连接;但是,现有连接不会立即终止。这些连接会一直保持打开状态,直到发生超时情况或流量被舍弃。具体行为因您使用的负载平衡器类型而异。

现有连接可能无法返回响应,具体取决于导致探测失败的原因。如果运行状况不佳的后端能够再次达到运行状况良好判断阈值,该后端就会被视为运行状况良好。

后续步骤

如需了解如何配置运行状况检查,请参阅创建运行状况检查