本文概述了故障转移和故障回复如何在云环境中运作。 但是，要了解故障转移，应首先了解冗余和复制。 要在继续本文之前了解这些概念，请参阅冗余、复制和备份。
维护应用程序和数据副本的冗余副本的一个常见原因是为了能够执行故障转移。 通过故障转移，可以将流量和请求从不正常的实例重定向到正常的实例。 然后，一旦原始实例再次正常运行，可以执行故障回复以返回到原始配置。
在故障转移上下文中，实例可以是单个组件（例如数据库），也可以是组成某个区域中服务部署的多个组件的集合。 在整个解决方案中，可以采用不同方式在不同情况中故障转移该解决方案的不同部分。
为故障转移和故障回复配置的组件或组件集合需要多个实例。 每个实例都采用特定角色：
- 主实例或活动实例会主动执行工作，例如服务来自客户端的传入请求。 通常一次只有一个主实例。
- 辅助或被动实例处于非活动状态，但可以根据需要切换到主要实例。 可能有多个辅助实例。
可以通过多种方式配置被动实例。 每种方法都涉及恢复时间与其他因素之间的权衡，例如成本和运营复杂性：
- 热备用，旨在随时接受生产流量。
- 暖备用，设计为几乎准备好接受生产流量，但可能需要进行一些配置更改或缩放操作才能接受流量。
- 试点轻型备用，部分部署在最少的配置中，需要完成大量准备，然后才能接受生产流量。
- 冷备用，可能根本不会部署，并且依赖于要部署的组件，然后才能接受生产流量。
提示
某些解决方案旨在使用主动-主动方法，这意味着多个实例都为请求提供服务。 主动-主动系统不需要故障转移，因为所有实例都在随时主动处理请求。
不同的情况需要不同的故障转移策略。 为了说明这些可能的策略，请考虑一个示例解决方案，该解决方案由从数据库访问数据的应用程序组成。 可以通过创建应用程序服务器的冗余副本和数据库的多个副本来配置故障转移解决方案。 接下来，需要进行以下配置：
- 通过在 Azure 区域内的不同可用性区域中放置副本和复制品来实现区域冗余。
- 使用全局负载均衡器在区域之间故障转移的异地冗余。
下面是一个简化的关系图，演示了常规操作中的整体体系结构：
在该解决方案中，不同的情况可能触发不同的故障转移事件。 其中每个都对应于故障转移范围，该范围表示故障转移的组件的粒度：
当活动数据库副本不可用时，可能会发生数据库副本故障转移。 被动副本被提升为活动副本。 通常，应用程序可以快速将请求重新路由到新的活动副本：
如果完整的可用性区域遇到服务中断，则可能会出现可用性区域故障转移。 这种类型的服务中断要求将所有流量路由到剩余区域中的 Web 服务器，并确保存活区域中的数据库副本成为活动副本（如果尚未成为）：
如果整个主要 Azure 区域发生灾难性损失，则可能会发生区域故障转移。
虽然其中每个范围都提供了一种故障转移类型，但它们可能具有不同的故障转移要求和流程。 此外，Azure 可能负责某些故障转移范围，例如使用区域冗余服务时，而你可能负责在更广泛的范围内进行故障转移，例如在 Azure 区域之间进行故障转移。
业务连续性规划的一部分是设计故障转移策略，包括可以故障转移的不同范围。
通常，业务连续性计划应包括可用性区域中或可用性区域之间的自动故障转移过程。 这种类型的故障转移构成了高可用性策略的一部分。 例如，如果数据库的活动副本失败，则自动化过程可以提升被动副本成为活动副本。 然后，Web 服务器与新的活动副本通信。 同样，如果可用性区域发生故障，许多解决方案都会使用剩余区域自动恢复。
在灾难方案中，会使用不同的故障转移过程，例如在可能性不大但发生完全区域中断的情况下。 如果发生区域中断，可以将传入的 Web 请求切换为使用次要区域，并触发数据库到次要区域中的副本的故障转移。
请记住，在业务连续性规划中包括故障转移过程需要执行更详细的设计和测试。 有关详细信息，请参阅什么是业务连续性、高可用性和灾难恢复？。
计划外故障转移是在组件中断期间执行的故障转移，以便可以使用另一个实例还原服务。 计划外故障转移有时会导致故障时间或数据丢失，具体取决于解决方案的设计方式。 计划外故障转移需要检测故障并决定何时触发故障转移。
相比之下，计划内的故障转移是主动触发的故障转移。 你可能会在预期发生某些事情时执行此操作，例如要进行修补和重新启动的虚拟机。 计划的故障转移可能会降低故障时间和数据丢失的容忍度，因为它们是常规维护过程的一部分。
故障转移通常由以下步骤组成，这些步骤可以手动执行，也可以由自动化系统执行。 这些步骤的具体详细信息取决于特定系统。
检测故障（仅限计划外故障转移）。 自动故障转移需要在实例不可用时有一个检测机制，这通常是基于某种运行状况检查。 不同服务以不同方式定义其运行状况。 例如，某些服务会主动在实例之间发送检测信号事件。 其他组件需要单独的组件定期探测每个实例。 运行状况监视器通常需要一段时间才能检测到实例已失败，而且通常很有必要设置一个宽限期，以防实例只是处于繁忙状态而无法做出响应。
选择故障转移。 在某些时候，将决定执行故障转移。 可以通过自动化工具或手动做出决策。 组织的风险容忍度可能会影响做出此决定的速度。 如果你对风险的容忍度较低，你可能会选择快速故障转移（如果有问题的迹象）。 如果你有更高的风险容忍度，你可能会选择等待，看看问题是否可以在故障转移之前解决。
选择新的主实例。 其余实例中的一个应升级为新的主实例。
在某些情况下，你可能已经预定义了哪个实例应成为新的主实例，或者可能只有一个要切换到的实例。
在其他情况下，系统会通过一个自动化流程选择新的主实例。 分布式计算中使用了许多共识算法，包括用于领导者选举的算法。 这些算法在相关服务（如数据库）中实现。 在某些系统中，必须让每个实例了解新的主副本，因此会自动向每个副本公布所选内容的结果。
重定向请求。 配置环境，以便将请求定向到正常的实例或新的主实例。
要实现此目的，可能需要更新其他系统，以便他们知道在何处发送请求。 这可能涉及更新负载均衡系统以排除不正常的实例。 在其他情况下，域名系统 (DNS) 通常用于将请求发送到系统的活动实例。 在故障转移过程中，通常需要更新 DNS 记录，以便将请求路由到新的主实例。 “生存时间”(TTL) 是 DNS 中的一个概念，它指示客户端应该检查更新 DNS 记录的频率。 如果 TTL 设置为一个较长的值，客户端可能需要一段时间才能收到有关故障转移的信息，并且它们可能会继续向旧的主实例发送请求。
由于故障转移过程可能有延迟，因此请务必规划故障转移过程，以满足故障时间（恢复点目标或 RTO）和数据丢失（恢复点目标或 RPO）的要求。 要了解详细信息，请参阅什么是业务连续性、高可用性和灾难恢复？。
故障回复是恢复流量并将流量重定向回原始主实例的过程。
在某些情况下，根本不需要故障回复，因为每个实例同样能够充当主实例。 但是，在某些情况下，必须进行故障回复，例如，需要从特定 Azure 区域运行应用程序，并在区域性中断期间暂时故障转移到另一个区域。
有时，故障回复的处理方式与故障转移相同。 但是，故障回复可能比故障转移更为复杂，原因有多种：
数据同步问题。 在常规故障转移期间和之后，以前的主实例可能仍执行某些工作或将某些数据写入数据存储。 故障回复过程的一部分是确保解决方案中的数据一致性和完整性，包括管理主实例和辅助实例之间的任何冲突或重复。
数据同步问题通常需要人工干预。 如果不需要冲突的数据，可以选择重置数据库或其他状态。
修正步骤。 如果在发生故障转移之前在主实例上尝试了任何修正步骤，它们可能已使主实例处于未知状态。
如果主实例可能存在状态不一致的风险，你可能需要销毁并重新部署主实例，确保其处于已知良好状态后方可执行故障回复。
额外的故障时间。 由于需要重新配置或还原数据一致性的操作，故障回复过程中的故障时间可能比故障转移期间的故障时间更长。
可以通过在维护时段内运行故障回复进程或提前建议用户更改来缓解此问题。 此外，你可能能够在系统处于联机状态时执行某些准备操作，并最大程度地减少所需的故障时间。
风险容忍度。 如果由于服务中断而发生故障转移，则组织对故障回复期间的故障时间或其他风险的容忍度可能会降低。
业务利益干系人应随时了解整个流程的情况，并应充分了解故障回复的需求和故障回复过程的后果。 可以协商适当的时间来进行更改。
了解一般故障转移的工作原理很重要，但需要注意的是，每个 Azure 服务可能以不同的方式进行故障转移和故障回复。 有关特定的 Azure 服务如何可靠工作的信息，请参阅每个服务的可靠性指南。
许多 Azure 服务会自动处理某些类型的故障转移。 例如，使用配置为区域冗余的 Azure 服务时，Azure 会自动在可用性区域之间执行故障转移。 要了解详细信息，请参阅什么是可用性区域？和 Azure 服务可靠性指南。
如果使用虚拟机，Azure Site Recovery 会在可用性区域之间复制虚拟机及其磁盘或将它们复制到另一个 Azure 区域，并且可以为你执行故障转移。
设计自己的将多个 Azure 服务组合在一起的解决方案时，故障转移要求可能会变得更加复杂。 假设你正在设计具有应用程序层和数据库的解决方案，并且想要创建多区域主动/被动体系结构。 在主要区域的服务中断期间，应用程序和数据库必须同时故障转移到次要区域。 根据所使用的确切服务，可能需要计划你自己的故障转移方法，以在每个区域中的部署之间切换。 Azure 通过 Azure Front Door 和 Azure 流量管理器提供全局流量路由和负载均衡，可以选择满足故障转移要求的技术。 每个服务都支持监视应用程序每个区域实例的运行状况，并且可以将其配置为自动将流量重新路由到正常实例。
- 了解可靠性的共同责任。
- 了解 Azure 架构良好的框架中高可用性多区域设计的建议。