Microsoft AZ-140: 工作階段主機營運、擴展與最佳化 — 學習指南
屬於 Microsoft Azure Virtual Desktop Specialty AZ-140 — 學習指南. 使用經過驗證的解答練習: Microsoft 考試中心, 或參加限時模擬考試: ExamRoll.io.
總覽
Azure Virtual Desktop (AVD) 的工作階段主機維運圍繞著三大核心準則:適當調整規模與效能工程、智慧擴展與電源管理,以及可靠的第二天維運 (day-2 operations)。其目標是在尖峰需求期間提供一致的使用者體驗,同時在離峰時段將支出降到最低,且不犧牲可維護性或可復原性。本節將說明如何透過擴展計畫、排程與容量設定、如清空模式 (drain mode) 等維運狀態,以及健康狀態與註冊的疑難排解,來設計與操作 AVD 自動擴展。接著,本節會將規模調整的指引(包含啟用 GPU 的工作負載)和自動化,與如 reservations、savings plans 及 Azure Hybrid Benefit 等成本優化手段結合在一起。
自動擴展設計:擴展計畫、排程與主機集區目標設定
擴展計畫與目標設定
- 擴展計畫定義了一個集區主機集區 (pooled host pool) 何時以及如何啟動、清空、停止與解除配置工作階段主機。一個擴展計畫可以將多個主機集區設為目標,甚至可以跨區域。
- 每個目標主機集區都會在其自己的時區情境中獨立執行擴展計畫。請使用擴展計畫中每個排程的時區設定,以符合當地的上班時間。
- 排除標籤:定義一個標籤的鍵/值對,讓自動擴展忽略特定的 VM(例如,維運 Canary 或維護前導 VM)。
- 負載平衡模式很重要:廣度優先 (breadth-first) 會將工作階段分散到各個主機(改善即時效能,但會減慢縮減速度);深度優先 (depth-first) 會將工作階段堆疊到較少的主機上(最大化整合度並節省成本)。對於以成本為導向的自動擴展,請使用深度優先並搭配適當的容量閾值。
排程:暖機階段、尖峰階段、降載階段、離峰階段
- 暖機階段 (Ramp-up):在需求來臨前啟動並暖機最基本的機群,然後在超過容量閾值時進行擴展 (scale-out)。
- 尖峰階段 (Peak):保持更多線上容量以最小化延遲和排隊;如果超過閾值,會繼續進行擴展。
- 降載階段 (Ramp-down):將選定的主機置於清空模式,整合工作階段,並在寬限期後關閉閒置主機的電源。
- 離峰階段 (Off-peak):為下班後存取維持一個小的基準線;其餘閒置主機則被解除配置以最小化支出。
容量閾值、最低主機可用性與自動擴展行為
- 容量閾值 (%) 是根據線上主機的總工作階段容量來衡量的。當平均使用率超過閾值時,自動擴展會啟動額外的 VM。使用率取決於每台主機的最大工作階段數和目前的工作階段計數。請根據工作負載進行調整;深度優先建議從 60–70% 開始,廣度優先則為 70–80%。
- 最低主機可用性可以定義為在每個排程階段中保持運作的主機數量或百分比。始終保留至少一台「備用」主機以吸收突發的流量。
- 縮減 (Scale-in) 安全性:自動擴展使用清空模式和「無活動中工作階段」檢查來避免中斷使用者連線。只有閒置的主機才會被停止/解除配置。
電源管理與具成本意識的解除配置
- 停止 (解除配置) 會釋放運算費用;作業系統和資料磁碟會繼續產生儲存費用。自動擴展會在降載和離峰階段解除配置閒置主機。
- 連線時啟動 VM (Start VM on connect) 可以輔助離峰時段的配置,當使用者嘗試連線時啟動已解除配置的 VM。請確保主機集區的受控識別或服務主體在工作階段主機資源群組上擁有 VM 啟動權限。
- 避免在客體作業系統內關機而不解除配置;這會讓 VM 保持在已配置且可計費的狀態。
維運狀態、維護與健康狀態:清空模式、通知與註冊
清空模式與維護時段
- 清空模式 (AllowNewSession=false) 會阻止新的登入,同時允許現有的工作階段完成。可用於修補、更新代理程式、更換映像檔或進行縮減。
- 維護方法:將主機設定為清空模式,等待其閒置,在通知後優雅地登出滯留的工作階段,然後套用更新並重新開機。驗證健康狀態/活動訊號並重新啟用新工作階段。
使用者通知策略
- 擴展計畫通知:在降載期間設定登出訊息和寬限期。請使用清晰、有時限的語言。
- 補充通知:使用 Azure Automation (Send-AzVMRunCommand,透過 PowerShell 發送快顯通知) 或 Endpoint Manager,在維護前顯示工作階段內訊息。
工作階段主機狀態、活動訊號與代理程式健康狀態
- 典型狀態:Available、Unavailable (NoHeartbeat)、NeedsAssistance、Unhealthy、Shutdown、NotJoinedToDomain、Upgrading。
- 活動訊號/代理程式的先決條件:對 AVD 服務端點的輸出 443 連線(使用 AzureVirtualDesktop 服務標籤)、穩定的 DNS 解析、時間同步,以及(如果適用)成功的網域加入。
- 代理程式服務:Remote Desktop Agent Loader 和 Remote Desktop Agent 必須正在執行。如果允許輸出存取,AVD 代理程式和並存堆疊 (side-by-side stack) 會自動更新。
註冊與疑難排解
- 若要將現有的 VM 加入主機集區,請建立一個註冊權杖(有時效性),並使用該權杖安裝/註冊 AVD 代理程式。
- 常見的故障隔離步驟:
- 檢查主機在主機集區中是否顯示為已註冊 (Registered) 且可用 (Available);如果不是,請使用新的權杖重新註冊。
- 檢查事件檢視器 (Event Viewer):在 Microsoft-RDInfra-RDAgent、Microsoft-RDInfra-RDAgentBootLoader 和 RDS/TerminalServices 記錄檔中尋找連線或驗證錯誤。
- 驗證 DNS:網域解析和服務端點解析必須成功;如果使用 Azure AD DS,請確保 VNet DNS 指向受控的網域控制站。
- 確認 Windows 防火牆或網路安全規則允許輸出 443 連線,且沒有 TLS 攔截破壞服務信任。
實用的自動化範例
# Put a session host in drain mode (no new sessions)
Update-AzWvdSessionHost -ResourceGroupName rg-avd -HostPoolName hp-finance `
-Name host1.contoso.com -AllowNewSession:$false
# Gracefully logoff idle users after notice (example)
Invoke-AzVMRunCommand -ResourceGroupName rg-avd -Name host1 `
-CommandId RunPowerShellScript -ScriptPath .\Notify-And-Logoff.ps1
規模調整、使用率與啟用 GPU 的工作負載
VM 大小選擇與工作負載驅動的規模調整
- 從工作負載的特性分析開始:辦公室/生產力、使用 Microsoft 365 Apps 與 Teams 最佳化的知識工作者、開發人員/工程師,或圖形/3D。
- CPU:將持續的 CPU 使用率維持在 70–75% 以下,短期峰值則低於 85%。監控 Processor(_Total)% Processor Time 與 System\Processor Queue Length。
- 記憶體:目標是已認可 (committed) 記憶體 <80%,且每個主機的 Memory\Available MBytes 高於 500 MB;注意分頁 (paging) 活動。FSLogix 快取可能會增加工作集 (working set)——請相應地調整大小。
- 儲存:使用者體驗取決於 FSLogix 設定檔的 IOPS 和延遲。針對暫存/快取密集型情境可使用 Premium SSD v2、Ultra Disk,而高 IOPS 的設定檔則可使用 Azure Files Premium 或 Azure NetApp Files。對於非常龐大的部署或要求最低延遲的設定檔,Azure NetApp Files 能提供最佳的一致性。
- 初始基準 (多重工作階段):
- 輕度生產力:4–8 vCPU、16–32 GB RAM;採用廣度優先 (breadth-first) 以求回應速度。
- 中度知識工作者:8–16 vCPU、32–64 GB RAM;採用深度優先 (depth-first) 以求成本效益。
- 重度開發/編譯/資料:16–32 vCPU、64–128 GB RAM;考慮使用專用集區。
啟用 GPU 的工作階段主機
- 對於 CAD/GIS/3D/影片編輯和複雜的視覺化,可使用 NVads A10 v5 以獲得精細的 vGPU 設定檔和強大的性價比;在適當情況下也可考慮 NV v4/v5 系列。
- 在 N 系列 VM 上部署適用於 Windows 的 NVIDIA GPU 驅動程式擴充功能。驗證硬體編碼:啟用 AVC/H.264,並在有益時透過原則設定「為遠端桌面使用硬體編碼」。
- 使用 Performance Counters (GPU 引擎使用率、GPU 記憶體) 和 Azure Monitor 指標來監控 GPU。確保有足夠的 CPU 餘裕;圖形密集型應用程式對 CPU 資源不足 (starvation) 仍然很敏感。
遙測與反覆調校
- 為 AVD 啟用 Azure Monitor 的 insights 和 Log Analytics。追蹤 CPU、記憶體、FSLogix 設定檔延遲、登入持續時間、中斷連線和代理時間 (brokering times)。
- 根據觀察到的資源競爭 (contention) 情況,調整主機集區的 MaxSessionLimit 和負載平衡模式,然後重新調整自動縮放的閾值以匹配。
成本最佳化:電源管理、自動調整規模、保留、節省方案與 AHB
將擴展規模與營業時間對齊
- 使用深度優先搭配保守的容量閾值,以整合工作階段並加速縮減規模。結合離峰時段解除配置與「連線時啟動 VM」(Start VM on connect),以供較晚或罕見的存取需求。
- 設定一個小但非零的最低主機數量,以避免冷啟動風暴。
保留與節省方案
- 保留 (Reservations):1 年期或 3 年期的 VM 保留可鎖定特定區域中的特定 SKU,以獲得最大折扣;適用於大部分時間運行的基準容量(例如,日間尖峰機群)。
- Compute Savings Plans:提供跨 VM 系列與區域的彈性折扣;當混合使用不同大小的 VM 或在 SKU 準確預測性較低的動態資產環境中很有用。
- 儲存體保留:Azure Files 保留容量可大規模降低 FSLogix 儲存成本。
Azure Hybrid Benefit (AHB) 與授權
- 將 AHB 應用於 Windows Server 和符合資格的 Windows 用戶端工作負載,以減少運算作業系統的授權費用。確保授權資格與合規性。
- 對於 Microsoft 365 部署,確認授權涵蓋適用的 Windows Enterprise multi-session 和 Microsoft 365 Apps。
維運腳本與 Runbook
- 使用 Azure Automation 或 GitHub Actions 進行:
- 維護前後的機群清空/啟用順序。
- 週一或公眾假期後的擴展規模前暖機腳本。
- 健康狀態修復(重新啟動代理程式服務、若心跳遺失則重新註冊主機)。
- 由標籤驅動的協調流程使選擇性操作變得簡單(例如,標記 Environment=Pilot 以將其從縮減規模中排除)。
- 使用 Azure Automation 或 GitHub Actions 進行:
# Start or stop idle hosts by tag (supplemental to native autoscale)
$hosts = Get-AzWvdSessionHost -ResourceGroupName rg-avd -HostPoolName hp-ops
foreach ($h in $hosts) {
if ($h.Session -eq 0 -and $h.Tags["KeepOnline"] -ne "true") {
Stop-AzVM -ResourceGroupName rg-avd -Name ($h.Name.Split("/")[1]) -Force -StayProvisioned:$false
}
}
實務問題情境
IKEA 面臨平日由 3D 規劃人員、產品工程師與客服中心人員使用遠端應用程式所造成的流量尖峰。晚上和週末的需求較低。由 GPU 支援的工作階段必須保持反應靈敏,同時將整體運算成本降至最低。
依工作負載區分主機集區
- 建立三個集區式主機集區:GPU-CAD (NVads A10 v5)、KnowledgeWorker (D/E-series) 和 ContactCenter (D-series)。
- 原因:將 VM 大小與密度與不同的效能設定檔對齊;實現獨立的自動調整規模與維護時段。
附加單一擴展計畫,並依營業時間排程
- 定義擴增時段為 07:00、尖峰時段為 09:00–17:00、縮減時段為 17:00–19:00,其餘為離峰時段;將時區設定為每個集區所在的區域。
- 原因:確保在使用者到達前容量已準備就緒,在下班後優雅地進行整合並關閉電源,並遵循各區域的時間。
依集區調整容量閾值與最低主機可用性
- GPU-CAD:廣度優先,容量閾值 70%,最低 30% 主機在線;KnowledgeWorker:深度優先,閾值 65%,最低 10%;ContactCenter:深度優先,閾值 70%,最低 15%。
- 原因:GPU 工作負載偏好更廣泛的分散以提高反應速度;辦公室工作負載可從整合中獲益以降低成本;客服中心需要穩定的備用容量以應對輪班變更。
為 KnowledgeWorker 和 ContactCenter 啟用「連線時啟動 VM」(Start VM on connect)
- 授予主機集區受控識別 VM 啟動權限;將離峰時段的最低主機數量維持在較低水平。
- 原因:減少閒置執行階段費用,同時為非預期的下班後登入保留即時存取能力。
實作維護與通知工作流程
- 在 Patch Tuesday 之前:透過標籤將每個集區的 20% 設為清空模式;提前 30 分鐘通知使用者;待主機閒置後,進行修補、重新啟動、驗證代理程式/心跳,然後輪替至下一批。
- 原因:滾動式清空可避免大規模登出,維持服務連續性,並減少服務台的支援案件尖峰。
使用 Azure Monitor for AVD 進行監控與迭代
- 追蹤 CPU、記憶體、GPU 使用率、登入持續時間、FSLogix 延遲;每月調整 MaxSessionLimit 和自動調整規模的閾值。
- 原因:由數據驅動的調整可隨著使用模式的演變,維持 SLA 並控制支出。
應用成本槓桿
- 為 KnowledgeWorker 和 ContactCenter 的平日尖峰基準容量保留 3 年期容量;對變動的 GPU 需求使用 Compute Savings Plan;在符合資格的情況下應用 Azure Hybrid Benefit。
- 原因:保留為可預測的基礎負載鎖定最大折扣;節省方案能彈性應對較難預測的 GPU 尖峰;AHB 降低作業系統授權成本。
強化註冊與健康狀態
- 維護一個常備的 Runbook,以重新註冊任何顯示 NoHeartbeat 的主機,並驗證 DNS/時間。為診斷主機保留排除標籤。
- 原因:迅速、自動化的修復可限制對使用者的影響,並在發生非預期的代理程式問題時保留容量。
透過此設計,IKEA 不僅滿足了日間的效能目標(包含 GPU 的反應速度),同時積極地在離峰時段解除配置容量並自動化維護,最終帶來穩定的使用者體驗與可衡量的成本降低。
← FSLogix、設定檔與使用者資料 · 所有領域 · 應用程式與終端使用者體驗 →
練習這些題目 → · 在 ExamRoll.io 上限時練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通過考試 →