作为一个组织，必须采用业务连续性和灾难恢复（BCDR）策略，使数据在计划内和计划外中断期间保持数据安全、应用可用和工作负载联机。
通过将虚拟机（VM）工作负荷从主站点复制到辅助位置，Azure Stack Hub 上的 Azure Site Recovery 提供服务，这些服务可以支持在中断期间组织数据、应用程序可用性和工作负荷的安全性。 例如，当你的主站点发生中断时，可以故障转移到备用站点以访问你的应用。 一旦主站点再次运行，就可以切换回到它。 有关详细信息，请参阅 关于 Site Recovery。
若要在两个 Azure Stack Hub 实例之间启用 VM 复制，请配置两个环境：
-
源 环境：
- 运行租户 VM 的 Azure Stack Hub 标记。
-
目标 环境：
- 运行 Azure Site Recovery 资源提供程序的位置。
业务连续性和灾难恢复计划成功的关键组成部分是容量规划。 在容量规划过程中，需要考虑以下几个因素：
要保护的特定工作负载的恢复时间目标 (RTO) 和恢复点目标 (RPO)。
工作负荷和应用程序特征：
- 相应 VM 中的数据更改频率。
- 生成或删除了多少数据？
- 应用程序设计的外观等方面如何？
VM 大小、磁盘数以及每个 VM 如何与其他 VM 相关联。
- 对于需要多个 VM 的解决方案，请了解这些 VM 的启动顺序。
源环境和目标环境之间的网络带宽。 此组件可能会影响 RPO。
其中每一点都很重要，在构建 BCDR 计划时具有广泛的影响。
以下部分列出了从 Azure Site Recovery 的角度来看要考虑的要点。 每个 BCDR 计划都是不同的，它基于你计划保护的工作负荷的具体情况。 因此，此列表并不全面。
关于源的注意事项
在源环境中，Azure Stack Hub 运行 Azure Site Recovery VM 设备。 VM 是一个 在 Azure Stack Hub 用户订阅中运行的Standard_DS4_v2（8 个 vCPU、28-Gb 内存、32 个数据磁盘）。
在源环境中，请考虑以下方面：
定额：
- 您需要有足够的配额来创建 Azure Site Recovery 虚拟机设备。 需要一个或多个，具体取决于总体计划。
Azure Site Recovery VM 设备的存储：
Azure Site Recovery VM 设备本身的数据需求由其虚拟机大小定义。
规划容量时，请确保设备 VM 有足够的存储来执行故障回复和重新保护机制。
注释
如果存在存储限制，故障回复和重新保护可能会失败，并显示错误消息：出现内部错误。 用户应检查设备上的事件日志，以确认实际的 Azure 资源管理器错误。 有关详细信息，请参阅 Azure Site Recovery 的已知问题。
带宽：
- 初始复制会生成高带宽使用率。
- 每个 VM 上的更改会根据复制策略和各类应用程序的不同类型被复制。
目标考虑因素
在目标环境中，对于容量规划，需要考虑两个部分：
Azure Site Recovery 服务要求：运行 Azure Site Recovery 所需的消耗量，不一定保护任何工作负荷。
受保护的工作负载要求。
目标环境要求为每个 Site Recovery 设备创建一个 Azure Site Recovery 保管库，以保护 VM 免受源（每个保管库一个设备） 的保护。 虽然这不是从容量的角度来看的限制，但在规划整体环境设计时，应考虑这一点。
Azure Site Recovery RP 资源
在 Azure Stack Hub 上安装 Azure Site Recovery 需要安装 Site Recovery 资源提供程序（RP）。
注释
使用 Microsoft.SiteRecovery-1.2301.2216.2287，Azure Stack Hub 上的 Azure Site Recovery 不需要事件中心作为依赖项。
此服务是在 Azure Stack Hub 管理员订阅上创建的，由 Azure Stack Hub 本身管理，因此无需配置。 但是，与任何服务一样，这些资源消耗内存、存储，并分配了某些 vCPU：
| 服务 | vCore | 内存 | 磁盘大小 |
|---|---|---|---|
| Azure Site Recovery | 18 | 64 GB | 384 GB |
注释
这些资源是 Azure Stack Hub 管理界面的 Azure Stack Hub 服务。 安装后，平台将管理这些资源。
受保护的工作负荷
创建 BCDR 计划时，请考虑受保护工作负荷的所有方面。 以下列表不完整，应被视为起点：
VM 大小、磁盘大小、IOPS、数据变动量和新数据创建。
网络带宽注意事项：
- 增量复制所需的网络带宽。
- Azure Site Recovery 能够从源环境传输至目标环境的吞吐量。
- 一次要批处理的 VM 数。 此数字基于在给定时间内完成初始复制的估计带宽。
- 可为给定带宽实现的 RPO。
- 预配较低的带宽时，对所需 RPO 的影响。
存储注意事项：
- 初始复制需要多少数据。
- 保留多少个恢复点，以及每个受保护 VM 的数据在这些时间间隔内如何增加。
- 需要向目标 Azure Stack Hub 用户订阅分配多少个配额，以便用户有足够的分配。
- 用于复制的缓存存储帐户。
计算考量：
- 发生故障转移时，虚拟机将在目标 Azure Stack Hub 用户的订阅上启动。 必须有足够的配额分配才能启动这些 VM 资源。
- 在保护 VM 期间，当受保护的 VM 在源环境中处于活动状态时，目标环境中不会使用与 VM 相关的资源（如 vCPU、内存等）。 这些资源只有在故障转移过程中才会变得重要，例如在故障转移测试中。
对于 Azure Stack Hub 上的 Azure Site Recovery 的范围，下面是计算的起点，尤其是用于使用的缓存存储帐户：
如果发生故障切换，在正常运行期间，请将复制的磁盘数乘以平均 RPO。 例如，你可能有 (2 MB * 250 秒)。 缓存存储帐户通常为每个磁盘数 KB 到 500 MB。
如果发生故障转移（在最坏的情况下）将复制的磁盘数乘以一整天的平均 RPO。
重要
如果 Azure Site Recovery 的某些部分不起作用，但其他部分起作用，那么在 Azure Site Recovery 决定超时之前，存储帐户中最多可能有一天的差异日志。
恢复至新 VM。 计算每个批处理的磁盘大小的总和。
- 必须将整个磁盘复制到要应用的目标 VM 的缓存存储帐户，因为目标是空磁盘。
- 复制后，关联的数据将被删除，但在所有磁盘大小总和下，可能会出现峰值使用量。
根据要保护的解决方案的详细信息创建 BDCR 计划。
下表是我们环境中运行测试的示例。 可以使用此见解获取自己的应用程序的基线，但每个工作负荷有所不同：
配置
| 块大小 | 吞吐量/磁盘 |
|---|---|
| 2 MB | 2 MB/秒 |
| 64 KB | 2 MB/秒 |
| 8 KB | 1 MB/秒 |
| 8 KB | 2 MB/秒 |
结果
| 支持的磁盘数 | 总吞吐量 | 总 OPS | 瓶颈 |
|---|---|---|---|
| 68 | 136 MB/秒 | 68 | 存储 |
| 六十 | 120 MB/秒 | 2048 | 存储 |
| 28 | 28 MB/秒 | 3584 | Azure Site Recovery CPU 和内存 |
| 16 | 32 MB/秒 | 4096 |
注释
8 Kb 是 Azure Site Recovery 支持的最小块大小。 任何小于 8 Kb 的更改都被视为 8 Kb。
为了进一步测试，我们生成了一致类型的工作负载；例如，在 8 Kb 块中的一致存储更改，总计每个磁盘达到 1 MB/秒。 因为更改可能在一天中的不同时间发生，或以各种规模的峰值出现，所以这种情况在实际工作负荷中不太可能发生。
为了复制这些随机模式，我们还使用以下方法测试了方案：
- 120 个 VM（80 Windows，40 Linux）通过同一 Azure Site Recovery VM 设备进行保护。
每个 VM 在随机间隔内，每小时至少生成两次随机数据块，总共在 5 个文件中合计 5 Gb 数据。
在 Azure Site Recovery 服务上，所有 120 个 VM 上的复制成功，负载为低到中等。
注释
这些数字应仅用作基线。 它们不一定线性缩放。 添加另一批相同数量的 VM 可能会比初始 VM 影响较小。 结果高度依赖于使用的工作负荷类型。
如何规划和测试
应用程序和解决方案工作负载具有特定的恢复时间目标（RTO）和恢复点目标（RPO）要求。 有效的业务连续性和灾难恢复（BCDR）设计利用满足这些要求的平台级功能，因为我们使用解决方案特定的机制。 若要设计 BCDR 功能，请捕获平台灾难恢复（DR）要求，并考虑设计中的所有因素：
应用程序和数据可用性要求：
- 每个工作负载的 RTO 和 RPO 要求。
- 支持主动-主动和主动-被动可用性模式。
支持用于故障转移的多区域部署，同时通过组件之间的邻近性提升性能。 在服务中断期间，您可能会遇到功能受限或性能下降的应用程序操作。
注释
应用程序可能以本机方式知道要运行，或者某些组件能够跨多个 Azure Stack Hub 环境运行。 在这种情况下，您可以使用 Azure Site Recovery 仅复制那些没有该功能的组件的 VM；例如，前端或后端类型的解决方案，您可以在 Azure Stack Hub 环境中跨越部署前端。
避免在生产和 DR 网络中使用重叠的 IP 地址范围。
- 具有重叠 IP 地址的生产和 DR 网络需要一个故障转移过程，这会使应用程序故障转移复杂化并出现延迟。 如果可能，请针对 BCDR 网络体系结构进行规划，以提供与所有站点的并发连接。
确定目标环境的尺寸：
- 如果以 1：1 的方式使用源和目标，请在目标环境中分配稍微更多的存储。 这是因为磁盘书签历史记录生成的方式。 此分配不会增加 2 倍，因为它仅包括对数据的更改。 根据数据类型和预期的更改，需要在目标上配置1.5倍至2倍存储量的复制策略，以确保故障转移过程不会引发任何问题。
- 可以考虑将目标 Azure Stack Hub 环境作为多个 Azure Stack Hub 源的目标。 在这种情况下，你将降低总体成本，但必须规划某些工作负荷下降时会发生什么情况：例如，必须确定源的优先级。
- 如果目标环境用于运行其他工作负荷，则 BCDR 计划必须包括这些工作负荷的行为。 例如，可以在目标环境中运行开发/测试 VM，如果源环境出现问题，则可以关闭目标上的所有 VM，以确保有足够的资源可用于启动受保护的 VM。
应测试 BCDR 并定期验证。 可以通过使用测试故障转移过程或移动整个工作负荷来验证端到端流，以实现此目的。