Azure Site Recovery 通过将 VM 复制到另一个 Azure 区域，为 Azure VM 启用灾难恢复。 如果发生中断，则会故障转移到主要区域，当情况恢复正常时，它会故障回复到主要区域。
在故障转移期间，可能想要将 IP 地址保留在与源区域相同的目标区域中：
- 默认情况下，为 Azure VM 启动灾难恢复时，Site Recovery 将根据源资源设置创建目标资源。 对于配置了静态 IP 地址的 Azure VM，Site Recovery 会尝试为目标 VM 预配相同的 IP 地址（如果可用）。 有关 Site Recovery 如何处理寻址的完整介绍，请参阅本文。
- 对于简单的应用程序，默认配置就足够了。 对于更复杂的应用，可能需要预配其他资源，以确保连接在故障转移后按预期工作。
本文提供在较复杂的示例方案中保留 IP 地址的一些示例。 示例包括：
- 针对在 Azure 中运行所有资源的公司的故障转移
- 针对使用混合部署并同时在本地和 Azure 中运行资源的公司的故障转移
Azure 中的资源：完全故障转移
公司 A 在 Azure 中运行其所有应用。
在故障转移之前
以下是故障转移之前的体系结构。
- 公司 A 在源和目标 Azure 区域中具有相同的网络和子网。
- 为了降低恢复时间目标（RTO），公司在 SQL Server Always On、域控制器和其他服务中使用副本节点。 这些副本节点位于目标区域中的不同 VNet 中，因此可以在源区域和目标区域之间建立 VPN 站点到站点连接。 如果源和目标使用相同的 IP 地址空间，则无法建立此连接。
- 故障转移前，网络体系结构如下所示：
主要区域是 Azure 中国东部
中国东部有一个 VNet（源 VNet），地址空间为 10.1.0.0/16。
中国东部地区的工作负荷分布在三个虚拟网络 (VNet) 子网中。
- 子网 1：10.1.1.0/24
- 子网 2：10.1.2.0/24
- 子网 3：10.1.3.0/24
次要（目标）区域是 Azure 中国北部
- 中国北部的恢复 VNet（恢复 VNet）与 源 VNet 相同。
- 中国北部有一个额外的 VNet（Azure VNet），地址空间为 10.2.0.0/16。
- Azure VNet 包含地址空间为 10.2.4.0/24 的子网（子网 4）。
- SQL Server Always On、域控制器和其他服务的副本节点位于 子网 4 中。
源 VNet 和 Azure VNet 使用 VPN 站点到站点连接进行连接。
恢复 VNet 未连接到任何其他虚拟网络。
公司 A 分配并验证复制项的目标 IP 地址。 目标 IP 地址与每个 VM 的源 IP 地址相同。
故障转移后
如果源区域发生故障，公司 A 可将其所有资源故障转移到目标区域。
- 通过使用故障转移之前已到位的目标 IP 地址，公司 A 可以协调故障转移，并在 恢复 VNet 和 Azure VNet 之间故障转移后自动建立连接。 下图演示了此过程。
- 根据应用要求，可以在故障转移之前、期间（作为中间步骤）或之后在目标区域中的两个 VNet（恢复 VNet 和 Azure VNet）之间建立连接。
Azure 中的资源：独立应用故障转移
可能需要在应用层面进行故障转移。 例如，当位于专用子网的特定应用程序或应用层发生故障时进行切换。
- 在此方案中，尽管可以保留 IP 地址，但通常不建议这样做，因为这将增加连接不一致的可能性。 你还将失去与同一 Azure VNet 中的其他子网的子网连接。
- 对子网级别应用执行故障转移的更好方法是：使用不同的目标 IP 地址进行故障转移（如果需要与源 VNet 上的其他子网建立连接），或者在源区域中将每个应用隔离在其自己的专用 VNet 中。 使用后一种方法可以在源区域中的网络之间建立连接性，并且在切换到目标区域时可以实现相同行为。
在此示例中，公司 A 将源区域中的应用放置在专用 VNet 中，并在这些 VNet 之间建立连接。 借助此设计，他们可以执行独立应用故障转移，并在目标网络中保留源专用 IP 地址。
在故障转移之前
故障转移前，系统架构如下：
您在 Azure 中国东部主区域托管应用程序虚拟机：
- App1 VM 位于 VNet 源 VNet 1：10.1.0.0/16 中。
- App2 VM 位于 VNet 源 VNet 2：10.2.0.0/16 中。
- 源 VNet 1 包含两个子网。
- 源 VNet 2 包含两个子网。
使用 Azure 中国北部作为次要（目标）区域。
- 中国北部有恢复 VNet（恢复 VNet 1 和 恢复 VNet 2），与源 VNet 1 和 源 VNet 2相同。
- 恢复 VNet 1 和 恢复 VNet 2 各有两个子网，这些子网与 源 VNet 1 和 源 VNet 2 中的子网匹配。
- 中国北部有一个额外的 VNet（Azure VNet），地址空间为 10.3.0.0/16。
- Azure VNet 包含地址空间为 10.3.4.0/24 的子网（子网 4）。
- SQL Server Always On、域控制器和其他服务的副本节点位于 子网 4 中。
- 中国北部有恢复 VNet（恢复 VNet 1 和 恢复 VNet 2），与源 VNet 1 和 源 VNet 2相同。
创建多个站点到站点 VPN 连接：
- 源 VNet 1 和 Azure VNet
- 源 VNet 2 和 Azure VNet
- 源 VNet 1 和源 VNet 2 通过站点到站点 VPN 进行连接
恢复 VNet 1 和恢复 VNet 2 没有连接到任何其他 VNet。
公司 A 在恢复 VNet 1 和恢复 VNet 2 上配置 VPN 网关，以减少 RTO。
若要减少恢复时间目标（RTO），请在故障转移前在 恢复 VNet1 和 恢复 VNet2 上配置 VPN 网关。
故障转移后
如果发生中断或影响 源 VNet 2 中单个应用的问题（在本示例中）， 公司 A 可以恢复受影响的应用，如下所示：
- 断开源 VNet1 与源 VNet2，以及源 VNet2 与 Azure VNet 之间的 VPN 连接。
- 建立在 源 VNet1 与 恢复 VNet2 之间的 VPN 连接，以及在 恢复 VNet2 与 Azure VNet 之间的 VPN 连接。
- 将源 VNet2 中的 VM 故障转移到恢复 VNet2。
- 可以展开此示例以包含更多应用程序和网络连接。 在从源故障转移到目标时，尽可能遵循相似的连接模型。
- VPN 网关使用公共 IP 地址和网关跃点建立连接。 如果不想使用公共 IP 地址，或希望避免额外的跃点，可以使用 Azure VNet 对等互连在受支持的 Azure 区域之间将虚拟网络对等互连。
混合资源：完全故障转移
在此方案中，公司 B 实行混合部署，其在 Azure 中运行一部分应用程序基础结构，并在本地运行剩余的基础结构。
在故障转移之前
下面是故障转移前网络体系结构的外观。
在 Azure 中国东部托管应用程序虚拟机。
中国东部有一个 VNet（源 VNet），地址空间为 10.1.0.0/16。
- 中国东部地区的工作负荷在 源 VNet 中分布在三个子网之间：
- 子网 1：10.1.1.0/24
- 子网 2：10.1.2.0/24
- 子网 3：10.1.3.0/24（使用地址空间为 10.1.0.0/16 的 Azure 虚拟网络）。 此虚拟网络名为“源 VNet”
- 中国东部地区的工作负荷在 源 VNet 中分布在三个子网之间：
次要（目标）区域是 Azure 中国北部：
- 中国北部的恢复 VNet（恢复 VNet）与 源 VNet 相同。
使用 Azure ExpressRoute 或站点到站点 VPN 将中国东部的 VM 连接到本地数据中心。
为了减少 RTO，在故障转移之前，公司 B 在 Azure 中国北部的 恢复 VNet 上预配网关。
公司 B 分配并验证复制 VM 的目标 IP 地址。 每个 VM 的目标 IP 地址均与源 IP 地址相同。
故障转移后
如果发生源区域的故障，公司 B 可以将其所有资源切换至目标区域。
通过使用故障转移之前已到位的目标 IP 地址，公司 B 可以协调故障转移，并在 恢复 VNet 和 Azure VNet 之间故障转移后自动建立连接。
根据应用要求，可以在故障转移之前、期间（作为中间步骤）或之后在目标区域中的两个 VNet（恢复 VNet 和 Azure VNet）之间建立连接。 该公司可以使用恢复计划来指定何时建立连接。
在建立 Azure 中国北部与本地数据中心之间的连接之前，请断开 Azure 中国东部与本地数据中心之间的原始连接。
在故障转移后，重新配置内部路由，使其指向目标区域和网关。
混合资源：独立应用故障转移
公司 B 无法在子网级别故障转移隔离应用。 存在此限制，因为源和恢复 VNet 上的地址空间相同，并且原始源到本地连接处于活动状态。
- 为了提高应用复原能力，公司 B 需要将每个应用置于其自己的专用 Azure VNet 中。
- 通过将每个应用放置在单独的 VNet 中，公司 B 可以对隔离的应用进行故障转移，并将源连接路由到目标区域。
后续步骤
了解恢复计划。