使用 Azure Site Recovery 进行容量规划（预览版）

  • 项目

组织必须采用业务连续性和灾难恢复 (BCDR) 策略，以便在计划内和计划外中断期间确保数据安全、应用可用且工作负载联机。

通过将虚拟机 (VM) 工作负载从主站点复制到辅助位置，Azure Stack Hub 上的 Azure Site Recovery 提供有助于在中断期间确保组织数据安全性以及应用程序和工作负载可用性的服务。 例如，当主站点发生中断时，可以故障转移到辅助位置以访问应用。 主站点恢复正常运行后，可以故障回复到主站点。 有关详细信息，请参阅关于 Site Recovery。

若要跨两个 Azure Stack Hub 缩放单元启用 VM 复制，你需要配置两个环境：

  • 源环境：
    • 运行租户 VM 的 Azure Stack Hub 缩放单元。
  • 目标环境：
    • Azure Site Recovery 资源提供程序和依赖项的运行位置。

Snapshot of replication of VMs across two Azure Stack Hub stamps.

业务连续性和灾难恢复计划取得成功的一个基本要素是容量规划。 在容量规划期间，需要考虑以下几个因素：

  • 要保护的特定工作负载的恢复时间目标 (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 个数据磁盘）VM。

对于源环境，请考虑以下方面：

  • 定额：

    • 应有足够的配额用于创建 Azure Site Recovery VM 设备。 需要一个或多个，具体取决于整体计划。

  • Azure Site Recovery VM 设备的存储：

    • Azure Site Recovery VM 设备本身需要符合根据其 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 依赖项服务器和 Site Recovery 资源提供程序 (RP) 本身。

注意

使用 Microsoft.SiteRecovery-1.2301.2216.2287 时，Azure Stack Hub 上的 Azure Site Recovery 不需要事件中心作为依赖项。

Screenshot of the three services to install Azure Site Recovery on Azure Stack Hub.

这两个服务是在 Azure Stack Hub 管理员订阅上创建的，由 Azure Stack Hub 本身管理，因此不需要配置。 但是，与任何服务一样，这些资源会消耗内存和存储，并且需要为其分配特定的 vCPU：

服务 vCore 内存 磁盘大小
依赖项服务 12 42 GB 600 GB
Azure Site Recovery 12 42 GB 300 GB
总计 24 84 GB 900 GB

注意

这些资源是 Azure Stack Hub 管理端的 Azure Stack Hub 服务。 安装后，平台将管理这些资源。

受保护的工作负荷

创建 BCDR 计划时，请考虑受保护工作负载的各个方面。 以下列表并不完整，应将其视为起点：

  • VM 大小、磁盘数量、磁盘大小、IOPS、数据变动率和创建的新数据。

  • 网络带宽考虑因素：

    • 增量复制所需的网络带宽。
    • 目标环境中的 Azure Site Recovery 可以从源环境获取的吞吐量。
    • 每次要批处理的 VM 数量。 此数值基于在给定时间内完成初始复制所需的估计带宽。
    • 给定带宽可以实现的 RPO。
    • 在预配较低带宽的情况下，对所需 RPO 的影响。

  • 存储考虑因素：

    • 初始复制所需的数据量。
    • 在这些间隔内，为每个受保护 VM 保留多少个恢复点，数据如何增加。
    • 需要为目标 Azure Stack Hub 用户订阅分配多少配额，以便用户有足够的分配。
    • 用于复制的缓存存储帐户。

  • 计算考虑因素：

    • 发生故障转移时，VM 将在目标 Azure Stack Hub 用户订阅上启动。 必须有足够的配额分配才能启动这些 VM 资源。
    • 在保护 VM 期间，当受保护的 VM 在源环境中处于活动状态时，不会在目标环境中消耗与 VM 相关的资源，例如 vCPU、内存等。 这些资源仅在故障转移（例如测试故障转移）过程中相关。

从 Azure Stack Hub 上的 Azure Site Recovery 范围讲，尤其是对于使用的缓存存储帐户，计算起点如下：

  1. 如果发生故障转移，请在正常操作期间，将复制的磁盘数乘以平均 RPO。 例如，(2MB * 250)。 缓存存储帐户通常为每个磁盘分配几 KB 到 500 MB。

  2. 如果发生故障转移，在最坏的情况下，请将复制的磁盘数乘以一整天的平均 RPO。

    重要

    如果 Azure Site Recovery 的某些部分不正常工作，但其他部分正常工作，则在 Azure Site Recovery 决定超时之前，存储帐户中最多可能有一天的差异日志。

  3. 故障回复到新的 VM。 计算每个批的磁盘大小总和。

    • 由于目标是空磁盘，因此必须将整个磁盘复制到缓存存储帐户以供目标 VM 应用。
    • 关联的数据在复制后将被删除，但根据所有磁盘大小的总和，可能会看到使用高峰。

根据要保护的解决方案的具体情况创建 BDCR 计划。

下表是在我们的环境中运行的测试示例。 你可以使用此见解为自己的应用程序建立基线，但每个工作负载是不同的：

配置

块大小 吞吐量/磁盘
2 MB 2 MB/秒
64 KB 2 MB/秒
8 KB 1 MB/秒
8 KB 2 MB/秒

结果

支持的磁盘数 总吞吐量 总 OPS Bottleneck
68 136 MB/秒 68 存储
60 120 MB/秒 2048 存储
28 28 MB/秒 3584 Azure Site Recovery CPU 和内存
16 32 MB/秒 4096

注意

8Kb 是 Azure Site Recovery 支持的最小数据块大小。 任何小于 8Kb 的更改都被视为 8Kb。

为了进一步测试，我们生成了一致类型的工作负载；例如，以 8 Kb 块为单位生成一致的存储更改，每个磁盘的总吞吐量高达 1 MB/秒。 这种情况在实际工作负载中不太可能发生，因为更改可能发生在一天中的不同时间，或者以各种大小的峰值发生。

为了复制这些随机模式，我们还使用以下配置测试了方案：

  • 通过同一 Azure Site Recovery VM 设备保护的 120 个 VM（80 个 Windows VM，40 个 Linux VM）。

    • 每个 VM 以随机间隔生成数据，至少每小时生成两次，随机块在五个文件中总共生成 5 Gb 数据。

    • 在 Azure Site Recovery 服务上使用中低负载在所有 120 个 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 并定期验证。 为此，可以使用测试故障转移过程，或移动整个工作负载以端到端地验证流程。

后续步骤

Azure Stack Hub 上的 Azure Site Recovery