本文档介绍有状态应用、健康检查代理以及应用专用的地区级控制层面（通过部署地区永久性磁盘来监控和编排区域性故障切换）的行为和它们之间的交互。
本文档面向应用开发者，是使用地区永久性磁盘的高可用性选项的后续文章，对使用地区永久性磁盘构建高可用性数据库服务部分中介绍的设计和架构进行了扩展。我们建议您先阅读该文档，尤其是有关设计注意事项和费用比较、性能和弹性的部分。
无状态应用通过在另一个 Compute Engine 区域运行至少一个辅助虚拟机实例来提高弹性。如果主虚拟机实例发生故障，应用将继续在辅助虚拟机实例上运行。有状态应用可将其应用状态保存到区域永久性磁盘，以便在虚拟机实例重启时恢复其状态。为了获得弹性，有状态应用还必须将应用状态保存到辅助虚拟机实例。
下图展示了一个跨两个区域复制的典型双节点有状态应用。应用在每个可用区中都有一个可用区永久性磁盘来捕获应用状态，并且虚拟机实例之间有网络连接，用于在节点之间同步应用状态更改。
添加地区永久性磁盘
同步有状态应用的应用状态的另一种方法是添加地区永久性磁盘。当应用将其应用状态写入地区永久性磁盘时，Google Cloud 会自动将块存储与另一个区域同步。地区永久性磁盘存储还有助于确保在两个区域中一次只有一个虚拟机实例挂接到地区永久性磁盘。
下图显示了有状态数据库应用的架构。
如上图所示，在两个区域中部署了两个应用虚拟机实例，即一个主虚拟机实例和一个辅助虚拟机实例。除了将地区永久性磁盘用于应用状态存储之外，现在还有一个额外的实体，即应用专用的地区级控制层面。应用专用的区域级控制平面决定哪个虚拟机实例挂接区域永久性磁盘，以及哪个虚拟机实例是当前主虚拟机实例。此架构是主动-被动配置，因为只有主虚拟机实例才能将应用状态提交到区域永久性磁盘。
虚拟机实例和有状态应用
上述架构图说明了一个主动-被动热数据库应用。您也可以使用以下配置：
- 如果恢复时间目标 (RTO) 可以承受启动辅助虚拟机实例所需的额外延迟时间，那么您可以仅运行主动虚拟机实例，从而节省 Compute Engine 费用。在故障切换中，应用专用的区域级控制平面会启动辅助虚拟机实例并挂接区域永久性磁盘。
- 将其进度以检查点的形式保存到地区永久性磁盘的批处理或流处理工作负载。在故障切换中，应用会从最后一个检查点继续处理。
管理虚拟机实例启动
由于一个虚拟机实例一次只能挂接一个地区永久性磁盘，因此您需要系统地启动虚拟机实例并挂接地区永久性磁盘。一种最佳做法是将虚拟机实例和应用启动与地区永久性磁盘挂接分离。虚拟机实例的启动脚本不应启动地区永久性磁盘挂接。相反，启动脚本应启动健康检查代理，并等待挂接地区永久性磁盘。
虚拟机实例在启动时需要执行以下顺序步骤：
- 启动健康检查代理。
- 等待挂接地区永久性磁盘。
- 地区永久性磁盘挂接后，装载文件系统。
- 装载文件系统后，启动应用。
这些步骤涵盖了系统启动，但此外还有故障切换。在故障切换期间，地区永久性磁盘会被强制挂接到辅助虚拟机实例。地区永久性磁盘也被强制从主虚拟机实例中移除，对文件系统的 I/O 操作会失败。此时，您需要关停或重启虚拟机实例。
运行健康检查代理和健康检查
如上一部分所述，虚拟机实例会等待地区永久性磁盘挂接，然后才启动应用。应用专用的地区级控制层面会挂接地区永久性磁盘，但只会挂接到等待挂接磁盘的虚拟机实例。挂接磁盘时，应用专用的控制层面会监控应用的健康状况，并在应用健康状况不佳时启动故障切换。
每个虚拟机实例都具有以下状态之一：
- 下一个
- 正在开始
- 等待磁盘
- 应用运行
健康检查代理会报告虚拟机实例的当前状态。您可以运行两个二进制健康检查，而不是通过单个健康检查报告这两个状态。如果虚拟机实例准备好挂接地区永久性磁盘，或者地区永久性磁盘已挂接并且可写，则虚拟机实例健康检查将报告健康状况良好。如果应用正在运行并且能够将应用状态写入地区永久性磁盘，则应用健康检查会报告健康状况良好状态。
使用两个二进制健康检查有几个优点：
- 您可以使用 Compute Engine 代管式健康检查服务，该服务会轮询健康检查代理，并通过阈值计数解决暂时性错误。
- 代管式实例组 (MIG) 可以监控实例健康检查和自动修复健康状况不佳的虚拟机实例。
- 负载均衡器可以监控应用的健康检查，并将流量路由到活动的应用实例。
您可以通过降低健康检查报告频率或提高从一个级别切换到另一个级别所需的重复信号的阈值，来防止系统对暂时性故障作出反应。这两种方法都会延迟系统响应中断的时间，并延长恢复时间。通过测试并测量这些参数，您可以调整健康检查参数以平衡系统恢复时间。
了解应用专用的地区级控制层面
架构中的最后一部分是应用专用的地区级控制层面，它负责以下两个功能：
- 管理主虚拟机实例和辅助虚拟机实例的生命周期。
- 通过监控应用健康检查的状态来确定是否需要故障切换。
如果需要故障切换，应用专用的地区级控制层面使用以下步骤来编排故障切换：
- 检查辅助虚拟机实例是否正在运行，以及是否正在等待地区永久性磁盘挂接。
- 强制将地区永久性磁盘挂接到辅助虚拟机实例。
- 监控并重启发生故障的主虚拟机实例。当虚拟机实例重启时，控制层面会根据需要启动故障恢复。
应用专用的地区级控制层面本身必须在应用运行的两个区域中具有高可用性。在本地数据中心中，通常通过部署其他服务器来构建仲裁、确定哪个虚拟机实例是主虚拟机实例以及编排故障切换，从而实现高可用性 (HA)。此方法通常使用 HA 监控工具，例如 Heartbeat、Pacemaker 或 Keepalived。
虽然您可以在云端的任何位置使用应用专用的地区级控制层面，但 Google Cloud 提供了以下代管式和地区可用的服务来简化此方法的实现：
- 易于管理和部署的 App Engine、Cloud Run 和 Cloud Functions 等 Google Cloud 无服务器产品。
- 可分流应用实例的监控的代管式健康检查。
- 用于管理服务器实例生命周期的代管式实例组。
下图展示了将 Cloud Functions 用于应用专用的区域级控制平面，同时还使用了有状态代管式实例组和代管式健康检查。
上图显示了应用的两个虚拟机实例，即主虚拟机实例和辅助虚拟机实例。每个虚拟机实例在不同的区域运行，并由有状态的地区级 MIG 管理。一个地区永久性磁盘在相同的两个区域可用。有两个代管式健康检查服务在运行。一个代管式健康检查服务监控虚拟机实例健康状况，并由有状态 MIG 使用。另一个健康检查服务监控应用的健康状况，并由负载均衡器的目标池使用。
应用专用的地区级控制层面与目标池应用运行状况和有状态的地区级 MIG 进行交互，以监控应用状态并启动地区永久性磁盘到当前运行状况良好的虚拟机实例的挂接。
后续步骤
- 阅读 Google Kubernetes Engine 中的预配区域级永久性磁盘。
- 如需了解如何调整本地 HA 工具以在 Google Cloud 中使用，请参阅使用浮动 IP 地址的模式。
- 探索有关 Google Cloud 的参考架构、图表和最佳实践。查看我们的 Cloud Architecture Center。