您可以配置内部 TCP/UDP 负载平衡器以便在主要后端的虚拟机实例之间分配连接，然后根据需要切换到使用故障转移后端。故障转移提供了一种提高可用性的方法，同时还可让您在主要后端虚拟机运行状况不佳时更好地控制系统如何管理工作负载。
本页面介绍内部 TCP/UDP 负载平衡器故障转移专用概念和要求。在为内部 TCP/UDP 负载平衡配置故障转移之前，请确保您已熟悉以下文章中的概念信息：
了解这些概念很重要，因为配置故障转移会修改内部 TCP/UDP 负载平衡器的标准流量分配算法。
默认情况下，您向内部 TCP/UDP 负载平衡器的后端服务添加后端时，该后端会作为主要后端。您可以在将某个后端添加到负载平衡器的后端服务时将其指定为故障转移后端，或者在以后通过修改后端服务将该后端指定为故障转移后端。在一定比率（可配置）的主要虚拟机未通过运行状况检查后，故障转移后端仅接收来自负载平衡器的连接。
支持的实例组
系统支持托管实例组和非托管实例组作为后端。简单起见，本页面上的示例展示的是非托管实例组。
如果将托管实例组与自动扩缩和故障转移搭配使用，可能导致活跃池在主要后端和故障转移后端之间反复进行故障转移和故障恢复。Google Cloud 不会阻止您使用托管实例组配置故障转移，因为您的部署可能会受益于此设置。
架构
以下简单示例介绍了具有一个主要后端和一个故障转移后端的内部 TCP/UDP 负载平衡器。
- 主要后端是
us-west1-a中的非托管实例组。 - 故障转移后端是
us-west1-c中不同的非托管实例组。
下一个示例介绍了具有两个主要后端和两个故障转移后端的内部 TCP/UDP 负载平衡器，这两种后端分布在 us-west1 区域的两个地区之间。此配置可以提高可靠性，因为它不依赖于单个地区来容纳所有主要后端或所有故障转移后端。
- 主要后端是非托管实例组
ig-a和ig-d。 - 故障转移后端是非托管实例组
ig-b和ig-c。
故障转移期间，两个主要后端均变为非活跃状态，而两个故障转移后端中运行状况良好的虚拟机会变为活跃状态。如需全面了解故障转移在此示例中的运作方式，请参阅故障转移示例。
后端实例组和虚拟机
内部 TCP/UDP 负载平衡中的非托管式实例组是主要后端或故障转移后端。您可以在将某个后端添加到后端服务时将其指定为故障转移后端，或者在添加某个后端以后通过修改该后端将其指定为故障转移后端。否则，默认情况下，非托管实例组是主要后端。
通过将多个主要后端和多个故障转移后端添加到负载平衡器的后端服务中，您可以在单个内部 TCP/UDP 负载平衡器中配置这些后端。
主要虚拟机是您已定义为主要后端的实例组的成员。除非负载平衡器切换为使用其故障转移后端，否则主要后端中的虚拟机会加入负载平衡器的活跃池（如下一部分所述）。
备用虚拟机是您已定义为故障转移后端的实例组的成员。当主要虚拟机运行状况不佳时，故障转移后端的虚拟机会加入负载平衡器的活跃池。触发故障转移的运行状况不佳的虚拟机数量是个可配置的百分比。
限制
虚拟机。活跃池中最多可以有 250 个虚拟机。 换句话说，您的主要后端实例组最多可以有 250 个主要虚拟机，您的故障转移后端实例组最多可以有 250 个备用虚拟机。
非托管实例组。您最多可以有 50 个主要后端实例组和最多 50 个故障转移后端实例组。
例如，某个最大的部署可能有 5 个主要后端和 5 个故障转移后端，每个实例组包含 50 个虚拟机。
活跃池
活跃池是内部 TCP/UDP 负载平衡器向其发送新连接的后端虚拟机的集合。活跃池中后端虚拟机的成员由系统根据哪些后端运行状况良好以及您可以指定的条件自动计算，如故障转移比率中所述。
活跃池绝不会将主要虚拟机和备用虚拟机合并在一起。以下示例说明了成员的可能性。故障转移期间，活跃池仅包含备用虚拟机。在正常运行（故障恢复）期间，活跃池仅包含主要虚拟机。
故障转移和故障恢复
故障转移和故障恢复是使后端虚拟机进出负载平衡器的活跃池的自动过程。Google Cloud 从活跃池中移除主要虚拟机并将运行状况良好的故障转移虚拟机添加到活跃池时，该过程称为故障转移。Google Cloud 从活跃池中移除故障转移虚拟机并将运行状况良好的主要虚拟机添加到活跃池时，该过程称为故障恢复。
故障转移政策
故障转移政策是 Google Cloud 用于故障转移和故障恢复的一组参数。每个内部 TCP/UDP 负载平衡器都有一项故障转移政策，故障转移政策有如下多项设置：
- 故障转移比率
- 当所有后端虚拟机运行状况都不佳时丢弃流量
- 故障转移和故障恢复期间的连接排空
故障转移比率
可配置的故障转移比率确定 Google Cloud 何时执行故障转移或故障恢复，从而更改活跃池中的成员。该比率介于 0.0 （含）到 1.0（含）之间。
如果您不指定故障转移比率，Google Cloud 会使用默认值 0.0。最佳做法是将故障转移比率设置为适合您使用场景的数字，而不是依赖于此默认值。
| 条件 | 活跃池中的虚拟机 |
|---|---|
|
运行状况良好的所有主要虚拟机 |
如果至少有一个备用虚拟机运行状况良好，并且满足以下条件：
|
运行状况良好的所有备用虚拟机 |
| 如果所有主要虚拟机和所有备用虚拟机运行状况都不佳，并且您未将负载平衡器配置为在此情况下丢弃流量 | 所有主要虚拟机（作为最后的补救措施） |
以下示例说明了活跃池中的成员。如需查看计算示例，请参阅故障转移示例。
- 如果故障转移比率为
1.0，则所有主要虚拟机的运行状况都必须良好。如果至少有一个主要虚拟机运行状况不佳，则 Google Cloud 会执行故障转移，将备用虚拟机移动到活跃池中。 - 如果故障转移比率为
0.1，则至少有 10% 的主要虚拟机运行状况必须良好；否则，Google Cloud 会执行故障转移。 - 如果故障转移比率为
0.0，则 Google Cloud 只有在所有主要虚拟机运行状况都不佳时才会执行故障转移。如果至少有一个主要虚拟机运行状况良好，则 GCP 不会执行故障转移。
内部 TCP/UDP 负载平衡器会根据流量分配算法在活跃池中的虚拟机之间分配连接。
当所有后端虚拟机运行状况都不佳时舍弃流量
默认情况下，当所有主要虚拟机和备用虚拟机运行状况都不佳时，Google Cloud 仅会在主要虚拟机之间分配新连接。这是最后的补救措施。此连接分配的最后补救措施不包括备用虚拟机。
如果您愿意，可以将内部 TCP/UDP 负载平衡器配置为在所有主要虚拟机和备用虚拟机运行状况都不佳时丢弃新连接。
故障转移和故障恢复期间的连接排空
借助连接排空，现有的 TCP 会话可以在长达一定时间段（可配置）内保持活跃状态，即使在后端虚拟机运行状况变得不佳以后也是如此。如果负载平衡器的协议为 TCP，则会出现以下情况：
默认情况下，连接排空已启用。现有的 TCP 会话可以在后端虚拟机上持续长达 300 秒（5 分钟），即使后端虚拟机运行状况不佳或不在负载平衡器的活跃池中也是如此。
您可以在故障转移和故障恢复事件期间停用连接排空。 在故障转移和故障恢复期间停用连接排空可以确保所有 TCP 会话（包括已建立的 TCP 会话）都能快速终止。TCP 重置数据包可能会关闭与后端虚拟机的连接。
在出现如下情况时，在故障转移和故障恢复期间停用连接排空会很有用：
修补后端虚拟机。在修补之前，请配置主虚拟机以使其无法通过运行状况检查，以便负载平衡器执行故障转移。停用连接排空可以确保所有连接都能按照计划快速移动到备用虚拟机。这样，您就可以安装更新并重启主要虚拟机，而无需持续运行现有的连接。 修补完以后，如果有足够数量的主要虚拟机（由故障转移比率定义）通过其运行状况检查，Google Cloud 可以执行故障恢复。
使用单个后端虚拟机确保数据一致性。如果您需要确保只有一个主要虚拟机是所有连接的目标，请停用连接排空，以便从主要虚拟机切换到备用虚拟机的操作不允许现有的连接在这两个虚拟机上持续存在。这样可以在任何给定时间仅让一个后端虚拟机处于活跃状态，从而降低数据不一致的可能性。
故障转移示例
以下示例介绍了架构部分中提供的多地区内部 TCP/UDP 负载平衡器示例中的故障转移行为。
此负载平衡器的主要后端是非托管实例组 ig-a（在 us-west1-a 中）和 ig-d（在 us-west1-c 中）。每个实例组都包含两个虚拟机。这两个实例组中的所有四个虚拟机都是主要虚拟机：
ig-a中的vm-a1ig-a中的vm-a2ig-d中的vm-d1ig-d中的vm-d2
此负载平衡器的故障转移后端是非托管实例组 ig-b（在 us-west1-a 中）和 ig-c（在 us-west1-c 中）。每个实例组都包含两个虚拟机。这两个实例组中的所有四个虚拟机都是备用虚拟机：
ig-b中的vm-b1ig-b中的vm-b2ig-c中的vm-c1ig-c中的vm-c2
假设您要为此负载平衡器配置一项故障转移政策，以便在运行状况良好的主要虚拟机数少于两个时将新连接提供给备用虚拟机。为此，请将故障转移比率设置为 0.5 (50%)。Google Cloud 会使用故障转移比率计算运行状况必须良好的最小主要虚拟机数量，计算方法是，将故障转移比率乘以主要虚拟机的数量：4 × 0.5 = 2
当所有四个主要虚拟机都运行状况良好时，Google Cloud 会将新连接分配到所有这四个主要虚拟机。以下是主要虚拟机无法通过运行状况检查时的情况：
如果
vm-a1和vm-d1运行状况不佳，则 Google Cloud 会在其余两个运行状况良好的主要虚拟机vm-a2和vm-d2之间分配新连接，因为运行状况良好的主要虚拟机数至少达到了最小值。如果
vm-a2也未通过运行状况检查，从而使得运行状况良好的主要虚拟机只剩下一个 （vm-d2），则 Google Cloud 会发现运行状况良好的主要虚拟机数少于最小值，从而执行故障转移。活跃池会设置为运行状况良好的四个备用虚拟机，而新连接会在这四个备用虚拟机（在实例组ig-b和ig-c中）之间进行分配。即使vm-d2运行状况仍然良好，系统也会将它从活跃池中移除，它不会接收新连接。如果
vm-a2恢复正常并通过了运行状况检查，则 Google Cloud 会发现运行状况良好的主要虚拟机数至少达到了最小值 2，从而执行故障恢复。活跃池会设置为运行状况良好的两个主要虚拟机vm-a2和vm-d2，而新连接会在这两个主要虚拟机之间进行分配。所有备用虚拟机都会从活跃池中移除。当其他主要虚拟机恢复正常并通过其运行状况检查时，Google Cloud 会将它们添加到活跃池中。例如，如果
vm-a1运行状况恢复良好，则 Google Cloud 会将活跃池设置为三个运行状况良好的主要虚拟机（vm-a1、vm-a2和vm-d2），并在这三个主要虚拟机之间分配新连接。
后续步骤
- 如需了解如何配置和测试使用故障转移的内部 TCP/UDP 负载平衡器，请参阅为内部 TCP/UDP 负载平衡配置故障转移。
- 如需配置和测试内部 TCP/UDP 负载平衡器，请参阅设置内部 TCP/UDP 负载平衡。
- 如需了解如何排查内部 TCP/UDP 负载平衡器的故障转移问题，请参阅内部 TCP/UDP 负载平衡问题排查。