内部 TCP/UDP 负载平衡概览

Google Cloud 内部 TCP/UDP 负载平衡是一种区域级负载平衡器,可让您在只能由内部虚拟机 (VM) 实例访问的内部负载平衡 IP 地址后面运行和扩缩服务。

内部 TCP/UDP 负载平衡使用内部 IP 地址在 Virtual Private Cloud (VPC) 网络中同一区域内的虚拟机实例之间分配流量。

如下面的概要图表所示,内部 TCP/UDP 负载平衡服务有一个前端(转发规则)和一个后端(后端服务和实例组)。

内部 TCP/UDP 负载平衡器概要示例(点击可放大)
内部 TCP/UDP 负载平衡器概要示例(点击可放大)

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

协议、方案和范围

每个内部 TCP/UDP 负载平衡器都支持:

  • TCP 或 UDP 流量(不同时支持两者)
  • 一种具有负载平衡方案的后端服务:internal
  • 一个 VPC 网络中的后端虚拟机
  • 一个区域内的所有地区中的后端虚拟机
  • 任何区域中的客户端(如果启用了全球访问权限

内部 TCP/UDP 负载平衡器不支持:

客户端访问

您可以启用全球访问权限,允许来自任何区域的客户端虚拟机实例访问您的内部 TCP/UDP 负载平衡器。客户端虚拟机必须位于内部 TCP/UDP 负载平衡器所在的网络中,或者位于使用 VPC 网络对等互连连接的 VPC 网络中。

下表汇总了客户端访问。

在停用全球访问权限的情况下 在启用全球访问权限的情况下
客户端必须位于负载平衡器所在的区域中。客户端还必须位于负载平衡器所在的 VPC 网络中,或者位于使用 VPC 网络对等互连连接到负载平衡器 VPC 网络的 VPC 网络中。 客户端可以位于任何区域中。客户端仍必须位于负载平衡器所在的 VPC 网络中,或者位于使用 VPC 网络对等互连连接到负载平衡器 VPC 网络的 VPC 网络中。
本地客户端可通过 Cloud VPN 隧道或互连连接 (VLAN) 访问负载平衡器。这些隧道或连接必须位于负载平衡器所在的区域中。 本地客户端可通过 Cloud VPN 隧道或互连连接 (VLAN) 访问负载平衡器。这些隧道或连接可以位于任何区域中。

使用场景

内部 TCP/UDP 负载平衡器解决了许多使用场景。本部分提供了几个概要示例。

访问示例

您可以从使用以下功能连接的网络访问 VPC 网络中的内部 TCP/UDP 负载平衡器:

  • VPC 网络对等互连
  • Cloud VPN 和 Cloud Interconnect

如需详细示例,请参阅内部负载平衡和连接的网络

三层 Web 服务示例

您可以将内部 TCP/UDP 负载平衡与其他负载平衡器结合使用。例如,如果您合并了外部 HTTP(S) 负载平衡器,则外部负载平衡器就是 Web 层,且依赖于内部负载平衡器后面的服务。

下图描述了使用外部 HTTP(S) 负载平衡器和内部 TCP/UDP 负载平衡器的三层配置示例:

使用 HTTP(S) 负载平衡和内部 TCP/UDP 负载平衡的三层 Web 应用(点击可放大)
使用 HTTP(S) 负载平衡和内部 TCP/UDP 负载平衡的三层 Web 应用(点击可放大)

启用全球访问权限的三层 Web 服务示例

如果您启用全球访问权限,您的 Web 层虚拟机可以位于其他区域中,如下图所示。

此多层应用示例会显示以下内容:

  • 面向互联网的全球可用 Web 层,可通过 HTTP(S) 负载平衡进行流量负载平衡。
  • us-east1 区域中的内部后端负载平衡数据库层,可通过全球 Web 层访问。
  • europe-west1 区域中属于 Web 层的客户端虚拟机,可访问位于 us-east1 中的内部负载平衡数据库层。
使用 HTTP(S) 负载平衡和内部 TCP/UDP 负载平衡及启用全球访问权限的三层 Web 应用(点击可放大)
使用 HTTP(S) 负载平衡和内部 TCP/UDP 负载平衡及启用全球访问权限的三层 Web 应用(点击可放大)

内部 TCP/UDP 负载平衡的工作原理

内部 TCP/UDP 负载平衡器具有以下特征:

  • 是托管式服务。
  • 不是代理。
  • 是在虚拟网络中实现的。

与基于设备或基于虚拟机实例的负载平衡器不同,内部 TCP/UDP 负载平衡器不会终止来自客户端的连接。客户端不会将流量发送到负载平衡器,然后发送到后端,而是将流量直接发送到后端:

  • 没有中间设备或单点故障。
  • 客户端发往负载平衡器 IP 地址的请求会直接发送到后端虚拟机。
  • 来自后端虚拟机的响应会直接发送到客户端,而不是通过负载平衡器返回。TCP 响应使用直接服务器返回功能。如需了解详情,请参阅 TCP 和 UDP 请求与返回数据包

Google Cloud Linux 客机环境Windows 客机环境或等效进程将每个后端虚拟机配置成使用负载平衡器的 IP 地址。Google Cloud 虚拟网络可管理流量传输,并根据需要扩缩。

架构

具有多个后端实例组的内部 TCP/UDP 负载平衡器会在所有这些实例组中的后端虚拟机之间分配连接。如需了解分配方法及其配置选项,请参阅流量分配

您可以将任何类型的实例组(非托管实例组、托管地区实例组或托管区域实例组)用作负载平衡器的后端,但不能使用网络端点组 (NEG)。

高可用性描述了如何设计不依赖于单个地区的内部负载平衡器。

作为内部 TCP/UDP 负载平衡器的后端虚拟机参与的实例必须运行相应的 Linux 客机环境、Windows 客机环境或提供同等功能的其他进程。此客机环境必须能够联系元数据服务器(metadata.google.internal169.254.169.254)以读取实例元数据,以便生成本地路由以接受发送到负载平衡器内部 IP 地址的流量。

此图说明了两个单独的实例组中的虚拟机之间的流量分配情况。从客户端实例发送到负载平衡器 IP 地址 (10.10.10.9) 的流量在任一实例组中的后端虚拟机之间分配。从任意服务后端虚拟机发送的响应直接传送到客户端虚拟机。

您可以将内部 TCP/UDP 负载平衡与自定义模式或自动模式 VPC 网络结合使用。您还可以使用现有的旧式网络创建内部 TCP/UDP 负载平衡器。

高可用性

内部 TCP/UDP 负载平衡器具有源于设计的高可用性。无需采用特殊步骤即可使负载平衡器具有高可用性,因为该机制不依赖于单个设备或虚拟机实例。

如需确保将后端虚拟机实例部署到多个地区,请遵循以下部署建议:

  • 如果您可以使用实例模板来部署软件,请使用区域托管实例组。区域托管实例组可在多个地区之间自动分配流量,提供最佳选择以避免在任何给定地区发生潜在问题。

  • 如果您使用地区托管实例组或非托管实例组,请对同一后端服务使用(在同一区域内)不同地区中的多个实例组。使用多个地区可防止在任何给定地区出现潜在问题。

组件

内部 TCP/UDP 负载平衡器由以下 Google Cloud 组件组成。

组件 目的 要求
内部 IP 地址 这是负载平衡器的地址。 内部 IP 地址必须位于内部转发规则所在的子网中。子网必须位于后端服务所在的区域和 VPC 网络中。
内部转发规则 内部转发规则与内部 IP 地址结合后即为负载平衡器的前端。它定义负载平衡器接受的协议和端口,并将流量定向到区域内部后端服务。 内部 TCP/UDP 负载平衡器的转发规则必须满足以下条件:
• 具有 load-balancing-scheme 类型的 INTERNAL
• 使用的 ip-protocolTCPUDP,其与后端服务的 protocol 匹配。
• 引用的 subnet 位于后端服务所在的 VPC 网络和区域中。
区域内部后端服务 区域内部后端服务定义与后端(实例组)通信所采用的协议,并指定运行状况检查。后端可以是非托管实例组、托管地区实例组或托管区域实例组。 后端服务必须满足以下条件:
• 具有 INTERNAL 类型的 load-balancing-scheme
• 使用的 protocolTCPUDP,其与转发规则的 ip-protocol 匹配。
• 进行相关的运行状况检查。
• 拥有关联的区域。转发规则和所有后端实例组的区域必须位于后端服务区域所在的区域中。
• 与单个 VPC 网络关联。如果未指定,则系统将根据每个后端虚拟机的默认网络接口 (nic0) 所使用的网络来推断网络。

尽管后端服务未绑定到特定子网,但转发规则的子网必须位于后端服务所在的 VPC 网络中。
运行状况检查 每个后端服务都必须进行相关的运行状况检查。运行状况检查会定义参数,Google Cloud 根据这些参数确定其所管理的后端是否能够接收流量。只有后端实例组中运行状况良好的虚拟机才会接收从客户端虚拟机发送到负载平衡器 IP 地址的流量。 即使转发规则和后端服务可以使用 TCPUDP,Google Cloud 也不会对 UDP 流量进行运行状况检查。如需了解详情,请参阅运行状况检查和 UDP 流量

内部 IP 地址

内部 TCP/UDP 负载平衡使用您创建内部转发规则时所选的子网的主要 IP 地址范围中的内部 IPv4 地址。该 IP 地址不能在子网的次要 IP 地址范围中。

您可以在创建转发规则时指定内部 TCP/UDP 负载平衡器的 IP 地址。您可以选择接收临时 IP 地址或使用预留的 IP 地址

转发规则

转发规则指定负载平衡器用于接受流量的协议和端口。 由于内部 TCP/UDP 负载平衡器不是代理,因此它们会将流量传递到使用相同协议和端口的后端。

内部 TCP/UDP 负载平衡器至少需要一个内部转发规则。您可以为同一负载平衡器定义多个转发规则

转发规则必须引用负载平衡器后端组件所在的 VPC 网络和区域中的特定子网。此要求具有以下含义:

  • 您为转发规则指定的子网不必与后端虚拟机使用的任何子网相同;但是,子网必须位于转发规则所在的区域中。
  • 当您创建内部转发规则时,Google Cloud 会从所选子网的主要 IP 地址范围中选择一个可用的区域内部 IP 地址。或者,您也可以指定子网的主要 IP 地址范围中的内部 IP 地址。

转发规则和全球访问权限

即使启用了全球访问权限,内部 TCP/UDP 负载平衡器的转发规则也是区域规则。启用全球访问权限后,区域内部转发规则的 allowGlobalAccess 标志设为 true

转发规则和端口指定

在创建内部转发规则时,您必须选择以下端口指定之一:

  • 按编号指定 1-5 个端口。
  • 指定 ALL 以转发所有端口上的流量。

一个支持所有 TCP 端口或所有 UDP 端口的内部转发规则允许后端虚拟机在各自的端口上运行多个应用。发送到给定端口的流量会传送到相应的应用,并且所有应用都使用同一 IP 地址。

如果您需要转发超过五个特定端口的流量,请将防火墙规则和转发规则结合使用。创建转发规则时,请指定所有端口,然后创建仅允许流量进入所需端口的入站 allow 防火墙规则。将防火墙规则应用于后端虚拟机。

转发规则在创建后无法修改。如果您需要更改内部转发规则的指定端口或内部 IP 地址,则必须删除并重建转发规则。

多个转发规则

您可以为同一内部负载平衡器配置多个内部转发规则。每个转发规则都必须具有唯一的 IP 地址,并且只能引用单个后端服务。多个内部转发规则可以引用同一个后端服务。

如果您需要为同一内部 TCP/UDP 负载平衡器使用多个 IP 地址,或者需要将某些端口与不同的 IP 地址关联,则配置多个内部转发规则会非常有用。使用多个转发规则时,请确保将后端虚拟机上运行的软件配置为绑定到所有必要的 IP 地址。通过负载平衡器传送的数据包的目标 IP 地址是与相应内部转发规则关联的内部 IP 地址。

如需创建辅助转发规则,请参阅在其他子网中创建转发规则

在该示例中,为同一负载平衡器配置了两个转发规则:一个使用 10.1.2.99,另一个使用 10.5.6.99。后端虚拟机必须配置为通过任一 IP 地址接收数据包。完成此操作的一种方法是将后端配置为绑定到任意 IP 地址 (0.0.0.0/0)。

后端服务

每个内部 TCP/UDP 负载平衡器都有一个用于定义后端参数和行为的区域内部后端服务。后端服务的名称是 Google Cloud Console 中显示的内部 TCP/UDP 负载平衡器的名称。

每个后端服务会定义以下后端参数:

  • 协议。后端服务接受由一个或多个内部转发规则指定的端口上的 TCP 或 UDP 流量(但不同时接受两者)。后端服务允许将流量传送到流量所发往的相同端口上的后端虚拟机。后端服务协议必须与转发规则的协议匹配。

  • 流量分配。后端服务允许根据可配置的会话粘性分配流量

  • 运行状况检查。后端服务都必须进行相关的运行状况检查

每个后端服务都在单个区域内运行,并为单个 VPC 网络中的后端虚拟机分配流量:

  • 区域性。后端是实例组,位于后端服务(及转发规则)所在的区域中。 后端可以为非托管实例组、地区托管实例组或区域托管实例组。

  • VPC 网络。所有后端虚拟机在 VPC 网络中都必须具有一个与后端服务关联的网络接口。您可以明确指定后端服务的网络或使用隐式网络。在任一情况下,每个内部转发规则的子网都必须位于后端服务 VPC 网络所在的子网中。

后端服务和网络接口

每个后端服务都在单个 VPC 网络和 Google Cloud 区域运行。VPC 网络可以是隐式网络,也可以在 gcloud compute backend-services create 命令中使用 --network 标志来明确指定:

  • 如果明确指定,则后端服务的 VPC --network 标志用于识别实现流量负载平衡的每个后端虚拟机上的网络接口。每个后端虚拟机在指定的 VPC 网络中都必须具有一个网络接口。在这种情况下,每个后端虚拟机上的网络接口标识符(nic0nic7)可以不同。 例如:

    • 如果同一非托管实例组中的不同后端虚拟机在指定的 VPC 网络中都具有一个接口,则每个后端虚拟机可能使用不同的接口标识符。
    • 所有后端实例组的接口标识符不必相同:一个后端实例组中的后端虚拟机可能为 nic0,而另一个后端实例组中的后端虚拟机可能为 nic2
  • 如果您在创建后端服务时未添加 --network 标志,则后端服务会根据所有后端虚拟机使用的初始(或唯一)网络接口的网络选择网络。这意味着 nic0 必须与所有后端实例组中的所有虚拟机位于同一个 VPC 网络中。

运行状况检查

负载平衡器的后端服务必须与运行状况检查关联。VPC 网络之外的特殊路由可以促进运行状况检查系统与后端之间的通信。

您可以使用现有运行状况检查,也可以定义新的运行状况检查。内部 TCP/UDP 负载平衡器使用运行状况检查状态来确定如何路由新的连接,如流量分配中所述。

您可以使用以下任何运行状况检查协议;运行状况检查的协议不必与负载平衡器的协议匹配:

  • HTTP、HTTPS 或 HTTP/2。如果您的后端虚拟机使用 HTTP、HTTPS 或 HTTP/2 来处理流量,则最好使用与该协议匹配的运行状况检查,因为基于 HTTP 的运行状况检查提供了适用于该协议的选项。通过内部 TCP/UDP 负载平衡器处理 HTTP 类型的流量意味着负载平衡器的协议为 TCP。
  • SSL 或 TCP。如果您的后端虚拟机不处理 HTTP 类型的流量,则应使用 SSL 或 TCP 运行状况检查

无论您创建何种类型的运行状况检查,Google Cloud 都会向内部 TCP/UDP 负载平衡器的 IP 地址发送运行状况检查探测,模拟负载平衡流量的传送方式。在后端虚拟机上运行的软件必须同时响应发送到负载平衡器的 IP 地址的负载平衡流量和运行状况检查探测。如需了解详情,请参阅探测数据包的目标

运行状况检查和 UDP 流量

Google Cloud 不提供使用 UDP 协议的运行状况检查。当您对 UDP 流量使用内部 TCP/UDP 负载平衡时,必须在后端虚拟机上运行基于 TCP 的服务,以提供运行状况检查信息。

在此配置中,客户端请求使用 UDP 协议进行负载平衡,而 TCP 服务用于向 Google Cloud 运行状况检查探测器提供信息。例如,您可以在每个后端虚拟机上运行一个向 Google Cloud 返回 HTTP 200 响应的简单 HTTP 服务器。在此示例中,您应该使用在后端虚拟机上运行的专属逻辑来确保仅当 UDP 服务已正确配置并运行时,HTTP 服务器才会返回 200。

TCP 和 UDP 请求与返回数据包

当客户端系统将 TCP 或 UDP 数据包发送到内部 TCP/UDP 负载平衡器时,该数据包的来源和目标如下所示:

  • 来源:客户端的主要内部 IP 地址,或来自其中一个客户端别名 IP 地址范围的 IP 地址。
  • 目标:负载平衡器转发规则的 IP 地址。

当负载平衡器发送响应数据包时,该数据包的来源和目标取决于协议:

  • TCP 是面向连接的,而内部 TCP/UDP 负载平衡器使用直接服务器返回功能。这意味着系统从负载平衡器转发规则的 IP 地址发送响应数据包。
  • 相比之下,UDP 是无连接的。默认情况下,系统从后端实例网络接口的主要内部 IP 地址发送返回数据包。 不过,您可以更改此行为。例如,如果将 UDP 服务器配置成绑定到转发规则的 IP 地址,则会导致系统从转发规则的 IP 地址发送响应数据包。

下表总结了响应数据包的来源和目标:

流量类型 来源 目标
TCP 负载平衡器转发规则的 IP 地址 请求数据包的来源
UDP 取决于 UDP 服务器软件 请求数据包的来源

流量分配

内部 TCP/UDP 负载平衡器分配新连接的方式取决于您是否配置了故障转移

  • 如果您尚未配置故障转移,并且至少有一个后端虚拟机运行状况良好,则内部 TCP/UDP 负载平衡器会在其所有运行状况良好的后端虚拟机之间分配新连接。当所有后端虚拟机均运行状况不佳时,作为最后的补救手段,负载平衡器会在所有后端之间分配新连接。

  • 如果已配置故障转移,内部 TCP/UDP 负载平衡器会根据所配置的故障转移政策在其活跃池中的虚拟机之间分配新连接。当所有后端虚拟机运行状况不佳时,您可以选择丢弃流量

默认情况下,分配新连接的方法使用根据以下五种信息计算出的哈希:客户端 IP 地址、来源端口、负载平衡器的内部转发规则 IP 地址、目标端口和协议。您可以通过指定会话粘性选项来修改 TCP 流量的流量分配方法。

运行状况检查状态控制新连接的分配。如果运行状况不佳的后端虚拟机仍然在处理连接,则已建立的 TCP 会话会一直存在于运行状况不佳的后端虚拟机上。

会话粘性选项

会话粘性控制从客户端到负载平衡器的后端虚拟机的新连接分配。如果您的后端虚拟机需要在发送 TCP 流量时跟踪其客户端的状态信息,您可以设置会话粘性。这是 Web 应用的常见要求。

会话粘性非常适用于 TCP 流量。由于 UDP 协议不支持会话,因此会话粘性不会影响 UDP 流量。

内部 TCP/UDP 负载平衡器支持您为整个内部后端服务而非每个后端实例组指定的以下会话粘性选项:

  • 。这是默认设置,实际上与客户端 IP、协议和端口相同。
  • 客户端 IP。根据使用客户端 IP 地址和目标 IP 地址创建的哈希,将特定客户端的请求定向到同一个后端虚拟机。
  • 客户端 IP 和协议。根据使用客户端 IP 地址、目标 IP 地址和负载平衡器协议(TCP 或 UDP)这三种信息创建的哈希,将特定客户端的请求定向到同一个后端虚拟机。
  • 客户端 IP、协议和端口。根据使用以下五种信息创建的哈希,将特定客户端的请求定向到同一个后端虚拟机:

    • 发送请求的客户端的来源 IP 地址
    • 发送请求的客户端的来源端口
    • 目标 IP 地址
    • 目标端口
    • 协议(TCP 或 UDP)

    目标 IP 地址是负载平衡器的转发规则的 IP 地址,除非自定义静态路由导致数据包传送给负载平衡器。如果内部 TCP/UDP 负载平衡器是路由的下一个跃点,请参阅本文的下一个部分“会话粘性和下一个跃点内部 TCP/UDP 负载平衡器”

会话粘性和下一个跃点内部 TCP/UDP 负载平衡器

无论您选择哪种会话粘性选项,Google Cloud 都会使用数据包的目标位置。将数据包直接发送到负载平衡器时,数据包的目标位置与负载平衡器的转发规则的 IP 地址匹配。

但是,将内部 TCP/UDP 负载平衡器用作自定义静态路由的下一个跃点时,数据包的目标位置很可能不是负载平衡器的转发规则的 IP 地址。对于目标位置位于路由目标范围内的数据包,路由会定向到负载平衡器。

如需将内部 TCP/UDP 负载平衡器用作自定义静态路由的下一个跃点,请参阅内部 TCP/UDP 负载平衡器作为下一个跃点

会话粘性和运行状况检查状态

更改后端虚拟机的运行状况状态会导致丢失会话粘性。例如,如果后端虚拟机运行状况变得不佳,并且至少还有一个运行状况良好的后端虚拟机,则内部 TCP/UDP 负载平衡器不会将新连接分配给该运行状况不佳的虚拟机。如果客户端与该运行状况不佳的虚拟机之间具有会话粘性,则会改为将新连接定向到另一个运行状况良好的后端虚拟机,从而失去其会话粘性。

测试来自单个客户端的连接

在测试从单个客户端系统到内部 TCP/UDP 负载平衡器的 IP 地址的连接时,请注意以下几点:

  • 如果该客户端系统不是进行负载平衡的虚拟机(即非后端虚拟机),则新连接会传送到负载平衡器的运行状况良好的后端虚拟机。但是,由于所有会话粘性选项至少会依赖客户端系统的 IP 地址,因此来自同一客户端的连接可能会以超出预期的频率分配到同一个后端虚拟机。

    实际上,这意味着您无法通过从单个客户端连接到内部 TCP/UDP 负载平衡器来准确监控流量的分配情况。监控流量分配所需的客户端数量因负载平衡器类型、流量类型和运行状况良好的后端数量而异。

  • 如果客户端虚拟机是负载平衡器的后端虚拟机,则发送到负载平衡器转发规则的 IP 地址的连接始终由客户端/后端虚拟机应答。无论后端虚拟机的运行状况是否良好,都会发生这种情况。发送到负载平衡器 IP 地址的所有流量都会发生这种情况,而不仅仅是负载平衡器内部转发规则中指定的协议和端口上的流量。

    如需了解详情,请参阅从负载平衡虚拟机发送请求

限制

如需了解配额和限制,请参阅负载平衡资源配额和限制

后续步骤