从 VMware 到 Azure 的灾难恢复体系结构(现代版)
本文介绍使用 VMware/物理计算机保护体验(现代版)在本地 VMware 站点和 Azure 之间部署 VMware 虚拟机 (VM) 的灾难恢复复制、故障转移和恢复时使用的体系结构和流程。
注意
请确保创建新的恢复服务保管库以设置 ASR 复制设备。 请勿使用现有保管库。
若要了解经典体系结构中的 Azure Site Recovery 体系结构,请参阅此文。
体系结构组件
下面的表和图提供了用于将 VMware VM/物理计算机灾难恢复到 Azure 的组件的概要视图。
组件 | 要求 | 详细信息 |
---|---|---|
Azure | Azure 订阅、用于缓存的 Azure 存储帐户、托管磁盘和 Azure 网络。 | 从本地 VM 复制的数据存储在 Azure 存储中。 运行从本地到 Azure 的故障转移时,将使用复制的数据创建 Azure VM。 创建 Azure VM 后,它们将连接到 Azure 虚拟网络。 |
Azure Site Recovery 复制设备 | 这是整个 Azure Site Recovery 本地基础结构的基本构建基块。 设备中的所有组件都与复制设备协调一致。 此服务监督所有端到端 Site Recovery 活动,包括监视受保护计算机的运行状况、数据复制、自动更新等。 |
该设备承载各种关键组件,例如: 代理服务器:此组件充当移动代理与云中 Site Recovery 服务之间的代理通道。 它确保生产工作负荷不需要其他 Internet 连接来生成恢复点。 发现的项: 此组件收集 vCenter 的信息,并与云中的 Azure Site Recovery 管理服务协调一致。 重新保护服务器: 在重新保护和故障回复操作期间,此组件在 Azure 和本地计算机之间进行协调。 进程服务器:此组件用于在将数据发送到 Azure 之前对其进行缓存和压缩。 详细了解复制设备以及如何使用多个复制设备。 恢复服务代理:此组件用于配置/注册到 Site Recovery 服务,以及监视所有组件的运行状况。 Site Recovery 提供程序:此组件用于促进重新保护。 它可以识别源计算机的备用位置重新保护和原始位置重新保护。 复制服务: 此组件用于将数据从源位置复制到 Azure。 |
VMware 服务器 | VMware VM 在本地 vSphere ESXi 服务器上托管。 我们建议使用 vCenter 服务器管理主机。 | 在 Site Recovery 部署期间,将 VMware 服务器添加到恢复服务保管库。 |
复制的计算机 | 移动服务将安装在复制的每个 VMware VM 上。 | 建议你允许自动安装移动服务。 或者,你也可以手动安装该服务。 |
设置出站网络连接
若要使 Site Recovery 按预期工作,需修改出站网络连接以允许环境复制。
注意
Site Recovery 不支持使用身份验证代理来控制网络连接。
URL 的出站连接
如果使用基于 URL 的防火墙代理来控制出站连接,请允许访问以下 URL:
URL | 详细信息 |
---|---|
portal.azure.cn |
导航到 Azure 门户。 |
*.chinacloudapi.cn *.msftauth.net *.msauth.net *.microsoft.com *.live.com *.office.com |
用于登录到 Azure 订阅。 |
*.partner.microsoftonline.cn |
为设备创建 Microsoft Entra 应用,以便与 Azure Site Recovery 通信。 |
management.chinacloudapi.cn |
为设备创建 Microsoft Entra 应用,以便与 Azure Site Recovery 服务通信。 |
*.services.visualstudio.com |
上传用于内部监视的应用日志。 |
*.vault.azure.cn |
在 Azure Key Vault 中管理机密。 注意:确保要复制的计算机可以访问此内容。 |
aka.ms |
允许访问“也称为”链接。 适用于 Azure Site Recovery 设备更新。 |
download.microsoft.com/download |
允许从 Microsoft 下载中进行下载。 |
*.servicebus.chinacloudapi.cn |
设备与 Azure Site Recovery 服务之间的通信。 |
*.discoverysrv.azure.cn |
连接 Azure Site Recovery 发现服务 URL。 |
*.hypervrecoverymanager.azure.cn |
连接到 Azure Site Recovery 微服务 URL。 |
*.blob.core.chinacloudapi.cn |
将数据上传到用于创建目标磁盘的 Azure 存储。 |
*.backup.azure.cn |
保护服务 URL � Azure Site Recovery 用于在 Azure 中处理和创建复制磁盘的微服务。 |
*.prod.migration.azure.cn |
发现你的本地资产。 |
复制过程
为某台 VM 启用复制时,将使用指定的复制策略开始到 Azure 存储的初始复制。 注意以下事项:
- 对于 VMware VM,复制是在块级别进行的,几乎连续进行,使用的是在 VM 上运行的移动服务代理。
- 应用的任何复制策略设置:
- RPO 阈值。 此设置不影响复制。 它有助于监视。 如果当前 RPO 超出了你指定的阈值限制,则会引发事件,并且还可能会发送电子邮件。
- 恢复点保留期。 此设置指定当发生中断时要回退的时间距离。 最长保留期为 15 天。
- 应用一致的快照。 可以每隔 1 到 12 个小时获取一次应用一致的快照,具体取决于应用需求。 快照是标准的 Azure blob 快照。 在 VM 上运行的移动代理根据此设置请求 VSS 快照,并且会将该时间点标记为复制流中的一个应用一致点。
注意
恢复点保持期的值过高可能会影响存储成本,因为可能需要保存更多的恢复点。
流量通过 Internet 复制到 Azure 存储公共终结点。 或者,可以结合使用 Azure ExpressRoute 和 Microsoft 对等互连。 仅在使用专用终结点时,才支持通过站点到站点虚拟专用网 (VPN) 将流量从本地站点复制到 Azure。
初始复制操作可确保在启用复制时将计算机上的所有数据发送到 Azure。 完成初始复制后,开始将增量更改复制到 Azure。 针对机器跟踪的更改将发送到进程服务器。
通信按如下方式发生:
- VM 通过 HTTPS 443 入站端口与本地设备通信,以进行复制管理。
- VM 通过 HTTPS 9443 入站端口将复制数据发送到设备。 可以修改此端口。
- 设备接收复制数据、优化和加密数据,然后通过 443 出站端口将其发送到 Azure 存储。
复制数据首先登陆 Azure 中的缓存存储帐户。 系统将处理这些日志,并将数据存储在 Azure 托管磁盘(称为 asrseeddisk)中。 将在此磁盘上创建恢复点。
重新同步过程
- 有时,在初始复制或传输增量更改期间,源计算机到进程服务器之间或进程服务器到 Azure 之间可能存在网络连接问题。 这两种情况都可能导致暂时无法将数据传输到 Azure。
- 为避免出现数据完整性问题,并最大限度地降低数据传输成本,Site Recovery 会标记计算机以进行重新同步。
- 在以下情况下也可能标记计算机以进行重新同步,目的是保持源计算机和存储在 Azure 中的数据之间的一致性
- 如果计算机强制关机
- 如果计算机出现了诸如磁盘大小调整之类的配置更改(将磁盘大小从 2 TB 修改为 4 TB)
- 重新同步仅向 Azure 发送增量数据。 通过计算源计算机和 Azure 中存储的数据之间的数据校验和来最小化本地和 Azure 之间的数据传输。
- 默认情况下,重新同步安排为在非工作时间自动运行。 如果你不希望等待默认非工作时间的重新同步,可手动重新同步 VM。 为此,请转到 Azure 门户,选择“VM”>“重新同步”。
- 如果默认重新同步在办公时间之外失败,并且需要手动干预,则会在 Azure 门户中的特定计算机上生成错误。 可以解决错误并手动触发重新同步。
- 重新同步完成后,将继续复制增量更改。
复制策略
启用 Azure VM 复制时,Site Recovery 默认会使用下表中汇总的默认设置创建新的复制策略。
策略设置 | 详细信息 | 默认 |
---|---|---|
恢复点保留期 | 指定 Site Recovery 保留恢复点的时间长短 | 1 天 |
应用一致性快照频率 | Site Recovery 创建应用一致性快照的频率 | 已禁用 |
管理复制策略
可按如下所述管理和修改默认的复制策略设置:
- 启用复制时可以修改设置。
- 尝试启用复制时,可以创建或编辑新的复制策略。
多 VM 一致性
如果希望 VM 一起复制,并在故障转移时获得共享的崩溃一致和应用一致恢复点,可将这些 VM 集中到一个复制组中。 多 VM 一致性会影响工作负载的性能。仅当 VM 4 工作负载需要在所有计算机之间保持一致时,才应该对这些 VM 使用此功能。
快照和恢复点
恢复点是基于在特定时间点生成的 VM 磁盘快照创建的。 故障转移 VM 时,可以使用恢复点来还原目标位置中的 VM。
故障转移时,我们通常想要确保 VM 在不发生任何数据损坏或丢失的情况下启动,并且 VM 数据可在操作系统以及 VM 上运行的应用中保持一致。 这取决于创建的快照类型。
Site Recovery 按如下所述创建快照:
- 默认情况下,Site Recovery 创建崩溃一致性数据快照;如果指定了频率,则创建应用一致性快照。
- 恢复点是基于快照创建的,根据复制策略中的保留期设置进行存储。
一致性
下表解释了不同的一致性类型。
崩溃一致性
说明 | 详细信息 | 建议 |
---|---|---|
崩溃一致性快照捕获创建快照时磁盘上的数据。 它不包括内存中的任何数据。 崩溃一致性快照包含在 VM 发生崩溃或者在创建快照的那一刻从服务器上拔下电源线时,磁盘上的等量数据。 崩溃一致性不能保证操作系统或 VM 上的应用中的数据一致性。 |
默认情况下,Site Recovery 每隔五分钟创建崩溃一致性恢复点。 此设置不可修改。 |
目前,大多数应用都可以从崩溃一致性恢复点正常恢复。 对于操作系统以及 DHCP 服务器和打印服务器等应用而言,崩溃一致性恢复点通常已足够。 |
应用一致性
说明 | 详细信息 | 建议 |
---|---|---|
应用一致性恢复点是基于应用一致性快照创建的。 应用一致性快照包含崩溃一致性快照中的所有信息,此外加上内存中的数据,以及正在进行的事务中的数据。 |
应用一致性快照使用卷影复制服务 (VSS): 1) Azure Site Recovery 使用“仅复制备份”(VSS_BT_COPY) 方法,该方法不会更改 Microsoft SQL 的事务日志备份时间和序列号 2) 在启动快照时,VSS 会对卷执行“写入时复制”(COW) 操作。 3) 执行 COW 之前,VSS 会告知计算机上的每个应用它需要将内存常驻数据刷新到磁盘。 4) 然后,VSS 允许备份/灾难恢复应用(在本例中为 Site Recovery)读取快照数据并继续处理。 |
应用一致性快照是按指定的频率创建的。 此频率始终应小于为保留恢复点设置的频率。 例如,如果使用默认设置 24 小时保留恢复点,则应将频率设置为小于 24 小时。 应用一致性快照比崩溃一致性快照更复杂,且完成时间更长。 应用一致性快照会影响已启用复制的 VM 上运行的应用的性能。 |
故障转移和故障回复过程
在设置复制并运行故障恢复演练(测试故障转移)来检查是否一切都按预期工作后,可以根据需要运行故障转移和故障回复。
可以针对一台计算机运行故障转移,也可以创建恢复计划来同时故障转移多个 VM。 相比单计算机故障转移,恢复计划的优势包括:
- 可以通过在单个恢复计划中包含整个应用的所有 VM,为应用依赖关系建模。
- 可以添加脚本、Azure Runbook 和暂停手动操作。
触发初始故障转移之后,可提交它来开始访问 Azure VM 中的工作负荷。
当本地主站点再次可用时,可以准备故障回复。 如果需要对大量流量进行故障回复,请设置新的 Azure Site Recovery 复制设备。
- 第 1 阶段:重新保护 Azure VM,以便它们可以从 Azure 复制回本地 VMware VM。
- 第 2 阶段:运行到本地站点的故障转移。
- 第 3 阶段:在工作负荷进行故障回复后,为本地 VM 重新启用复制。
后续步骤
根据此教程启用 VMware 到 Azure 复制。