外部 TCP/UDP 网络负载平衡概览

Google Cloud 外部 TCP/UDP 网络负载平衡(此后称为网络负载平衡)是区域级的非代理负载平衡器。

网络负载平衡在虚拟私有云 (VPC) 网络中同一区域的虚拟机 (VM) 实例之间分配流量。网络负载平衡器可以跨区域后端定向 TCP 或 UDP 流量。

网络负载平衡器支持所有端口。您可以使用网络负载平衡对 TCP 和 UDP 流量进行负载平衡。由于负载平衡器是直通负载平衡器,因此您的后端会终止负载平衡的 TCP 连接或 UDP 数据包本身。例如,您可以在后端运行 HTTPS 网络服务器,并使用网络负载平衡将请求路由到该服务器,从而终止后端本身上的 TLS。

如需详细了解受支持的端口,请参阅 Google Cloud 负载平衡器摘要

网络负载平衡具有以下特点:

  • 网络负载平衡是一项托管式服务。
  • 网络负载平衡是使用 Andromeda 虚拟网络Google Maglev 实现的。
  • 网络负载平衡器不是代理。
  • 来自后端虚拟机的响应直接发送到客户端,而不是通过负载平衡器返回。其行业术语称为直接服务器返回
  • 负载平衡器会保留数据包的来源 IP 地址。
  • 数据包的目标 IP 地址是与负载平衡器的转发规则关联的区域外部 IP 地址。

因此:

  • 作为网络负载平衡器的后端虚拟机参与的实例必须运行相应的 Linux 访客环境Windows 访客环境或提供同等功能的其他进程。

    访客操作系统环境(或等效进程)负责在每个后端虚拟机上配置本地路由。这些路由允许虚拟机接受其目标位置与负载平衡器转发规则的 IP 地址相匹配的数据包。

  • 在接受实现了负载平衡的流量的后端实例上,您必须将软件配置为绑定到与负载平衡器的转发规则相关联的 IP 地址(或任何 IP 地址 0.0.0.0/0)。

下图展示了加利福尼亚、纽约和新加坡的用户。 他们均连接到后端资源(myapp、test 和 travel)。当新加坡的用户连接到美国西部后端时,流量会进入离新加坡最近的区域,因为范围是任播的。然后,流量将路由到区域后端。

三个区域后端和三个转发规则(点击可放大)
网络负载平衡示例(点击可放大)

如需了解各种 Google Cloud 负载平衡器之间的具体区别,请参阅以下文档:

协议、方案和范围

每个网络负载平衡器要么支持 TCP 流量,要么支持 UDP 流量(不同时支持两者)。

网络负载平衡器会平衡来自互联网的流量。

网络负载平衡器按区域划分范围,而非全球范围。这意味着网络负载平衡器不能跨多个区域。负载平衡器可以为一个区域内的所有地区提供服务。

用例

在以下情况可使用网络负载平衡:

  • 您需要对 UDP 流量进行负载平衡,或者需要对其他负载平衡器不支持的 TCP 端口进行负载平衡。
  • 可以通过后端解密 SSL 流量,但负载平衡器不可以。网络负载平衡器无法执行此任务。当后端解密 SSL 流量时,虚拟机的 CPU 负担增大。
  • 您可以自行管理负载平衡器的 SSL 证书。 由 Google 管理的 SSL 证书仅适用于 HTTP(S) 负载平衡和 SSL 代理负载平衡。
  • 您需要转发未被代理的原始数据包。
  • 您的现有设置使用直通式负载平衡器,您希望原封不动地将它迁移。

架构

负载平衡器由多个配置组件组成。单个负载平衡器可能具有以下功能:

网络负载平衡器始终有一个目标池。多条转发规则可以引用目标池。

目标池是负载平衡器的后端。它指定了将对流量进行负载平衡的后端实例。每条转发规则都是负载平衡器的前端。请注意,每个项目的转发规则数量和目标池数量都有限制

网络负载平衡器根据传入的 IP 协议数据(例如地址、端口和协议类型)平衡系统负载。

网络负载平衡器是一种直通式负载平衡器,因此您的后端会收到原始客户端请求。网络负载平衡器不执行任何传输层安全协议 (TLS) 的分流或代理。流量会直接路由到您的虚拟机。

为负载平衡器创建转发规则时,您会收到一个临时的虚拟 IP 地址 (VIP) 或保留来自区域性网络块的 VIP。

接着,您可以将转发规则与目标池相关联。VIP 是通过 Google 的全球入网点任播的,但网络负载平衡器的后端是区域性后端。负载平衡器不能包含跨多个区域的后端。

您可以使用 Google Cloud 防火墙来控制或过滤对后端虚拟机的访问。

网络负载平衡器会检查来源和目标端口与 IP 地址以及协议,以确定转发数据包的方式。对于 TCP 流量,您可以通过配置会话粘性来修改负载平衡器的转发行为。

负载分配算法

默认情况下,为了将流量分配给实例,会话粘性值会设置为 NONE。Cloud Load Balancing 根据来源 IP 和端口、目标 IP 和端口以及协议的哈希来选择实例。这意味着传入的 TCP 连接分散在不同的实例中,每个新的连接可能会转发到不同的实例。用于连接的所有数据包都定向到相同的实例,直到连接关闭。在负载平衡过程中不会考虑已建立的连接。

无论会话粘性如何设置,用于连接的所有数据包都定向到所选实例,直到连接关闭。现有连接不会影响新传入连接的负载平衡决策。如果使用长期有效的 TCP 连接,这可能会导致后端之间出现失衡。

如果您需要某个客户端的多个连接转到同一实例,可以选择其他会话粘性设置。

目标池

目标池资源定义了一组应从转发规则接收传入流量的实例。当转发规则将流量定向到目标池时,Cloud Load Balancing 将根据来源 IP 和端口以及目标 IP 和端口的哈希从这些目标池中选取实例。如需详细了解如何将流量分配到各个实例,请参阅本主题中的负载分配算法部分。

目标池仅能与处理 TCP 和 UDP 流量的转发规则一起使用。对于所有其他协议,您必须创建目标实例。您必须先创建目标池,才能将其与转发规则一起使用。每个项目最多可以有 50 个目标池。

如果您打算让自己的目标池包含单个虚拟机实例,则应考虑改用协议转发功能。

网络负载平衡支持 Cloud Load Balancing 自动扩缩程序,通过该自动扩缩程序,用户可以根据后端利用率对目标池中的实例组进行自动扩缩。如需了解详情,请参阅根据 CPU 利用率进行扩缩

转发规则

转发规则与目标池配合使用以支持负载平衡。如需使用负载平衡,您必须创建将流量定向到特定目标池的转发规则。如果没有转发规则,您就无法对流量进行负载平衡。

每个转发规则都会将特定的 IP 地址、协议和(可选)端口范围与单个目标池相匹配。当流量被发送到由一个转发规则负责处理流量的某个外部 IP 地址时,该转发规则会将这些流量定向到相应的目标池。

如果您要对到达 Google Cloud VPC 网络之前可能会被分段的 UDP 数据包进行负载平衡处理,请参阅负载平衡和经过分段的 UDP 数据包

多个转发规则

您可以为同一外部 TCP/UDP 网络负载平衡器配置多个区域外部转发规则。(可选)每个转发规则可以具有不同的区域外部 IP 地址,或者多个转发规则可以具有相同的区域外部 IP 地址。

配置多个区域外部转发规则在以下用例中非常有用:

  • 您需要为同一目标池配置多个外部 IP 地址。
  • 您需要为同一个目标池使用相同的外部 IP 地址,以配置不同的端口范围或不同的协议。

使用多个转发规则时,请确保将后端虚拟机上运行的软件配置为绑定到所有必要的 IP 地址。 这是必需的,因为通过负载平衡器传送的数据包的目标 IP 地址是与各自的区域外部转发规则关联的区域外部 IP 地址。

运行状况检查

运行状况检查可确保 Compute Engine 仅将新的连接转发到已启动并准备好接收它们的实例。Compute Engine 以指定的频率向每个实例发送运行状况检查请求。在实例超过其允许的运行状况检查失败次数后,就不再被视为可接收新流量的合格实例。现有连接不会被主动终止,因此实例可以正常关停,然后关闭 TCP 连接。

运行状况检查工具继续查询运行状况不佳的实例,并在成功检查达到特定次数后将实例返回池中。如果所有实例均被标记为 UNHEALTHY,则负载平衡器会将新流量定向到所有现有实例。

网络负载平衡依靠传统的 HTTP 运行状况检查来确定实例运行状况。即使您的服务未使用 HTTP,但必须在运行状况检查系统可查询的每个实例上运行基本的 Web 服务器。

旧式 HTTPS 运行状况检查不受网络负载平衡器支持,并且不能与其他大多数负载平衡器类型搭配使用。

返回路径

Google Cloud 会使用未在您的 VPC 网络中定义的特殊路由来执行运行状况检查。如需了解详情,请参阅负载平衡器返回路径

防火墙规则

网络负载平衡器的运行状况检查是从这些 IP 地址范围发出的。您需要创建入站允许防火墙规则,以允许来自这些范围的流量。

网络负载平衡是一种直通式负载平衡器,这意味着您的防火墙规则必须允许来自客户端来源 IP 地址的流量通过。如果您的服务面向互联网开放,允许来自所有 IP 地址范围的流量通过是最容易的。如果要限制访问权限,只允许某些来源 IP 地址,您可以设置防火墙规则来强制执行该限制,但您必须允许运行状况检查 IP 范围的访问。

如需获取防火墙规则示例和配置示例,请参阅网络负载平衡规则

会话粘性

网络负载平衡不使用后端服务会话粘性。相反,网络负载平衡器会将目标池用于会话粘性。

如需了解详情,请参阅使用目标池中的 sessionAffinity 参数。

负载平衡和经过分段的 UDP 数据包

如果您要对 UDP 数据包进行负载平衡处理,请注意以下事项:

  1. 未分段的数据包通常会在所有配置中进行处理。
  2. UDP 数据包在到达 Google Cloud 之前可能会被分段。中间网络可能会等待所有数据段到达,然后再进行转发,从而导致延迟,或者可能会丢弃数据段。Google Cloud 不会等待所有数据段;它会在每个数据段到达时立即转发。
  3. 由于后续 UDP 数据段不包含目标端口,因此在以下情况可能会出现问题:

    • 如果将目标池会话粘性设置为 NONE(5 元组粘性),后续数据段可能会被丢弃,因为负载平衡器无法计算 5 元组哈希。
    • 如果同一个负载平衡 IP 地址有多个 UDP 转发规则,后续数据段可能会到达错误的转发规则。

如果您想要经过分段的 UDP 数据包,请执行以下操作:

  • 将会话粘性设置为 CLIENT_IP_PROTOCLIENT_IP。不要使用 NONE(5 元组哈希方法)。由于 CLIENT_IP_PROTOCLIENT_IP 在计算哈希值时不使用目标端口,因此可以像对第一个数据段一样,为后续数据段计算哈希值。
  • 对每个负载平衡的 IP 地址只使用一个 UDP 转发规则。这确保了所有数据段到达相同的转发规则。

通过这些设置,来自同一数据包的 UDP 数据段会被转发到同一实例进行重组。

后续步骤