Microsoft AZ-140: 复原能力、恢复和迁移 — 学习指南

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

属于 Microsoft Azure Virtual Desktop Specialty AZ-140 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Azure Virtual Desktop (AVD) 的弹性、恢复和迁移规划侧重于在区域性故障期间维持用户生产力，保护数据（配置文件、映像、应用程序），协调依赖项的故障转移，以及实现从旧版 Remote Desktop Services (RDS) 的可预测过渡。有效的设计会将无状态的 AVD 控制平面与有状态的数据平面分离，使用可重复的自动化进行重建，为每个组件定义明确的恢复目标，并通过发现和容量建模来验证实际性能。

区域架构、用户访问和故障转移

• 控制平面和数据平面：AVD 的代理、Web 访问、诊断和管理服务是全局弹性的。会话主机、主机池、映像和存储是区域特定的，必须为其设计故障转移。
• 区域性故障策略：
  • 为每个用户群组创建一个辅助区域主机池，使用相同的 VM 大小系列和映像沿袭。使用 Azure Compute Gallery 将映像复制到辅助区域。
  • 在两个区域中发布相同的应用程序组（RemoteApp 和/或桌面），并将用户分配到这两个组，将主池设置为默认池，将辅助池设置为 DR 目标。
  • 将 DR 主机保持在冷或温备用状态。对于池化主机，可以缩减至零或关机，然后依靠缩放计划和“连接时启动 VM”功能来最小化稳定状态下的成本。
• 故障期间的用户访问：
  • AVD 服务会将连接请求路由到健康的会话主机。当您将主主机池置于排空模式或其不可用时，如果用户在辅助池中有分配，新连接将被代理到该辅助池。
  • 告知用户，在故障区域中打开的会话将会断开；重新连接时将连接到可用区域。
• 映像和 MSIX 应用附加的对等性：
  • 使用 Azure Image Builder 和带有区域复制功能的 Azure Compute Gallery (SIG) 来管理映像。
  • 将 MSIX 应用附加包存储在两个区域均可访问的弹性存储位置，并将内容复制到辅助区域（例如，ANF 跨区域复制或存储帐户复制）。
• 网络和身份依赖项：
  • 确保 DNS 和身份标识（Active Directory 或 Azure AD DS）可从两个区域访问。对于 Azure AD DS，在每个需要加入域和进行名称解析的区域化 VNet 中，将 VNet DNS 设置配置为托管域的 IP。
  • 验证跨区域的 RDP Shortpath 行为；如果 UDP 受阻，则回退到反向连接。

将映像版本复制到两个区域的示例：

az sig image-version create \
  --resource-group rg-avd-images \
  --gallery-name sig-avd \
  --gallery-image-definition win11-ms \
  --gallery-image-version 1.0.3 \
  --target-regions eastus=1 westus=1

恢复目标和数据保护角色

为每个组件定义不同的 RTO/RPO：

• 主机池和会话主机：
  • 池化：将会话主机视为临时性的。RTO 为分钟级（自动化重新部署），RPO 为 N/A（无主机状态）。不要依赖 VM 备份进行恢复；应从映像重新部署并自动缩放。
  • 个人：如果用户状态驻留在操作系统磁盘上，请使用 Azure Backup 或 Azure Site Recovery (ASR) 进行保护。首选将用户状态卸载到 FSLogix 配置文件中，以简化 DR。
• 映像：
  • 使用 Compute Gallery 复制可实现映像可用性的 RPO 接近于零；RTO 为分钟级，用于部署新主机。保持黄金映像管道的版本化和可重现性。
• 配置文件和 Office 缓存 (FSLogix)：
  • RPO：分钟到小时级，具体取决于复制和备份计划；RTO：如果配置了 Cloud Cache，则为分钟级，用于在辅助区域挂载，否则为恢复卷/共享并重新指向会话所需的时间。
• 应用程序：
  • 对于映像内应用程序，与映像的 RTO/RPO 保持一致。对于 MSIX 应用附加，与包存储复制和重新注册时间保持一致。

Azure Backup 和 ASR：

• Azure Backup：
  • 备份托管 FSLogix 配置文件和 ODFC 容器的 Azure Files 共享。使用频繁的快照来满足 RPO 目标；可恢复单个 VHD/VHDX 或整个共享。需明确快照在用户登录时是崩溃一致性的；对于精确恢复，请执行用户容器的带外复制/重命名，并指示用户重新登录。
  • 在需要时备份个人桌面的操作系统磁盘。池化主机通常不需要 VM 备份。
• Azure Site Recovery：
  • 对 AVD 的关键有状态基础架构组件（例如，管理服务器、许可证服务器（如果适用）、LOB 服务器）以及需要保留 VM 状态的个人主机池使用 ASR。
  • 避免对池化的 AVD 主机使用 ASR；从映像/缩放计划重新部署更快、成本更低。

配置文件存储弹性、Cloud Cache、备份和恢复

• FSLogix 的存储选项：
  • Azure NetApp Files (ANF)：大规模下提供最高的 IOPS/最低的延迟；支持跨区域复制以实现 DR。非常适合超大规模环境或高并发和高配置文件 IO 需求。
  • Azure Files Premium：基于 SSD 的 PaaS 文件共享，具有 ZRS 以实现区域内弹性；在性能和管理之间取得了极佳的平衡。对于跨区域 DR，可与 Cloud Cache 和共享级备份/恢复相结合，或设计双区域共享。
  • IaaS 上的 Storage Spaces Direct (S2D)：仅在 PaaS 不可行时使用。需要至少三个 VM 才能在没有云见证的情况下实现仲裁。运营开销高于 PaaS 替代方案。
• Cloud Cache：
  • 配置多个提供程序（例如，位于不同区域/地区的两个 Azure Files 或 ANF 端点）。在区域性中断期间，FSLogix 会继续针对幸存的提供程序运行，并通过最终一致性来处理缓存的写入。
  • 配置示例：

# PowerShell on session host
New-Item -Path HKLM:\SOFTWARE\FSLogix\Profiles -Force | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name Enabled -Type DWord -Value 1 | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name CCDLocations -Type String `
  -Value "type=smb,connectionString=\\files-pri.file.core.windows.net\profiles;type=smb,connectionString=\\files-dr.file.core.windows.net\profiles" | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name DeleteLocalProfileWhenVHDShouldApply -Type DWord -Value 1 | Out-Null

• 备份和恢复模式：
  • 为配置文件共享实施每小时或每几小时一次的 Azure Backup 快照。对于损坏的用户配置文件，隔离当前的 VHDX，将上一个快照恢复到备用位置，然后复制或重新附加该用户的容器。
  • 对于 ANF，使用快照和跨区域复制；通过快照目录恢复卷级别或单个文件。
• 测试：
  • 在 DR 演练中包括挂载/附加验证、损坏模拟和用户级回滚。

流量、DNS 和依赖项故障转移

• 应用程序依赖项：
  • 许多 AVD 应用程序依赖于 HTTP/S API、Web 前端或数据库。在架构设计上，应采用全局负载均衡和区域性部署，以便在依赖项发生故障转移时，不会让用户滞留在其他方面健康的会话中。
• Azure Front Door 和 Traffic Manager：
  • 使用 Azure Front Door 为 AVD 用户使用的应用程序依赖项提供全局 HTTP/S 第 7 层负载均衡、WAF 和基于路径的路由。在每个区域中，将其与区域冗余后端配对使用。
  • 对于面向公众且支持健康探测的非 HTTP 端点，使用 Azure Traffic Manager 进行基于 DNS 的负载均衡。
• 私有 DNS 和名称解析：
  • 使用 Azure DNS Private Resolver 集中管理条件转发器，以在本地、Azure VNet 和托管域之间路由查询。为可能需要快速故障转移的端点发布低 TTL 记录。
  • 对于无法无缝地进行原生故障转移的存储端点，可以考虑使用通过内部 DNS 抽象出来的双命名端点，以便在发生事件时在主共享和灾备共享之间切换。
• 网络 QoS 和访问：
  • 在 WAN 上优先处理实时 AVD 流量 (UDP/TCP)；调整分支路由器上的 QoS，确保 AVD 流量类别有足够的带宽，以减少连接错误和延迟。
  • 验证 Shortpath 可达性和防火墙针孔；确保出口带宽规划与并发性和工作负载组合相匹配。

从 RDS 迁移、发现、密度和容量

• RDS 评估：
  • 盘点 Connection Broker、RD Gateway、RD Web、RD Session Host、RD Licensing 以及文件服务器/配置文件存储。记录 GPO、FSLogix 配置和应用程序交付方法。
  • 将角色映射到 AVD 构造：主机池、工作区、应用组、配置文件存储和 AVD 托管的代理；消除在 Azure 中对 RD Gateway 和 Broker 的需求。
• Azure Migrate 和发现：
  • 使用 Azure Migrate 设备来发现现有的 RDS VM、性能基线和依赖项。识别应用到服务器的关系，以便进行 AVD 会话主机放置和考虑数据引力。
• 用户密度分析：
  • 按工作负载（任务/知识/高级用户）构建密度模型。使用 CPU 就绪情况、内存压力和配置文件 IO 基线来推导出每台 VM 的会话数。通过在候选 VM SKU（例如 Dv5/Esv5/Dasv5，以及用于图形处理的启用 GPU 的 SKU）上进行试点基准测试来验证。
  • 使用 Azure Virtual Desktop Experience Estimator 来选择用户到主机的延迟最低的区域。
• 容量建模：
  • 将密度转换成每个主机池的主机数量，并包含 N+1 缓冲区和维护开销。在伸缩计划中定义横向扩展阈值以及最小/最大主机数。考虑使用容量预留，以获得可预测的成本和在繁忙区域中得到保证的核心。
  • 确保提前提高订阅和区域配额（vCPU、每个系列的内核数、IP、NIC、磁盘）；尽早提交配额增加请求。

正式切换、共存、配额和运行手册

• 正式切换规划：
  • 运行并行共存：在 AVD 引入试点用户期间，保持 RDS 的正常运行。在两个系统中发布相同的应用，但按用户组引导用户。
  • 试点用户组：从 IT 和早期采用者开始，扩展到有代表性的部门，然后进行广泛推广。利用反馈来调整镜像、FSLogix 设置和缩放策略。
  • 回滚：在满足验收标准之前，保留 RDS 的访问路径。保持用户配置文件向后兼容，或为每个用户组提供配置文件重置路径。
• 运维就绪：
  • 注册密钥：将现有虚拟机加入主机池时，生成注册密钥并通过 AVD 代理加入；通过 Azure Image Builder 和后期预配脚本实现自动化。
  • 工作区和应用组的规范管理：发布最小权限的应用组；分离桌面 (Desktop) 和远程应用 (RemoteApp)；保持灾难恢复 (DR) 应用组的分配状态，但如有必要可在视觉上弱化显示。
• 运行手册和自动化：
  • 构建业务连续性和灾难恢复 (BCDR) 运行手册，涵盖以下内容：
    • 宣布事件并将主池置于排空模式。
    • 扩展灾难恢复 (DR) 池并验证镜像对等性。
    • 通过 Cloud Cache 或 DNS 重定向切换配置文件存储。
    • 通过 Front Door/Traffic Manager 验证关键应用依赖项。
    • 与用户和服务台进行沟通。
    • 在主区域恢复后进行回滚。
  • 使用 Azure Automation 或 Functions 实施运行手册，并配置基于角色的访问控制和变更审批。
• 成本和预留：
  • 对稳定的基线工作负载使用 Savings Plans 和 Capacity Reservations；对突发容量保持即用即付模式并结合自动缩放。安排非生产池在非工作时间关闭。

实际问题场景

在从本地 RDS 场迁移到 Azure Virtual Desktop 的过程中，Adobe 必须确保创意和支持团队在区域性中断期间能够持续工作，同时要处理数百 TB 的漫游配置文件和高要求的图形工作负载。

1. 发现和基线评估

• 使用 Azure Migrate 清点 RDS 主机、配置文件共享和 LOB 依赖项，并捕获图形和支持用户组的 CPU/内存/IO 模式。
• 原因：经验基线有助于确定准确的用户密度目标和虚拟机 SKU 选择，从而最大限度地减少过度预配。

2. 设计区域架构

• 在 West US 2 中创建主主机池，为创意团队使用启用 GPU 的 NVadsA v5，为支持团队使用 Dv5；在 Central US 中部署辅助池。
• 通过 Azure Compute Gallery 复制镜像；将 MSIX 包存储在 ANF 中，并配置跨区域复制。
• 原因：确保跨区域的计算和应用对等性，并提供可预测的性能。

3. 强化身份和 DNS

• 将会话主机要加入域的 VNet DNS 配置为 Azure AD DS 的 IP；部署 Azure DNS Private Resolver 以转发本地和 Azure 之间的查询。
• 原因：跨区域的可靠名称解析可在故障转移期间实现登录和应用访问。

4. 实施弹性配置文件

• 为 FSLogix 使用 Azure NetApp Files，并配置快照和跨区域复制；启用 FSLogix Cloud Cache，使其指向主和灾难恢复 (DR) 的 ANF 卷。
• 原因：ANF 提供了创意人员所需的 IOPS/延迟；如果某个区域发生故障，Cloud Cache 和跨区域复制 (CRR) 可提供业务连续性。

5. 编排依赖项故障转移

• 使用 Azure Front Door 作为 LOB Web API 的前端，并配置区域部署的后端；对任何非 HTTP 的公共端点使用 Traffic Manager。
• 原因：使应用程序端点可以从任一 AVD 区域访问，无需重新配置。

6. 建立恢复目标和保护

• 为池化主机设置分钟级的 RTO（重建），为个人桌面（如有，通过 Azure Backup/ASR 保护）设置小时级的 RTO，通过 ANF 快照为配置文件设置 15 分钟的 RPO；如果支持用户组使用了 Azure Files 共享，则对其进行备份。
• 原因：针对特定组件的目标使成本与业务影响保持一致。

7. 试点和共存

• 将 100 名支持用户和 50 名创意人员引入 AVD；同时保持 RDS 的发布。验证用户密度、配置文件稳定性和应用性能。迭代优化缩放策略和 FSLogix 设置。
• 原因：受控的试点可以降低镜像、存储和自动缩放选择方面的风险。

8. 正式切换和灾难恢复演练

• 生成 AVD 注册密钥以扩展主机池；为所有用户分配 DR 应用组。执行一次 DR 演练：排空主池，扩展 DR 池，验证 Cloud Cache 的连续性，并通过 Front Door 对应用依赖项进行故障转移。
• 原因：在全面迁移之前，验证包括配置文件和依赖项在内的端到端故障转移能力。

9. 配额、预留和自动化

• 预先增加区域 vCPU 和 GPU 配额；为基线 GPU 和 CPU 购买 Capacity Reservations；实施 Azure Automation 运行手册以执行排空、扩展、存储切换和通信任务。
• 原因：保证事件期间的容量，并消除高压事件中的手动操作步骤。

10. 全面迁移和回滚计划

• 在两周内分批迁移剩余的用户组；保留 RDS 访问作为回滚路径，并为每批迁移设置明确的决策门。
• 原因：渐进式切换可降低风险，并在出现意外问题时保留一个即时的后备方案。

← 监视、诊断和故障排除 · 所有领域

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Microsoft →