内部直通式网络负载均衡器故障切换

您可以将内部直通式网络负载均衡器配置为在主要后端中的虚拟机 (VM) 实例之间分配连接，然后在需要时改为使用故障切换后端。故障切换提供了一种提高可用性的方法，同时还可让您在主要后端虚拟机健康状况不佳时更好地控制系统如何管理工作负载。

本页面介绍了特定于内部直通式网络负载均衡器故障切换的概念和要求。在为内部直通式网络负载均衡器配置故障切换之前，请确保您已熟悉以下文章中的概念性信息：

了解这些概念很重要，因为配置故障切换会修改内部直通式网络负载均衡器的标准流量分配算法。

默认情况下，当您向内部直通式网络负载均衡器的后端服务添加后端时，该后端是主要后端。您可以在将某个后端添加到负载均衡器的后端服务时将其指定为故障切换后端，或者在以后通过修改后端服务将该后端指定为故障切换后端。在一定比率（可配置）的主要虚拟机未通过健康检查后，故障切换后端仅接收来自负载均衡器的连接。

支持的实例组

系统支持托管实例组和非托管实例组作为后端。简单起见，本页面上的示例展示的是非托管实例组。

如果将托管实例组与自动扩缩和故障切换搭配使用，可能导致活跃池在主要后端和故障切换后端之间反复进行故障切换和故障恢复。Google Cloud 不会阻止您使用托管实例组配置故障切换，因为您的部署可能会受益于此设置。

架构

以下简单示例展示了具有一个主要后端和一个故障切换后端的内部直通式网络负载均衡器。

主要后端是 us-west1-a 中的非托管实例组。
故障切换后端是 us-west1-c 中不同的非托管实例组。

内部直通式网络负载均衡器的故障切换示例。 — 内部直通式网络负载均衡器的故障切换示例（点击可放大）。

下一个示例展示了具有两个主要后端和两个故障切换后端的内部直通式网络负载均衡器，这两种后端分布在 us-west1 区域的两个可用区之间。此配置可以提高可靠性，因为它不依赖于单个可用区来容纳所有主要后端或所有故障切换后端。

主要后端是非托管实例组 ig-a 和 ig-d。
故障切换后端是非托管实例组 ig-b 和 ig-c。

多可用区内部直通式网络负载均衡器故障切换。 — 多可用区内部直通式网络负载均衡器故障切换（点击可放大）。

故障切换期间，两个主要后端均变为非活跃状态，而两个故障切换后端中健康状况良好的虚拟机会变为活跃状态。如需全面了解故障切换在此示例中的运作方式，请参阅故障切换示例。

后端实例组和虚拟机

内部直通式网络负载均衡器中的非代管式实例组是主要后端或故障切换后端。您可以在将某个后端添加到后端服务时将其指定为故障切换后端，或者在添加某个后端以后通过修改该后端将其指定为故障切换后端。否则，默认情况下，非托管实例组是主要后端。

您可以在单个内部直通式网络负载均衡器中配置多个主要后端和多个故障切换后端，方法是将它们添加到该负载均衡器的后端服务。

主要虚拟机是您已定义为主要后端的实例组的成员。除非负载均衡器切换为使用其故障切换后端，否则主要后端中的虚拟机会加入负载均衡器的活跃池（如下一部分所述）。

备用虚拟机是您已定义为故障切换后端的实例组的成员。当主要虚拟机健康状况不佳时，故障切换后端的虚拟机会加入负载均衡器的活跃池。触发故障切换的健康状况不佳的虚拟机数量是个可配置的百分比。

限制

虚拟机。活跃池中最多可以有 250 个虚拟机。换句话说，您的主要后端实例组最多可以有 250 个主要虚拟机，您的故障切换后端实例组最多可以有 250 个备用虚拟机。
非托管实例组。您最多可以有 50 个主要后端实例组和最多 50 个故障切换后端实例组。

例如，某个最大的部署可能有 5 个主要后端和 5 个故障切换后端，每个实例组包含 50 个虚拟机。

活跃池

活跃池是内部直通式网络负载均衡器向其发送新连接的后端虚拟机的集合。活跃池中后端虚拟机的成员由系统根据哪些后端健康状况良好以及您可以指定的条件自动计算，如故障切换比率中所述。

活跃池绝不会将主要虚拟机和备用虚拟机合并在一起。以下示例说明了成员的可能性。故障切换期间，活跃池仅包含备用虚拟机。在正常运行（故障恢复）期间，活跃池仅包含主要虚拟机。

故障切换和故障恢复

故障切换和故障恢复是使后端虚拟机进出负载均衡器的活跃池的自动过程。Google Cloud 从活跃池中移除主要虚拟机并将健康状况良好的故障切换虚拟机添加到活跃池时，该过程称为故障切换。Google Cloud 从活跃池中移除故障切换虚拟机并将健康状况良好的主要虚拟机添加到活跃池时，该过程称为故障恢复。

故障切换政策

故障切换政策是 Google Cloud 用于故障切换和故障恢复的一组参数。每个内部直通式网络负载均衡器都有一个具有多项设置的故障切换政策：

故障切换比率
当所有后端虚拟机运行状况都不佳时丢弃流量
故障切换和故障恢复期间的连接排空

故障切换比率

可配置的故障切换比率确定 Google Cloud 何时执行故障切换或故障恢复，从而更改活跃池中的成员。该比率介于 0.0 （含）到 1.0（含）之间。如果您不指定故障切换比率，Google Cloud 会使用默认值 0.0。最佳做法是将故障切换比率设置为适合您使用场景的数字，而不是依赖于此默认值。

条件	活跃池中的虚拟机
故障切换比率 (x) `!= 0.0`。运行状况良好的主要虚拟机的比率 `>= x`。故障切换比率 (x) `= 0.0`。运行状况良好的主要虚拟机的数量 `> 0`。	运行状况良好的所有主要虚拟机
如果至少有一个备用虚拟机健康状况良好，并且满足以下条件：故障切换比率 (x) `!= 0.0`。运行状况良好的主要虚拟机的比率 `< x`。故障切换比率 `= 0.0`。运行状况良好的主要虚拟机的数量 `= 0`。	运行状况良好的所有备用虚拟机
如果所有主要虚拟机和所有备用虚拟机健康状况都不佳，并且您未将负载均衡器配置为在此情况下丢弃流量	所有主要虚拟机（作为最后的补救措施）

以下示例说明了活跃池中的成员。如需查看计算示例，请参阅故障切换示例。

如果故障切换比率为 1.0，则所有主要虚拟机的健康状况都必须良好。如果至少有一个主要虚拟机健康状况不佳，则 Google Cloud 会执行故障切换，将备用虚拟机移动到活跃池中。
如果故障切换比率为 0.1，则至少有 10% 的主要虚拟机健康状况必须良好；否则，Google Cloud 会执行故障切换。
如果故障切换比率为 0.0，则 Google Cloud 只有在所有主要虚拟机健康状况都不佳时才会执行故障切换。如果至少有一个主要虚拟机健康状况良好，则 GCP 不会执行故障切换。

内部直通式网络负载均衡器根据流量分配算法在活跃池中的虚拟机之间分配连接。

当所有后端虚拟机运行状况都不佳时舍弃流量

默认情况下，当所有主要虚拟机和备用虚拟机运行状况都不佳时，Google Cloud 仅会在主要虚拟机之间分配新连接。这是最后的补救措施。此连接分配的最后补救措施不包括备用虚拟机。

如果您愿意，可以将内部直通式网络负载均衡器配置为在所有主要虚拟机和备用虚拟机健康状况都不佳时丢弃新连接。

故障切换和故障恢复期间的连接排空

借助连接排空，现有的 TCP 会话可以在长达一定时间段（可配置）内保持活跃状态，即使在后端虚拟机运行状况变得不佳以后也是如此。如果负载平衡器的协议为 TCP，则会出现以下情况：

默认情况下，连接排空已启用。现有的 TCP 会话可以在后端虚拟机上持续长达 300 秒（5 分钟），即使后端虚拟机运行状况不佳或不在负载平衡器的活跃池中也是如此。
您可以在故障切换和故障恢复事件期间停用连接排空。 在故障切换和故障恢复期间停用连接排空可以确保所有 TCP 会话（包括已建立的 TCP 会话）都能快速终止。TCP 重置数据包可能会关闭与后端虚拟机的连接。

在出现如下情况时，在故障切换和故障恢复期间停用连接排空会很有用：

修补后端虚拟机。在修补之前，请配置主虚拟机以使其无法通过健康检查，以便负载均衡器执行故障切换。停用连接排空可以确保所有连接都能按照计划快速移动到备用虚拟机。这样，您就可以安装更新并重启主要虚拟机，而无需持续运行现有的连接。修补完以后，如果有足够数量的主要虚拟机（由故障切换比率定义）通过其健康检查，Google Cloud 可以执行故障恢复。
使用单个后端虚拟机确保数据一致性。如果您需要确保只有一个主要虚拟机是所有连接的目标，请停用连接排空，以便从主要虚拟机切换到备用虚拟机的操作不允许现有的连接在这两个虚拟机上持续存在。这样可以在任何给定时间仅让一个后端虚拟机处于活跃状态，从而降低数据不一致的可能性。

故障切换示例

以下示例说明了架构部分中展示的多可用区内部直通式网络负载均衡器示例的故障切换行为。

此负载平衡器的主要后端是非托管实例组 ig-a（在 us-west1-a 中）和 ig-d（在 us-west1-c 中）。每个实例组都包含两个虚拟机。这两个实例组中的所有四个虚拟机都是主要虚拟机：

ig-a 中的 vm-a1
ig-a 中的 vm-a2
ig-d 中的 vm-d1
ig-d 中的 vm-d2

此负载均衡器的故障切换后端是非托管实例组 ig-b（在 us-west1-a 中）和 ig-c（在 us-west1-c 中）。每个实例组都包含两个虚拟机。这两个实例组中的所有四个虚拟机都是备用虚拟机：

ig-b 中的 vm-b1
ig-b 中的 vm-b2
ig-c 中的 vm-c1
ig-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），并在这三个主要虚拟机之间分配新连接。

后续步骤

如需配置和测试使用故障切换的内部直通式网络负载均衡器，请参阅为内部直通式网络负载均衡器配置故障切换。
如需配置和测试内部直通式网络负载均衡器，请参阅设置内部直通式网络负载均衡器。
如需排查内部直通式网络负载均衡器的故障切换问题，请参阅排查内部直通式网络负载均衡器问题。