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 服務會將連線請求路由到健康的工作階段主機。當您將主要主機集區置於清空模式 (drain mode) 或其無法使用時，如果使用者在次要集區有指派，新的連線會被代理到該集區。
  • 教育使用者，在故障區域中開啟的工作階段將會中斷連線；重新連線時會連接到可用的區域。
• 映像與 MSIX app attach 的對等性：
  • 使用 Azure Image Builder 和 Azure Compute Gallery (SIG) 搭配區域複寫來處理映像。
  • 將 MSIX app attach 套件儲存在具備彈性的儲存位置，這些位置在兩個區域都能連線，並將內容複寫到次要區域（例如，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 app attach，使其與套件儲存體複寫和重新註冊的時間一致。

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 才能在沒有 Cloud Witness 的情況下達成仲裁。營運開銷高於 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 layer-7 負載平衡、WAF 及基於路徑的路由。並在每個區域中搭配使用區域備援的後端。
  • 對於非 HTTP、公開且支援健康情況探查的端點，使用 Azure Traffic Manager 進行基於 DNS 的負載平衡。
• 私人 DNS 與名稱解析：
  • 使用 Azure DNS Private Resolver 將條件式轉寄站集中化，以在本地端、Azure VNet 和受控網域之間路由查詢。對於可能需要快速容錯移轉的端點，應發佈低 TTL 的記錄。
  • 對於無法原生無縫容錯移轉的儲存體端點，可考慮使用雙重命名端點，並透過內部 DNS 進行抽象化，以便在事件發生時於主要和災難復原 (DR) 共用之間切換。
• 網路 QoS 與存取：
  • 在廣域網路 (WAN) 上優先處理即時的 AVD 流量 (UDP/TCP)；調整分支路由器的 QoS 設定，以確保 AVD 流量類別有足夠的頻寬，從而減少連線錯誤和延遲。
  • 驗證 Shortpath 的連線能力與防火牆的特定連接埠開放；確保輸出頻寬的規劃符合同時連線數和工作負載組合。

從 RDS 遷移、探索、密度與容量

• RDS 評估：
  • 盤點 Connection Brokers、RD Gateways、RD Web、RD Session Hosts、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、每個系列的 CPU 核心數、IP、NIC、磁碟）；及早提交配額增加請求。

轉換、並存、配額與 Runbook

• 轉換規劃：
  • 平行並存運行：在 AVD 讓先導使用者上線的同時，保持 RDS 的運作。在兩個系統中發佈相同的應用程式，但按群組引導使用者。
  • 先導群組：從 IT 人員與早期採用者開始，擴展到具代表性的部門，然後進行大規模推廣。利用回饋來調整映像檔、FSLogix 設定與擴展規模。
  • 復原：保留 RDS 的存取路徑，直到滿足驗收標準為止。保持使用者設定檔的向後相容性，或為每個群組提供設定檔重設路徑。
• 營運準備：
  • 註冊金鑰：將現有 VM 加入主機集區時，產生註冊金鑰並透過 AVD 代理程式加入；可透過 Azure Image Builder 和後續佈建指令碼來自動化。
  • Workspace 與應用程式群組的維護：發佈最低權限的應用程式群組；將 Desktop 和 RemoteApp 分開；保持 DR 應用程式群組的指派，但視需要降低其視覺上的顯著性。
• Runbook 與自動化：
  • 建立業務連續性與災難復原 (BCDR) 的 Runbook，內容應涵蓋：
    • 宣告事件並將主要集區設為 drain 模式。
    • 擴展 DR 集區並驗證映像檔的一致性。
    • 透過 Cloud Cache 或重新指向 DNS 來切換設定檔儲存體。
    • 透過 Front Door/Traffic Manager 驗證關鍵應用程式的相依性。
    • 與使用者和服務台溝通。
    • 當主要區域恢復時進行回復。
  • 使用 Azure Automation 或 Functions 實作 Runbook，並搭配角色型存取控制與變更核准。
• 成本與保留：
  • 對穩定的基線工作負載使用 Savings Plans 和 Capacity Reservations；對於尖峰容量，則使用隨用隨付搭配自動擴展。排程在非工作時間關閉非生產環境的集區。

實務問題情境

Adobe 必須確保創意與支援團隊在區域性中斷期間能夠持續工作，同時要從地端的 RDS 伺服器陣列遷移到 Azure Virtual Desktop，其中包含數百 TB 的漫遊設定檔與高需求的圖形工作負載。

1. 探索與建立基準

• 使用 Azure Migrate 盤點 RDS 主機、設定檔共用與 LOB 相依性，並擷取圖形與支援群組的 CPU/記憶體/IO 模式。
• 理由：根據實證的基準，能推導出準確的使用者密度目標與 VM 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 集區、驗證 Cloud Cache 的連續性，並透過 Front Door 進行應用程式相依性的容錯移轉。
• 理由：在全面遷移前，證明端到端的容錯移轉能力，包含設定檔與相依性。

9. 配額、保留與自動化

• 預先增加區域性的 vCPU 與 GPU 配額；為基線的 GPU 與 CPU 購買 Capacity Reservations；實作 Azure Automation Runbook 以處理排空、擴展、儲存體切換與通訊。
• 理由：保證事件發生時的容量，並從壓力事件中移除手動步驟。

10. 全面遷移與復原計畫

• 在兩週內分批次遷移剩餘的群組；保留 RDS 存取作為復原路徑，並為每批次設定明確的決策關卡。
• 理由：漸進式轉換能降低風險，並在出現意外問題時保留一個立即的備援方案。

← 監視、診斷與疑難排解 · 所有領域

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Microsoft →