为 VMware VM/物理服务器设置大规模灾难恢复
本文介绍如何使用 Azure Site Recovery 服务将生产环境中的大量 (> 1000) 本地 VMware VM 或物理服务器设置为灾难恢复到 Azure。
定义 BCDR 策略
在业务连续性和灾难恢复 (BCDR) 策略中，定义业务应用和工作负荷的恢复点目标 (RPO) 与恢复时间目标 (RTO)。 RTO 衡量业务应用或流程为了避免出现连续性问题，必须能够在多长时间内还原并保持可用性服务级别。
- Site Recovery 为 VMware VM 和物理服务器提供连续复制，并提供 RTO 方面的 SLA。
- 在规划 VMware VM 的大规模灾难恢复以及测算所需的 Azure 资源时，可以指定用于容量计算的 RTO 值。
最佳实践
适用于大规模灾难恢复的一些常规最佳做法。 本文档的后续几个部分将更详细地讨论这些最佳做法。
- 确定目标要求：在设置灾难恢复之前，估算出 Azure 中的容量和资源需求。
- 规划 Site Recovery 组件：确定需要提供哪些 Site Recovery 组件（配置服务器、进程服务器）才能符合估算的容量。
- 设置一个或多个横向扩展进程服务器：不要使用配置服务器上默认运行的进程服务器。
- 运行最新的更新：Site Recovery 团队定期发布 Site Recovery 组件的新版本，你应确保运行最新版本。 为帮助做到这一点，请在新增功能中跟踪更新，在发布后启用并安装更新。
- 主动监视：正常运行灾难恢复后，应主动监视复制的计算机以及基础结构资源的状态和运行状况。
- 灾难恢复演练：应定期运行灾难恢复演练。 这些演练不会影响生产环境，但有助于确保在必要时可按预期故障转移到 Azure。
收集容量规划信息
收集有关本地环境的信息，以帮助评估目标 (Azure) 容量需求。
- 对于物理服务器，可手动收集信息。
规划目标 (Azure) 要求和容量
使用收集的估算值和建议，可以规划目标资源和容量。
- 兼容的 VM 数：使用此数字来识别已准备好灾难恢复到 Azure 的 VM 数目。 有关网络带宽和 Azure 核心数的建议基于此数字。
- 所需的网络带宽：注意兼容 VM 的增量复制所需的带宽。
- 运行规划器时，应指定所需的 RPO（以分钟为单位）。 建议中会显示符合该 RPO 时间的 100% 和 90% 所需的带宽。
- 网络带宽建议考虑到了规划器中建议的所有配置服务器和进程服务器所需的带宽。
- 所需的 Azure 核心数：注意目标 Azure 区域中所需的核心数，该数字基于兼容的 VM 数。 如果没有足够的核心，在故障转移时，Site Recovery 将无法创建所需的 Azure VM。
- 建议的 VM 批大小：建议的批大小基于在默认 72 小时内完成该批的初始复制，同时满足 100% 的 RPO 的能力。 可以修改小时值。
使用这些建议可以规划 Azure 资源、网络带宽和 VM 批处理。
规划 Azure 订阅和配额
我们希望确保目标订阅中的可用配额足以应对故障转移。
| Task | 详细信息 | 操作 |
|---|---|---|
| 检查核心数 | 如果可用配额中的核心数少于故障转移时的目标总数，故障转移将会失败。 | 对于 VMware VM，请检查目标订阅中是否有足够的内核。 对于物理服务器，请检查 Azure 核心数是否符合人工估算结果。 若要检查配额，请在 Azure 门户中依次单击“订阅”、“用量 + 配额”。 详细了解如何提高配额。 |
| 检查故障转移限制 | 故障转移次数不得超过 Site Recovery 的故障转移限制。 | 如果故障转移次数超过限制，你可以添加订阅并故障转移到多个订阅，或者提高订阅的配额。 |
故障转移限制
限制是指 Site Recovery 在一小时内支持的故障转移次数（假设每台计算机包含三个磁盘）。
“符合条件”是什么意思？ 若要启动 Azure VM，Azure 要求某些驱动程序处于引导/启动状态，并将 DHCP 等服务设置为自动启动。
- 符合条件的计算机已采用这些设置。
- 对于运行 Windows 的计算机，可以主动检查符合性，并根据需要使其符合条件。 了解详细信息。
- 对于 Linux 计算机，只能在故障转移时使其符合条件。
| 计算机是否符合 Azure 条件？ | Azure VM 限制（托管磁盘故障转移） |
|---|---|
| 是 | 2000 |
| 否 | 1000 |
- 限制假设订阅的目标区域中只有其他极少量的作业正在进行。
- 某些 Azure 区域的规模较小，因此限制可能略低一些。
规划基础结构和 VM 连接
故障转移到 Azure 后，需要让工作负荷像在本地一样正常运行，并使用户能够访问 Azure VM 上运行的工作负荷。
规划源容量和要求
重要的一点是，必须提供足够的配置服务器和横向扩展进程服务器来满足容量要求。 开始大规模部署时，请先从一台配置服务器和一台横向扩展进程服务器着手。 达到规定的限制后，添加更多的服务器。
设置配置服务器
配置服务器容量受启用复制的计算机数目的影响，而不受数据变动率的影响。 若要确定是否需要更多的配置服务器，请参考定义的这些 VM 限制。
| CPU | 内存 | 缓存磁盘 | 复制的计算机限制 |
|---|---|---|---|
| 8 个 vCPU 2 个插槽 * 4 个核心 @ 2.5 GHz |
16 GB | 600 GB | 最多 550 台计算机 假设每台计算机有 3 个 100 GB 的磁盘。 |
- 这些限制基于使用 OVF 模板设置的配置服务器。
- 这些限制假设不是使用配置服务器上默认运行的进程服务器。
如果需要添加新的配置服务器，请遵照以下说明操作：
设置配置服务器时，请注意：
- 设置配置服务器时，必须考虑到该服务器所在的订阅和保管库，因为设置后不能更改订阅和保管库。 如果确实需要更改保管库，必须从保管库取消关联配置服务器，然后重新注册该服务器。 这会停止保管库中的 VM 复制。
- 若要设置包含多个网络适配器的配置服务器，应在设置期间执行此操作。 将配置服务器注册到保管库中后，无法执行此操作。
设置进程服务器
进程服务器容量受数据变动率的影响，而不受启用复制的计算机数目的影响。
- 对于大型部署，始终应该至少提供一台横向扩展进程服务器。
- 若要确定是否需要更多的服务器，请参考下表。
- 我们建议添加最高规格的服务器。
| CPU | 内存 | 缓存磁盘 | 变动率 |
|---|---|---|---|
| 12 个 vCPU 2 个插槽 * 6 个核心 @ 2.5 GHz |
24 GB | 1 TB | 每天最大 2 TB |
按如下所述设置进程服务器：
启用大规模复制
规划容量并部署所需的组件和基础结构之后，为大量的 VM 启用复制。
将计算机排序成批。 为一个批中的 VM 启用复制，然后转到下一批。
- 对于物理计算机，我们建议根据大小和数据量类似的计算机以及可用的网络吞吐量来标识批。 目的是将有可能在大致相同的时间内完成初始复制的计算机分批。
如果某台计算机的磁盘变动率较高或超过部署规划器中的限制，则你可以将不需要复制的非关键文件（例如日志转储或临时文件）移出该计算机。 对于 VMware VM，可将这些文件移到单独的磁盘，然后从复制项中排除该磁盘。
在启用复制之前，请检查计算机是否满足复制要求。
监视部署
启动第一批 VM 的复制后，按如下所述开始监视部署：
规划大规模故障转移
发生灾难时，你可能需要将大量计算机/工作负荷故障转移到 Azure。 按如下所述准备应对此类事件。
可按如下所述提前准备好故障转移：
- 准备基础结构和 VM，以便在故障转移后工作负荷可用，并且用户可以访问 Azure VM。
- 请注意本文档前面所述的故障转移限制。 确保故障转移在这些限制范围内进行。
- 定期运行灾难恢复演练。 演练可以帮助：
- 在故障转移之前发现部署中的不足。
- 估算应用的端到端 RTO。
- 估算工作负荷的端到端 RPO。
- 识别 IP 地址范围冲突。
- 运行演练时，我们建议不要使用生产网络，并在每次演练后清理测试故障转移。
若要运行大规模故障转移，我们建议：
为工作负荷故障转移创建恢复计划。
- 每个恢复计划最多可以触发 100 台计算机的故障转移。
- 详细了解恢复计划。
将 Azure 自动化 Runbook 脚本添加到恢复计划，以将 Azure 上的任何手动任务自动化。 典型的任务包括配置负载均衡器、更新 DNS，等等。
在故障转移之前，请准备好 Windows 计算机，使之符合 Azure 环境的条件。 符合条件的计算机的故障转移限制更高。 详细了解 Runbook。
结合恢复计划使用 Start-AzRecoveryServicesAsrPlannedFailoverJob PowerShell cmdlet 触发故障转移。