Compartilhar via

VMware 到 Azure 灾难恢复体系结构 - 经典版

本文介绍使用 Azure Site Recovery 服务在本地 VMware 站点与 Azure 之间部署 VMware virtual machines（VM）的灾难恢复复制、故障转移和恢复时使用的体系结构和过程- 经典。

有关现代化体系结构的详细信息，请参阅本文。

体系结构组件

下表和图形概述了用于 VMware 虚拟机和物理计算机灾难恢复到 Azure 的组件。

组件 要求 详细信息
Azure Azure订阅、用于缓存的Azure存储帐户、托管磁盘和Azure网络。 在 Azure storage 中存储从本地 VM 复制的数据。 当您从本地故障转移到 Azure 时，会创建具有复制数据的 Azure 虚拟机。 Azure VM 在创建时连接到Azure virtual network。
配置服务器计算机 单台本地部署服务器。 将其作为从下载的 OVF 模板部署的 VMware VM 运行。

计算机运行所有本地Site Recovery组件，其中包括配置服务器、进程服务器和主目标服务器。		 配置服务器：协调本地与Azure之间的通信，并管理数据复制。

进程服务器：默认安装在配置服务器上。 它接收复制数据，使用缓存、压缩和加密对其进行优化，并将其发送到Azure Storage。 进程服务器还会在要复制的 VM 上安装Azure Site Recovery Mobility Service，并自动发现本地计算机。 随着部署的增长，可以添加额外的独立进程服务器来处理更大的复制流量。

主目标服务器：默认安装在配置服务器上。 它在从Azure故障回复期间处理复制数据。 对于大型部署，可以添加一个额外且独立的主目标服务器以进行回切操作。
VMware 服务器 在本地 vSphere ESXi 服务器上托管 VMware VM。 使用 vCenter 服务器管理主机。 在Site Recovery部署期间，将 VMware 服务器添加到恢复服务保管库。
复制的计算机 在复制的每个 VMware VM 上安装Mobility Service。 允许从进程服务器自动安装。 或者，可以手动安装服务或使用自动化部署方法，例如Configuration Manager。

显示 VMware 到 Azure 复制架构关系的图示。

设置出站网络连接

若要使Site Recovery按预期工作，请修改出站网络连接，以允许环境复制。

注释

使用经典架构的 Site Recovery 不支持使用身份验证代理来控制 VMware 和物理机的网络连接。 使用 现代化体系结构时支持同一代理。

URL 的出站连接

如果使用基于 URL 的防火墙代理来控制出站连接，请允许访问以下 URL：

名称 Azure China 21Vianet 说明
存储 *.blob.core.chinacloudapi.cn 允许将数据从 VM 写入源区域中的缓存存储帐户。
Microsoft Entra ID login.chinacloudapi.cn 为Site Recovery服务 URL 提供授权和身份验证。
重复 *.hypervrecoverymanager.windowsazure.cn 允许 VM 与Site Recovery服务通信。
Service Bus *.servicebus.chinacloudapi.cn 允许 VM 写入 Site Recovery 监控和诊断数据。

有关本地 Azure Site Recovery 基础结构与 Azure 服务之间通信过滤所需 URL 的完整列表，请参阅先决条件文章中的 网络需求部分。

复制过程

  1. 为 VM 启用复制时，使用指定的复制策略开始对Azure storage进行初始复制。 注意以下事项：

    • 对于 VMware VM，使用 VM 上运行的Mobility service代理，复制是块级、近乎连续的。
    • 应用的任何复制策略设置：
      • RPO 阈值。 此设置不影响复制。 它有助于监视。 如果当前 RPO 超出了你指定的阈值限制，则会引发事件，并且还可能会发送电子邮件。
      • 恢复点保留期。 此设置指定当发生中断时要回退的时间距离。 托管磁盘上的最大保留期为 15 天。
      • 应用一致的快照。 可以每隔 1 到 12 个小时获取一次应用一致的快照，具体取决于应用需求。 快照是标准 Azure Blob 快照。 在 VM 上运行的移动代理根据此设置请求 VSS 快照，并且会将该时间点标记为复制流中的一个应用一致点。

      注释

      恢复点长保留期可能会影响存储成本，因为可能需要保存更多的恢复点。

  2. 流量通过 Internet 复制到Azure storage公共终结点。 或者，可以将 Azure ExpressRoute 与 Azure 对等互连配合使用。 不支持通过站点到站点虚拟专用网络（VPN）将流量从本地站点复制到Azure。

  3. 初始复制操作可确保在启用复制时，计算机上的所有数据都被发送到 Azure。 初始复制完成后，增量更改的复制到 Azure 的过程开始。 机器的跟踪更改被发送到进程服务器。

  4. 通信按如下方式发生：

    • VM 通过 HTTPS 443 入站端口与本地配置服务器通信，进行复制管理。
    • 配置服务器通过出站端口 HTTPS 443 协调 Azure 的复制。
    • 虚拟机通过入站端口 HTTPS 9443 将复制数据发送到进程服务器，该服务器在配置服务器计算机上运行。 可以修改此端口。
    • 进程服务器接收复制数据、优化和加密数据，并通过端口 443 出站将其发送到Azure storage。

  5. 复制数据日志首先存储在Azure的缓存存储帐户中。 处理这些日志，并将数据存储在Azure托管磁盘中（称为Azure Site Recovery种子磁盘）。 将在此磁盘上创建恢复点。

图示展示 VMware 到 Azure 的复制过程。

重新同步过程

  1. 有时，在初始复制期间或在传输差异更改期间，源计算机与进程服务器之间或进程服务器与Azure之间可能存在网络连接问题。 其中任一项都可能导致数据传输到Azure暂时失败。
  2. 为了避免数据完整性问题，并最大限度地减少数据传输成本，Site Recovery标记计算机进行重新同步。
  3. 在以下情况下，还可以将计算机标记为重新同步，以保持源计算机与存储在Azure中的数据之间的一致性
    • 如果计算机强制关机
    • 如果计算机出现了诸如磁盘大小调整之类的配置更改（将磁盘大小从 2 TB 修改为 4 TB）
  4. 重新同步只将增量数据发送到 Azure。 通过计算源计算机与存储在Azure中的数据之间的校验和，将本地与Azure之间的数据传输降到最低。
  5. 默认情况下，重新同步安排为在非工作时间自动运行。 如果你不希望等待默认非工作时间的重新同步，可手动重新同步 VM。 要执行此操作，请转到 Azure portal，选择 VM>重新同步。
  6. 如果默认重新同步在办公时间之外失败，并且需要手动干预，则会在Azure portal的特定计算机上生成错误。 可以解决错误并手动触发重新同步。
  7. 重新同步完成后，将继续复制增量更改。

管理复制策略

  • 启用复制时，可以自定义复制策略的设置。
  • 随时可以创建复制策略，并在启用复制时应用该策略。

多虚拟机一致性

如果希望 VM 一同复制，并在故障转移时获得共享的崩溃一致性和应用一致性恢复点，可将这些 VM 集中到一个复制组中。 多 VM 一致性会影响工作负荷的性能。仅当 VM 运行的工作负荷需要在所有计算机之间保持一致时，才应该对这些 VM 使用此功能。

快照和恢复点

恢复点是基于在特定时间点生成的 VM 磁盘快照创建的。 故障转移 VM 时，可以使用恢复点来还原目标位置中的 VM。

故障转移时，我们通常想要确保 VM 在不发生任何数据损坏或丢失的情况下启动，并且 VM 数据可在操作系统以及 VM 上运行的应用中保持一致。 这取决于创建的快照类型。

Site Recovery按如下所示拍摄快照：

  1. 默认情况下，Site Recovery创建数据崩溃一致性快照，如果为此指定了特定频率，则会创建应用程序一致性快照。
  2. 恢复点是基于快照创建的，根据复制策略中的保留期设置进行存储。

一致性

下表解释了不同的一致性类型。

崩溃一致性

说明 详细信息 建议
崩溃一致性快照捕获创建快照时磁盘上的数据。 它不包括内存中的任何数据。

崩溃一致性快照包含在 VM 发生崩溃或者在创建快照的那一刻从服务器上拔下电源线时，磁盘上的等量数据。

崩溃一致性不能保证操作系统或 VM 上的应用中的数据一致性。		 默认情况下，Site Recovery每隔五分钟创建崩溃一致性恢复点。 此设置不可修改。

 目前，大多数应用都可以从崩溃一致性恢复点正常恢复。

对于操作系统以及 DHCP 服务器和打印服务器等应用而言，崩溃一致性恢复点通常已足够。

应用一致性

说明 详细信息 建议
应用一致性恢复点是基于应用一致性快照创建的。

应用一致性快照包含崩溃一致性快照中的所有信息，此外加上内存中的所有数据，以及正在进行的所有事务。		 应用一致性快照使用卷影复制服务 (VSS)：

1）Azure Site Recovery 使用“仅复制备份”（VSS_BT_COPY）方法，该方法不会更改 Microsoft SQL Server 的事务日志备份时间和序列号

2）在启动快照时，VSS 对卷执行写时复制 (COW) 操作。

3) 执行 COW 之前，VSS 会告知计算机上的每个应用它需要将内存常驻数据刷新到磁盘。

4） VSS 然后允许备份/灾难恢复应用（在本例中为 Site Recovery）读取快照数据并继续作。		 应用一致性快照是按指定的频率创建的。 此频率始终应小于为保留恢复点设置的频率。 例如，如果您使用默认设置，在 24 小时内保留恢复点，则应将频率设置为小于 24 小时。

应用一致性快照比崩溃一致性快照更复杂，且完成时间更长。

已启用复制的 VM 上运行的应用程序的性能会受到影响。

故障转移和故障回复过程

在设置复制并运行故障恢复演练（测试故障转移）来检查是否一切都按预期工作后，可以根据需要运行故障转移和故障回复。

  1. 可以针对一台计算机运行故障转移，或创建恢复计划来同时故障转移多个 VM。 相比单个计算机故障转移，恢复计划的优势包括：

    • 可以通过在单个恢复计划中包含整个应用的所有 VM，为应用依赖关系建模。
    • 可以添加脚本、Azure 运维手册，并为手动操作暂停。

  2. 触发初始故障转移后，提交操作以开始从 Azure 虚拟机访问工作负载。

  3. 当主要本地站点再次可用时，可以准备进行故障恢复。 若要故障回复，需要设置故障回复基础结构，包括：

    • Azure 中的临时进程服务器：若要从 Azure 恢复故障，请设置 Azure VM 作为进程服务器来处理来自 Azure 的数据复制。 故障回复完成后，可以删除此虚拟机。
    • VPN 连接：若要故障恢复，需要有从 Azure 网络到本地站点的 VPN 连接（或 ExpressRoute）。
    • 单独的主目标服务器：默认情况下，在本地 VMware VM 上与配置服务器一起安装的主目标服务器用于处理故障回复。 如果需要回切大量流量，应为此目的设置一个独立的本地主服务器。
    • 故障回复策略：若要复制回到本地站点，需要创建故障回复策略。 从本地创建复制策略到Azure时，会自动创建此策略。

  4. 所有组件均就位后，故障回复通过三个操作进行：

    • 阶段 1：重新保护Azure VM，以便从Azure复制回本地 VMware VM。
    • 第 2 阶段：对本地站点执行故障转移。
    • 第 3 阶段：在工作负荷进行故障恢复后，为本地 VM 重新启用复制。

显示从 Azure 进行 VMware 回切的图示。

后续步骤

请按照 本教程 启用 VMware 到 Azure 的复制。

  • Last updated on