Azure Site Recovery 概述
Azure Site Recovery 不仅仅是一种帮助你在系统中断时恢复的工具。 Azure Site Recovery 可在主站点和辅助站点之间复制工作负载。 Site Recovery 还可用于将 VM 从本地基础结构迁移到 Azure。
例如，要保护工作负载免受地震影响，首要任务是查看公司的当前业务连续性和灾难恢复 (BCDR) 计划。 为需要保护的系统确定不同的恢复目标和范围。
在本单元中，你将调查 Azure Site Recovery 是如何帮助实现这些目标的，又是如何在发生灾难时对资源进行故障转移和恢复的。
业务连续性和灾难恢复
丢失服务可能会给员工和用户带来困扰。 系统不可用的每一秒都可能造成公司收入损失。 你的公司还可能因违反你所提供服务的可用性协议而面临经济处罚。
BCDR 计划是公司起草的正式文档，其中涵盖发生灾难或大规模系统中断时应采取的范围和操作。 每种中断情况都按其特点进行了评估。 例如，当整个数据中心断电时，会实施 BCDR 计划。
在此示例场景中，发生了地震，受损的通信线路导致数据中心无法使用并需要修复。 这种规模的灾难可能会导致服务中断几天（而不是几小时），因此必须调用完整的 BCDR 计划以恢复服务。
在 BCDR 计划中，确定应用程序的恢复时间目标 (RTO) 和恢复点目标 (RPO)。 这两个目标共同有助于确定你的业务在没有指定服务情况下可以运行的最长时间，进而确定数据恢复流程。 让我们更详细地了解每一项。
恢复时间目标
RTO 是一个度量值，指示在灾难发生之后、必须恢复正常服务之前，你的业务可维持的最长时间，以避免与连续性中断相关的不可接受的后果。 假设 RTO 为 12 小时，这意味着在业务核心服务未运行的情况下，可以持续运营 12 小时。 如果故障时间延长，你的业务将受到严重损害。
恢复点目标
RPO 是一个度量值，指示灾难发生之后可接受的最大数据丢失量。 公司通常可以决定备份频率：每 24 小时一次、每 12 小时一次，甚至实时备份。 如果发生灾难，总会丢失一些数据。
例如，如果每 24 小时在午夜执行一次备份，而灾难发生在第二天上午 9:00 点，则会丢失 9 个小时的数据。 如果公司的 RPO 为 12 小时，那么情况还好，因为只过去了九个小时。 如果 RPO 为 4 小时，则会出现问题，对业务产生损害。
什么是 Azure Site Recovery？
Azure Site Recovery 可支持 BCDR 计划，因为它可以将工作负荷从主站点复制到辅助站点。 当主站点出现问题时，可以自动调用 Site Recovery，将受保护的虚拟机复制到另一个位置。 故障转移可以从本地到 Azure，也可以从一个 Azure 区域到另一个 Azure 区域。
Azure Site Recovery 的一些重要功能包括：
- 集中管理：通过 Azure 门户，可以对复制进行设置、管理和故障转移，还可以调用故障回复。
- 本地虚拟机复制：根据需要，可将本地虚拟机复制到 Azure 或辅助本地数据中心。
- Azure 虚拟机复制：可以将 Azure 虚拟机从一个区域复制到另一个区域。
- 故障转移期间的应用一致性：在复制期间，通过使用恢复点和应用程序一致的快照，虚拟机将始终保持一致状态。
- 灵活的故障转移：可以以测试形式按需运行故障转移，也可以在实际灾难发生时触发故障转移。 可以运行测试来模拟灾难恢复场景，而不会中断实时服务。
- 网络集成：Site Recovery 可以在复制和灾难恢复场景中实现网络管理。 包含保留 IP 地址和负载均衡器，因此虚拟机可以在新位置运行。
设置 Azure Site Recovery
要启用 Azure Site Recovery，必须设置多个组件：
- 网络：使用复制的虚拟机需要使用有效的 Azure 虚拟网络。
- 恢复服务保管库：Azure 订阅中，在运行故障转移时存储迁移的 VM 的保管库。 保管库还包含复制策略，以及复制和故障转移的源和目标位置。
- 凭据：用于 Azure 的凭据必须具有虚拟机参与者和 Site Recovery 参与者角色，从而允许修改 Site Recovery 连接到的 VM 和存储的权限。
- 配置服务器：在故障转移和复制过程中，本地 VMware 服务器可实现多种角色。 以开放虚拟机设备 (OVA) 的形式从 Microsoft Azure 门户获取它，以便轻松部署。 配置服务器包括：
- 进程服务器：此服务器充当用于复制流量的网关。 它将缓存、压缩和加密流量，然后通过 WAN 将其发送到 Azure。 进程服务器还会将移动服务安装到故障转移和复制的所有目标物理计算机和虚拟机上。
- 主目标服务器：在从 Azure 进行故障回复期间，此计算机会处理复制过程。
重要
要从 Azure 故障回复到本地环境，即使只想将物理计算机复制到 Azure，具有配置服务器的 VMware vCenter 也必须是可用状态。 不能故障回复到物理服务器。
复制过程
设置必备任务后，即可开始复制计算机。 它们是根据已设定的复制策略进行复制的。 在首次复制的初始阶段，会将服务器数据复制到 Azure 存储。 初始复制完成后，进行第二次复制。 这次会将对虚拟机的增量更改复制到 Azure。
测试和监视故障转移
为灾难恢复设置好环境后，请测试环境，以确保配置正确，确保一切按预期正常运行。 在独立的 VM 上执行灾难恢复演练，以测试配置。 最佳做法是使用独立网络进行测试，以免实时服务中断。
尝试恢复演练的第一个任务是在 Azure 门户的“受保护的项”部分中验证测试虚拟机属性。 可从“复制的项”窗格中查看最新的恢复点。 在“计算与网络”部分中，可以根据需要调整虚拟机名称、资源组、目标大小、可用性集和磁盘设置。
可以从 Azure 门户的“设置”>“复制的项”部分启动恢复演练。 选择目标虚拟机，然后为最近处理的恢复点选择“测试故障转移”菜单项。 在同一菜单中选择 Azure 网络。 要启动恢复作业，请在网络选择屏幕上选择“确定”。
恢复作业的状态和复制的虚拟机可通过恢复服务保管库的“概述”部分进行访问。 复制的项的状态为：
- 正常：复制正常运行。
- 警告：指示可能存在影响复制的问题。
- 严重：检测到严重的复制错误。
如果一切正常，则复制的 VM 状态会设置为“已成功执行”。 如果测试尚未完成，则状态会设置为“建议测试”。 如果距离上次测试已超过六个月，则 VM 也会设置为“建议测试”。