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