在 Compute Engine 中使用浮动 IP 地址的模式

Last reviewed 2024-01-29 UTC

本文档介绍了如何使用浮动 IP 地址实现模式将应用从本地网络环境迁移到 Compute Engine。本文档适用于将应用迁移到 Google Cloud 的网络管理员、系统管理员和运营工程师。

浮动 IP 地址也称为共享或虚拟 IP 地址，常常用于使本地网络环境具备高可用性。使用浮动 IP 地址，您可以在多台配置相同的物理服务器或虚拟服务器之间传递 IP 地址。这种实践允许故障切换或升级正式版软件。但是，如果不将架构更改为本文档中所述的模式之一，就无法直接在 Compute Engine 环境中实现浮动 IP 地址。

与本文档配套的 GitHub 代码库包含您可以使用 Terraform 自动部署的每种模式的部署示例。

本地环境中的浮动 IP 地址

浮动 IP 地址常常用于本地环境。使用场景示例如下：

有几种方法可以在本地环境中实现浮动 IP 地址。共享浮动 IP 地址的服务器通常也会通过检测信号机制共享状态信息。此机制允许服务器相互通知其健康状况；它还允许辅助服务器在主服务器发生故障后接管浮动 IP 地址。此方案通常使用虚拟路由器冗余协议实现，但您也可以使用其他类似的机制。

启动 IP 地址故障切换后，接管浮动 IP 地址的服务器会将地址添加到其网络接口。服务器通过发送免费地址解析协议 (ARP) 帧宣布使用第 2 层接管其他设备。或者，诸如开放式最短路径优先协议 (OSPF) 之类的路由协议有时也会将 IP 地址通告到上游第 3 层路由器。

下图展示了本地环境中的典型设置。

典型的本地环境。

上图显示了连接到同一交换机的主服务器和辅助服务器如何通过检测信号机制交换响应信息。如果主服务器发生故障，则辅助服务器会向交换机发送免费 ARP 帧，以接管浮动 IP 地址。

使用与本地负载均衡解决方案稍有不同的设置，例如具有直接服务器响应的 Windows 网络负载均衡或 Linux 负载均衡，例如 IPVS。在这些情况下，该服务还发出免费 ARP 帧，但使用另一台服务器的 MAC 地址作为免费 ARP 源。此操作实质上是仿冒 ARP 帧并接管另一台服务器的源 IP 地址。

执行此操作的目的是为了在不同的服务器之间分发一个 IP 地址的负载。但是，这种设置超出了本文档的范围。几乎在所有情况下，当浮动 IP 地址用于本地负载均衡时，最好迁移到 Cloud Load Balancing。

将浮动 IP 地址迁移到 Compute Engine 的挑战

Compute Engine 在 Virtual Private Cloud (VPC) 网络中使用虚拟化网络栈，因此，如果不在 Google Cloud 中进行更改，典型的实现机制将不起作用。例如，VPC 网络处理软件定义网络中的 ARP 请求，并忽略免费 ARP 帧。此外，您无法使用诸如 OSPF 或边界网关协议 (BGP) 等标准路由协议直接修改 VPC 网络路由表。浮动 IP 地址的典型机制依赖于通过切换基础架构来处理 ARP 请求，或者它们依赖于可通过 OSPF 或 BGP 编程的网络。因此，IP 地址不会使用 Google Cloud 中的这些机制进行故障切换。如果使用本地浮动 IP 地址迁移虚拟机映像，则浮动 IP 地址会在不更改应用的情况下进行故障切换。

您可以使用覆盖网络创建配置，以通过 ARP 请求启用完整的第 2 层通信和 IP 地址接管。但是，设置覆盖网络很复杂，这使得管理 Compute Engine 网络资源变得困难。该方法也超出了本文档的范围。取而代之的是，本文档介绍了在不创建覆盖网络的情况下在 Compute Engine 网络环境中实现故障切换场景的模式。

如需在 Compute Engine 中实现高可用性和高可靠性应用，请使用横向扩缩架构。这种架构可以最大限度地减少单节点故障带来的影响。

本文档介绍了使用浮动 IP 地址将现有应用从本地迁移到 Compute Engine 的多种模式，包括：

不建议使用在虚拟机实例之间移动的别名 IP 地址作为故障切换机制，因为它不符合高可用性要求。在某些故障场景（如可用区故障事件）中，您可能无法从实例中移除别名 IP 地址。因此，您可能无法将其添加到其他实例，造成无法进行故障切换。

为您的使用场景选择模式

根据您的要求，此解决方案中描述的一个或多个模式可用于在本地环境中实现浮动 IP 地址。

在决定哪种模式最适合您使用应用时，请考虑以下因素：

  • 浮动内部或浮动外部 IP 地址：大多数需要浮动 IP 地址的应用都使用浮动内部 IP 地址。很少有应用使用浮动外部 IP 地址，因为发送到外部应用的流量通常应该经过负载均衡。

    本部分后面的表建议可用于浮动内部 IP 地址和浮动外部 IP 地址的模式。对于依赖于浮动内部 IP 地址的用例，这些模式中的任何一个都可能符合您的需求。但是，我们建议依赖于浮动外部 IP 地址的用例应迁移到使用负载均衡的模式之一。

  • 应用协议：如果您的虚拟机仅使用 TCP 和 UDP，您可以使用表中的所有模式。如果它使用基于 IPv4 的其他协议进行连接，则只有某些模式是合适的。

  • 主动/主动部署兼容性：部分应用在本地使用浮动 IP 地址时，可以在主动/主动部署模式下工作。此功能意味着它们不一定需要从主服务器故障切换到辅助服务器。您还可以选择其他模式以将这些类型的应用迁移到 Compute Engine。如果应用在任何时候都只需要单个应用服务器来接收流量，则与主动/主动部署不兼容。您只能使用下表中的一些模式来实现这些应用。

  • 主要虚拟机恢复后的故障恢复行为：如果原始主要虚拟机在故障切换后恢复，根据使用的模式，流量会执行以下任一操作。它会立即移回原始主要虚拟机，或者保留在新的主要虚拟机上，直到手动启动故障恢复或新的主要虚拟机发生故障。在所有情况下，只有新启动的连接才会故障恢复。现有连接会保留在新的主要虚拟机中，直到被关闭为止。

  • 健康检查兼容性：如果难以使用 Compute Engine 健康检查来检查应用是否可以快速响应，则无法使用下表中描述的一些模式。

  • 实例组：任何具有健康检查兼容性的模式也与实例组兼容。如需自动重新创建失败的实例，您可以使用具有自动修复功能的托管式实例组。如果您的虚拟机保留状态，您可以使用有状态的托管式实例组。如果无法自动重新创建虚拟机或您需要手动进行故障切换，请使用非托管式实例组并在故障切换期间手动重新创建虚拟机。

  • 现有的检测信号机制：如果应用的高可用性设置已使用检测信号机制（例如 Heartbeat、Pacemaker 或 Keepalived）来触发故障切换，您可以使用下表中所述的某些模式。

下表列出了模式功能。以下各部分介绍了每个模式：

模式名称 IP 地址 支持的协议 部署模式 故障恢复 是否需要应用健康检查兼容性 可以集成检测信号机制
使用负载均衡的模式
主动/主动负载均衡 内部还是外部 仅限 TCP/UDP 主动/主动 不适用 是 否
通过故障切换和应用公开的健康检查实现负载均衡 内部还是外部 仅限 TCP/UDP 主动/被动 立即（现有连接除外） 是 否
通过故障切换和检测信号公开的健康检查实现负载均衡 内部还是外部 仅限 TCP/UDP 主动/被动 可配置 否 是
使用 Google Cloud 路由的模式
使用 ECMP 路由 内部 所有 IP 协议 主动/主动 不适用 是 否
使用不同的优先级路由 内部 所有 IP 协议 主动/被动 立即（现有连接除外） 是 否
使用检测信号机制切换路由的下一个跃点 内部 所有 IP 协议 主动/被动 可配置 否 是
使用自动修复的模式
使用自动修复单实例 内部 所有 IP 协议 不适用 不适用 是 否

确定您的使用场景所用的模式可能取决于多种因素。以下决策树可以帮助您将选择范围缩小到合适的选项。

可帮助您选择负载均衡器的决策树。

上图概述了以下步骤：

  1. 自动修复单实例是否提供足够的可用性来满足您的需求？
    1. 如果是，请参阅本文档后面的使用自动修复单实例。自动修复功能使用虚拟机实例组中的机制来自动替换有故障的虚拟机实例。
    2. 如果不是，请使用下一个决策点。
  2. 您的应用是否需要基于 IPv4（而非 TCP 和 UDP）的协议？
    1. 如果是，请使用下一个决策点。
    2. 如果不是，请使用下一个决策点。
  3. 您的应用是否可以在主动/主动模式下工作？
    1. 如果可以，且应用需要使用基于 IPv4（而非 TCP 和 UDP）的协议，请参阅本文档后面的使用等价多路径 (ECMP) 路由。ECMP 路由会在所有路由候选项的下一个跃点之间分配流量。
    2. 如果可以，且应用不需要使用基于 IPv4（而非 TCP 和 UDP）的协议，请参阅本文档后面的主动/主动负载均衡。主动/主动负载均衡将您的虚拟机用作内部 TCP/UDP 负载均衡器的后端。
    3. 如果在两种情况下都不能，请使用下一个决策点。
  4. 您的应用是否可以公开 Google Cloud 健康检查？
    1. 如果可以，且应用需要使用基于 IPv4（而非 TCP 和 UDP）的协议，请参阅本文档后面的通过故障切换和应用公开的健康检查实现负载均衡。“通过故障切换和应用公开的健康检查实现负载均衡”会将虚拟机用作内部 TCP/UDP 负载均衡器的后端。它还使用内部 TCP/UDP 负载均衡 IP 地址作为虚拟 IP 地址。
    2. 如果可以，且应用不需要使用基于 IPv4（而非 TCP 和 UDP）的协议，请参阅本文档后面的使用不同的优先级路由。“使用不同的优先级路由”有助于确保流量始终流向主实例，除非该实例发生故障。
    3. 如果不能，且应用需要使用基于 IPv4（而非 TCP 和 UDP）的协议，请参阅本文档后面的通过故障切换和检测信号公开的健康检查实现负载均衡。在“通过故障切换和检测信号公开的健康检查实现负载均衡”模式中，健康检查并非由应用本身公开，而是通过两个虚拟机之间运行的检测信号机制公开。
    4. 如果不能，且应用不需要使用基于 IPv4（而非 TCP 和 UDP）的协议，请参阅本文档后面的使用检测信号机制切换路由的下一个跃点。“使用检测信号机制切换路由的下一个跃点”是使用单个静态路由，且下一个跃点指向主要虚拟机实例。

使用负载均衡的模式

通常，您可以使用浮动 IP 地址将应用迁移到使用 Cloud Load Balancing 的 Google Cloud 架构。您可以使用内部直通式网络负载均衡器，因为此选项适合本地迁移服务仅在内部公开的大多数使用场景。此负载均衡选项用于本部分中以及 GitHub 上部署示例中的所有示例。如果您的客户端从其他区域访问浮动 IP 地址，请选择全球访问权限选项。

如果您的应用使用基于 IPv4（而非 TCP 或 UDP）的协议进行通信，您必须选择某一不使用负载均衡的模式。本文档后面部分介绍了这些模式。

如果您的应用使用 HTTP(S)，您可以使用内部应用负载均衡器来实现主动/主动模式。

如果您尝试迁移的服务可供外部使用，则可以使用外部直通式网络负载均衡器实现本部分讨论的所有模式。对于主动/主动部署，您还可以使用外部应用负载均衡器、TCP 代理或 SSL 代理（如果应用使用这些负载均衡选项支持的协议和端口）。

请考虑基于浮动 IP 地址的本地实现与所有基于负载均衡的模式之间的以下差异：

  • 故障切换时间：在本地环境中将 Keepalived 与免费 ARP 配对可能会在几秒钟内完成 IP 地址故障切换。在 Compute Engine 环境中，故障切换的平均恢复时间取决于您设置的参数。如果虚拟机实例或虚拟机实例服务失败，则平均故障切换时间流量取决于健康检查参数，例如 Check Interval 和 Unhealthy Threshold。将这些参数设置为其默认值后，故障切换通常需要 15-20 秒。您可以通过减少这些参数值来缩短时间。

    在 Compute Engine 中，可用区内或可用区间的故障切换所需的时间相同。

  • 协议和端口：在本地设置中，浮动 IP 地址接受所有流量。在内部直通式网络负载均衡器的内部转发规则中选择以下端口规范之一：

    • 按编号指定 1-5 个端口。
    • 指定 ALL 以转发所有端口上针对 TCP 或 UDP 的流量。
    • 通过具有相同 IP 地址的多个转发规则来转发将 TCP 和 UDP 同时使用的流量，或者将五个以上的端口与单个 IP 地址配合使用：
      • 只有 TCP 或 UDP 以及 1-5 个端口：使用一个转发规则。
      • TCP 和 UDP 以及 1-5 端口：使用多个转发规则。
      • 6 个或更多端口以及 TCP 或 UDP：使用多个转发规则。

  • 健康检查：在本地，您可以通过以下方式在机器上检查应用的响应能力：

主动/主动负载均衡

在主动/主动负载均衡模式中，虚拟机是内部直通网络负载均衡器的后端。您可以将内部直通网络负载均衡器 IP 地址用作虚拟 IP 地址。流量在两个后端实例之间均衡分配。属于同一会话的流量会进入会话亲和性设置中定义的同一后端实例。

如果应用仅使用基于 TCP 和 UDP 的协议，且不需要在机器之间进行故障切换，请使用主动/主动负载均衡模式。在应用可以根据请求本身的内容来响应请求的场景下使用该模式。如果存在不经常同步的机器状态，请勿使用该模式，例如在主要数据库或辅助数据库中。

下图显示了主动/主动负载均衡模式的实现：

内部客户端如何导航主动/主动负载均衡模式。

上图显示了内部客户端如何通过内部直通网络负载均衡器访问在两个虚拟机上运行的服务。这两个虚拟机属于一个实例组。

主动/主动负载均衡模式要求您的服务使用其中一个支持的健康检查协议来公开健康检查，以确保只有正常响应的虚拟机可收到流量。

如需查看此模式的完整实现示例，请参阅示例：在 GitHub 上使用 Terraform 进行部署的示例。

通过故障切换和应用公开的健康检查实现负载均衡

与主动/主动模式类似，“通过故障切换和应用公开的健康检查实现负载均衡”模式会将您的虚拟机用作内部直通网络负载均衡器的后端。它还使用内部直通网络负载均衡器 IP 地址作为虚拟 IP 地址。为了确保一次只有一个虚拟机收到流量，此模式会针对内部直通网络负载均衡器应用故障切换。

如果应用只有 TCP 或 UDP 流量，但不支持主动/主动部署，则建议使用此模式。应用此模式时，所有流量都会流向主要虚拟机或故障切换虚拟机。

下图显示了“通过故障切换和应用公开的健康检查实现负载均衡”模式：

内部客户端如何导航内部直通式网络负载均衡器后面的服务。

上图显示了内部客户端如何访问内部直通网络负载均衡器后面的服务。两个虚拟机位于单独的实例组中。将一个实例组设置为主要后端。将另一个实例组设置为内部直通网络负载均衡器的故障切换后端。

如果主要虚拟机上的服务无响应，则流量会切换到故障切换实例组。在主要虚拟机可再次响应后，流量会自动切换回主要后端服务。

如需查看此模式的完整实现示例，请参阅示例：在 GitHub 上使用 Terraform 进行部署的示例。

通过故障切换和检测信号公开的健康检查实现负载均衡

“通过故障切换和检测信号公开的健康检查实现负载均衡”模式和上述模式相同。不同之处在于，健康检查不是由应用本身公开，而是由两个虚拟机之间运行的检测信号机制公开。

下图显示了“通过故障切换和检测信号公开的健康检查实现负载均衡”模式：

内部客户端如何访问内部负载均衡器后面，在两个位于单独实例组中的虚拟机上运行的服务。

下图显示了内部客户端如何访问内部负载均衡器后台的服务。两个虚拟机位于单独的实例组中。将一个实例组设置为主要后端。将另一个实例组设置为内部直通网络负载均衡器的故障切换后端。Keepalived 用作虚拟机节点之间的检测信号机制。

虚拟机节点使用所选的检测信号机制交换有关服务状态的信息。每个虚拟机节点都会检查自己的状态，并将该状态传达给远程节点。根据本地节点的状态和远程节点收到的状态，一个节点被选为主要节点，另一个节点被选为备份节点。您可以使用此状态信息公开健康检查结果，以确保检测信号机制中视为主要节点的节点也会收到来自内部直通网络负载均衡器的流量。

例如，借助 Keepalived，您可以使用 notify_master、notify_backup 和 notify_fault 配置变量来调用脚本以更改健康检查状态。过渡到主要状态后（在 Keepalived 中，此状态称为 master），您可以启动一个侦听自定义 TCP 端口的应用。过渡到备份或故障状态时，您可以停止此应用。然后，如果此自定义 TCP 端口处于打开状态，则健康检查可以是执行成功的 TCP 健康检查。

此模式比使用故障切换和应用公开健康检查的模式更复杂。不过，它可以为您提供更多控制权。例如，在实行检测信号机制的过程中，您可以将其配置为立即或手动进行故障恢复。

如需查看使用 Keepalived 针对此模式完成的完整实现示例，请参阅示例：在 GitHub 上使用 Terraform 进行部署的示例。

使用 Google Cloud 路由的模式

如果您的应用使用基于 IPv4（而非 TCP 或 UDP）的协议，则可以根据路由将浮动 IP 地址迁移到模式。

在本部分中，只要提及路由，就是指属于 VPC 网络的 Google Cloud 路由。对静态路由的引用始终是指对 Google Cloud 上静态路由的引用。

使用其中一种模式，您可以为特定 IP 地址设置多个静态路由，并将不同实例用作下一个跃点。此 IP 地址将成为所有客户端使用的浮动 IP 地址。它必须位于所有 VPC 子网 IP 地址范围外部，因为静态路由无法替换现有子网路由。您必须针对目标实例启用 IP 地址转发功能。通过启用 IP 地址转发功能，您可以接受未分配给实例的 IP 地址（本例中为浮动 IP 地址）的流量。

如果您希望浮动 IP 地址路由可从对等互连 VPC 网络使用，请导出自定义路由以便浮动 IP 地址路由传播到所有对等 VPC 网络。

如需从通过 Cloud Interconnect 或 Cloud VPN 连接的本地网络建立连接，您需要使用自定义 IP 地址路由通告在本地通告浮动 IP 地址。

基于路由的模式与基于负载均衡的模式相比具有以下优势：

  • 协议和端口：基于路由的模式适用于发送到特定目标位置的所有流量。基于负载均衡的模式仅允许 TCP 和 UDP 流量。

基于路由的模式与基于负载均衡的模式相比具有以下缺点：

  • 健康检查：健康检查无法与 Google Cloud 路由关联。因此无论底层虚拟机服务的健康如何，系统都会使用路由。每当虚拟机运行时，即使服务健康状况不佳，路由也会将流量定向到实例。将自动修复政策关联至这些实例后，系统会在您指定的健康状况不佳时间段后替换这些实例。但是，一旦这些实例重启，流量就会立即恢复，即使在服务启动之前也是如此。如果健康状况不佳的实例仍在处理流量或正在重启，则此服务间隔可能会导致潜在的服务错误。
  • 故障切换时间：删除或停止虚拟机实例后，Compute Engine 会忽略指向此实例的任何静态路由。但是，由于没有对路由进行健康检查，因此只要实例仍然可用，Compute Engine 仍会使用静态路由。此外，停止实例也需要时间，因此其故障切换时间远远高于搭配基于负载均衡的模式使用的情况。
  • 仅限内部浮动 IP 地址：虽然您可以实现将负载均衡与外部直通网络负载均衡器搭配使用的模式，以创建外部浮动 IP 地址，但基于路由的模式仅适用于内部浮动 IP 地址。
  • 浮动 IP 地址选择：您只能将路由设置到不属于任何子网的内部浮动 IP 地址，无法在 Google Cloud 中覆盖子网路由。跟踪这些浮动 IP 地址，以免意外将其分配给其他网络。
  • 路由可达性：如需使内部浮动 IP 地址可通过本地网络或对等互连网络访问，您需要按照上述说明分配这些静态路由。

使用等价多路径 (ECMP) 路由

等价多路径 (ECMP) 路由模式类似于主动/主动负载均衡模式，流量在两个后端实例之间平均分配。当您使用 Google Cloud 静态路由时，ECMP 会通过使用五元组哈希值在所有路由候选项的下一个跃点之间分配流量来实现亲和性。

如需实现此模式，请创建两个优先级相同的静态路由，并将 Compute Engine 实例用作下一个跃点。

下图显示了 ECMP 路由模式的实现：

内部客户端如何使用两个 ECMP 路由之一访问服务。

上图显示了内部客户端如何使用两个路由之一访问服务，且下一个跃点指向实现该服务的虚拟机实例。

如果一个虚拟机上的服务无响应，则自动修复功能会尝试重新创建无响应的实例。在自动修复功能删除实例后，指向该实例的路由会在创建新实例之前变为非活跃状态。新实例存在后，系统会立即自动使用指向此实例的路由，并在实例之间平均分配流量。

ECMP 路由模式要求您的服务使用支持的协议来公开健康检查，以便自动修复功能可以自动替换无响应的虚拟机。

您可以在与本文档关联的 GitHub 代码库中找到使用 Terraform 针对此模式完成的实现示例。

使用不同的优先级路由

不同的优先级路由模式类似于上述模式，不同之处在于它使用不同的优先级静态路由，以便流量始终流向主要实例，除非该实例失败。

如需实现此模式，请遵循 ECMP 路由模式中的相同步骤。创建静态路由时，请为下一个跃点指向主实例的路由提供较低优先级的值（主要路由）。为下一个跃点指向辅助实例的实例提供更高优先级的值（辅助路由）。

下图显示了不同优先级路由模式的实现：访问服务的内部客户端如何根据网络情况使用主要路由或辅助路由。

上图显示了访问某一服务的内部客户端如何使用优先级值为 500 且指向虚拟机 1（正常情况下用作下一个跃点）的主要路由。优先级值为 1000 的第二个路由指向虚拟机 2（辅助虚拟机，用作下一个跃点）。

如果主要虚拟机上的服务无响应，则自动修复功能会尝试重新创建实例。在自动修复功能删除实例后，在其创建的新实例启动之前，以主要实例作为下一个跃点的主要路由将变为非活跃状态。然后，该模式将使用以辅助实例作为下一个跃点的路由。新的主要实例启动后，主要路由会再次变为活跃状态，并且所有流量都会流向主要实例。

与上述模式一样，不同的优先级路由模式要求您的服务使用支持的协议公开健康检查，以便自动修复功能可以自动替换无响应的虚拟机。

您可以在本文档附带的 GitHub 代码库中找到使用 Terraform 针对此模式完成的实现示例。

使用检测信号机制切换路由的下一个跃点

如果应用实现检测信号机制（如 Keepalived）以监控应用响应能力，您可以应用检测信号机制模式来更改静态路由的下一个跃点。在这种情况下，您只使用下一个跃点指向主要虚拟机实例的静态路由。在故障切换时，检测信号机制会将路由的下一个跃点指向辅助虚拟机。

下图显示了如何实现检测信号机制来切换路由的下一个跃点模式：

内部客户端如何访问服务以便主要虚拟机和辅助虚拟机在其中交换检测信号信息。

上图显示了内部客户端如何使用下一个跃点指向主要虚拟机的路由来访问服务。主要虚拟机通过 Keepalived 与辅助虚拟机交换检测信号信息。在故障切换时，Keepalived 会调用 Cloud Functions 函数，以使用 API 调用将下一个跃点指向辅助虚拟机。

节点使用所选检测信号机制相互交换服务状态的相关信息。每个虚拟机节点都会检查自己的状态，并将该状态传达给远程虚拟机节点。根据本地虚拟机节点的状态和远程节点收到的状态，一个虚拟机节点被选为主要节点，另一个虚拟机节点被选为备份节点。一旦节点成为主要节点，它会将浮动 IP 地址的路由的下一个跃点指向其自身。如果您使用 Keepalived，则可以使用 notify_master 配置变量来调用脚本，以通过 API 调用或 Google Cloud CLI 来替换静态路由。

用于切换路由的下一个跃点模式的检测信号机制不要求虚拟机加入实例组。如果您希望在失败时自动替换虚拟机，则可以将它们放入自动修复实例组。您也可以手动修复并重新创建无响应的虚拟机。

对故障切换调用以下过程可确保最大限度地减少故障切换时间，因为在第 1 步中完成单个 API 调用后，流量会进行故障切换：

  1. 创建新的浮动路由，将浮动 IP 地址作为目标位置并将新的主要实例作为下一个跃点。新路由应具有与原始路由不同的路由名称以及低于原始路由的路由优先级（例如 400）。
  2. 删除通往旧的主要虚拟机的原始路由。
  3. 创建一个名称和优先级与您刚删除的路由相同的路由。将其指向作为下一个跃点的新主要虚拟机。
  4. 删除您创建的新静态路由。您不需要使用它来确保流量流向新的主要虚拟机。

由于原始路由将被替换，因此即使存在拆分网络，一次也只能让一个路由处于活动状态。

使用检测信号机制来切换路由优先级模式（而不是其他基于路由的模式）可以减少故障切换时间。您不必通过自动修复功能来删除和替换虚拟机即可进行故障切换。此外，它还可让您更好地控制在原始主要服务器再次响应后如何故障切换至原始主要服务器。

该模式的一个缺点是您必须自行管理检测信号机制。管理该机制可能会增加复杂性。另一个缺点是您必须授予相应权限，用以将全局路由表更改为运行检测信号进程的虚拟机或从检测信号进程调用的无服务器函数。将全局路由表更改为无服务器函数更安全，因为它可以减少授予虚拟机的权限范围。然而，这种方法实现起来更复杂。

如需查看使用 Keepalived 针对此模式完成的完整实现示例，请参阅示例：在 GitHub 上使用 Terraform 进行部署的示例。

使用自动修复的模式

根据恢复时间要求，在使用 Compute Engine 时，迁移到单个虚拟机实例可能是可行的方案。即使在本地使用多台使用浮动 IP 地址的服务器，也是如此。 有时，即使虚拟机数量减少，也可以使用此模式，因为您可以在几秒钟或几分钟内创建新的 Compute Engine 实例，而本地故障通常需要数小时甚至数天才能修复。

使用自动修复单实例

使用此模式，您依靠虚拟机实例组中的自动修复机制来自动替换有故障的虚拟机实例。应用会公开健康检查，并且在应用健康状况不佳时，自动修复功能会自动替换虚拟机。

下图展示了自动修复单实例模式的实现：

内部客户端如何直接连接至 Compute Engine 实例。

上图显示了内部客户端如何直接连接至布置在大小为 1 且启用了自动修复功能的代管式实例组中的 Compute Engine 实例。

与使用负载均衡功能的模式相比，自动修复单实例模式具有以下优势：

  • 流量分配：只有一个实例，因此该实例始终接收所有流量。
  • 易用性：只有一个实例，因此该模式实现起来最不复杂。
  • 节省费用：相比两个虚拟机实例，使用单个虚拟机实例可以将费用减半。

不过，该模式具有以下缺点：

  • 故障切换时间：此过程比基于负载均衡的模式慢得多。在健康检查检测到机器故障后，删除失败的实例并重新创建实例至少需要 1 分钟，但通常需要更长的时间。此模式在生产环境中不常见。但是，对于某些内部或实验性服务，故障切换时间可能已足够
  • 对可用区故障作出反应：大小为 1 的代管式实例组在可用区故障后无效。如需对可用区故障作出反应，请考虑在服务失败时添加 Cloud Monitoring 提醒，并在发生可用区故障时在另一个可用区中创建实例组。由于在此情况下您无法使用相同的 IP 地址，因此请使用 Cloud DNS 专用可用区对虚拟机进行寻址，并将 DNS 名称切换为新的 IP 地址。

您可以在 GitHub 代码库中找到使用 Terraform 针对此模式完成的实现示例。

后续步骤