Microsoft AZ-140: Operacje na hostach sesji, skalowanie i optymalizacja — Przewodnik do nauki

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

Część Microsoft Azure Virtual Desktop Specialty AZ-140 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Operacje na hostach sesji w Azure Virtual Desktop (AVD) koncentrują się na trzech podstawowych dyscyplinach: optymalizacji rozmiaru i inżynierii wydajności, inteligentnym skalowaniu i zarządzaniu zasilaniem oraz niezawodnych operacjach utrzymaniowych (day-2). Celem jest zapewnienie spójnego doświadczenia użytkownika podczas szczytowego zapotrzebowania przy jednoczesnej minimalizacji wydatków poza godzinami pracy, a wszystko to bez uszczerbku dla utrzymywalności i odzyskiwalności. Ta sekcja wyjaśnia, jak projektować i obsługiwać autoskalowanie AVD za pomocą planów skalowania, konfiguracji harmonogramów i pojemności, stanów operacyjnych, takich jak tryb drenażu, oraz jak rozwiązywać problemy ze stanem i rejestracją. Następnie łączy wskazówki dotyczące doboru rozmiaru (w tym dla obciążeń wykorzystujących GPU) i automatyzację z dźwigniami optymalizacji kosztów, takimi jak rezerwacje (reservations), plany oszczędnościowe (savings plans) i Azure Hybrid Benefit.

Projektowanie autoskalowania: plany skalowania, harmonogramy i targetowanie pul hostów

• Plany skalowania i targetowanie

  • Plan skalowania definiuje, kiedy i jak pula hostów (pooled host pool) uruchamia, wprowadza w tryb drenażu, zatrzymuje i cofa alokację hostów sesji. Jeden plan skalowania może być skierowany do wielu pul hostów, nawet w różnych regionach.
  • Każda docelowa pula hostów wykonuje plan skalowania niezależnie, we własnym kontekście strefy czasowej. Użyj ustawienia strefy czasowej planu skalowania dla każdego harmonogramu, aby dostosować go do lokalnych godzin pracy.
  • Tag wykluczenia: zdefiniuj parę klucz/wartość tagu, aby autoskalowanie ignorowało określone maszyny wirtualne (np. wdrożenia testowe typu „canary” lub maszyny do pilotażu konserwacji).
  • Tryb równoważenia obciążenia ma znaczenie: tryb wszerz (breadth-first) rozkłada sesje na wiele hostów (poprawia natychmiastową wydajność, spowalnia skalowanie w dół); tryb wgłąb (depth-first) kumuluje sesje na mniejszej liczbie hostów (maksymalizuje konsolidację i oszczędności). W przypadku autoskalowania zorientowanego na koszty, używaj trybu wgłąb z odpowiednimi progami pojemności.

• Harmonogramy: faza rozruchu (ramp-up), faza szczytu (peak), faza wygaszania (ramp-down), faza poza szczytem (off-peak)

  • Faza rozruchu (Ramp-up): uruchamia i przygotowuje minimalną flotę przed przewidywanym wzrostem zapotrzebowania, a następnie skaluje w górę po przekroczeniu progów pojemności.
  • Faza szczytu (Peak): utrzymuje większą pojemność online, aby zminimalizować opóźnienia i kolejkowanie; skalowanie w górę jest kontynuowane, jeśli progi zostaną przekroczone.
  • Faza wygaszania (Ramp-down): przełącza wybrane hosty w tryb drenażu, konsoliduje sesje, a po okresie prolongaty wyłącza bezczynne hosty.
  • Faza poza szczytem (Off-peak): utrzymuje niewielką bazową liczbę maszyn dla dostępu po godzinach pracy; pozostałe bezczynne hosty mają cofaną alokację, aby zminimalizować wydatki.

• Progi pojemności, minimalna dostępność hostów i zachowanie autoskalowania

  • Próg pojemności (%) jest mierzony w stosunku do całkowitej pojemności sesji na hostach online. Gdy średnie wykorzystanie przekroczy ten próg, autoskalowanie uruchamia dodatkowe maszyny wirtualne. Wykorzystanie zależy od maksymalnej liczby sesji na hosta i bieżącej liczby sesji. Dostosuj wartość do obciążenia; zacznij od 60–70% dla trybu wgłąb (depth-first) i 70–80% dla trybu wszerz (breadth-first).
  • Minimalna dostępność hostów może być zdefiniowana jako liczba lub procent hostów, które mają pozostać uruchomione w każdej fazie harmonogramu. Zawsze utrzymuj co najmniej jednego „zapasowego” hosta, aby mógł obsłużyć nagłe skoki obciążenia.
  • Bezpieczeństwo skalowania w dół: autoskalowanie używa trybu drenażu i sprawdza brak aktywnych sesji, aby uniknąć rozłączania użytkowników. Tylko bezczynne hosty są zatrzymywane/mają cofaną alokację.

• Zarządzanie zasilaniem i cofanie alokacji z uwzględnieniem kosztów

  • Zatrzymanie (cofnięcie alokacji) zwalnia z opłat za moc obliczeniową; dyski systemowe i dyski z danymi nadal generują opłaty za magazyn. Autoskalowanie cofa alokację bezczynnych hostów podczas fazy wygaszania i poza szczytem.
  • Opcja „Start VM on connect” może uzupełniać strategię dla fazy poza szczytem, uruchamiając maszyny wirtualne z cofniętą alokacją, gdy użytkownik próbuje się połączyć. Upewnij się, że tożsamość zarządzana lub jednostka usługi (service principal) puli hostów ma uprawnienia „VM Start” w grupie zasobów hostów sesji.
  • Unikaj zamykania systemu z poziomu gościa bez cofania alokacji; pozostawia to maszynę wirtualną w stanie alokacji, za który naliczane są opłaty.

Stan operacyjny, konserwacja i kondycja: tryb drenażu, powiadomienia i rejestracja

• Tryb drenażu i okna konserwacyjne

  • Tryb drenażu (AllowNewSession=false) uniemożliwia nowe logowania, pozwalając jednocześnie na dokończenie istniejących sesji. Używaj go do instalowania poprawek, aktualizacji agentów, wymiany obrazów lub podczas skalowania w dół.
  • Podejście do konserwacji: ustaw hosta (lub hosty) w tryb drenażu, poczekaj na brak aktywności, grzecznie wyloguj pozostałe sesje po wysłaniu powiadomienia, a następnie zastosuj aktualizacje i uruchom ponownie. Zweryfikuj kondycję/puls (heartbeat) i ponownie włącz obsługę nowych sesji.

• Strategia powiadamiania użytkowników

  • Powiadomienia z planu skalowania: skonfiguruj komunikat o wylogowaniu i okres prolongaty podczas fazy wygaszania. Używaj jasnego, określonego w czasie języka.
  • Powiadomienia uzupełniające: użyj Azure Automation (Send-AzVMRunCommand, powiadomienia „toast” przez PowerShell) lub Endpoint Manager, aby wyświetlać komunikaty wewnątrz sesji przed rozpoczęciem konserwacji.

• Status hosta sesji, puls (heartbeat) i kondycja agenta

  • Typowe statusy: Available, Unavailable (NoHeartbeat), NeedsAssistance, Unhealthy, Shutdown, NotJoinedToDomain, Upgrading.
  • Wymagania wstępne dla pulsu/agenta: ruch wychodzący na porcie 443 do punktów końcowych usługi AVD (użyj tagu usługi AzureVirtualDesktop), stabilne rozwiązywanie nazw DNS, synchronizacja czasu i pomyślne dołączenie do domeny (jeśli dotyczy).
  • Usługi agenta: Usługi Remote Desktop Agent Loader i Remote Desktop Agent muszą być uruchomione. Agent AVD i stos „side-by-side” aktualizują się automatycznie, jeśli dozwolony jest ruch wychodzący.

• Rejestracja i rozwiązywanie problemów

  • Aby dołączyć istniejące maszyny wirtualne do puli hostów, utwórz token rejestracyjny (ważny przez ograniczony czas) i zainstaluj/zarejestruj agenta AVD przy użyciu tego tokenu.
  • Typowe kroki izolowania błędów:
    • Sprawdź, czy host jest widoczny jako „Registered” i „Available” w puli hostów; jeśli nie, zarejestruj go ponownie przy użyciu nowego tokenu.
    • Sprawdź Podgląd zdarzeń (Event Viewer): logi Microsoft-RDInfra-RDAgent, Microsoft-RDInfra-RDAgentBootLoader oraz RDS/TerminalServices w poszukiwaniu błędów łączności lub uwierzytelniania.
    • Zweryfikuj DNS: rozwiązywanie nazw domenowych i nazw punktów końcowych usługi musi działać poprawnie; jeśli używasz Azure AD DS, upewnij się, że serwery DNS w sieci wirtualnej (VNet) wskazują na zarządzane kontrolery domeny.
    • Potwierdź, że reguły Zapory systemu Windows lub sieciowe grupy bezpieczeństwa (NSG) zezwalają na ruch wychodzący na porcie 443 i że żadne przechwytywanie TLS nie narusza zaufania do usługi.

• Przydatne przykłady automatyzacji

# 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

Wymiarowanie, wykorzystanie i obciążenia robocze z obsługą GPU

• Wybór rozmiaru maszyny wirtualnej i wymiarowanie w oparciu o obciążenie robocze
  • Rozpocznij od charakterystyki obciążenia roboczego: praca biurowa/produktywność, pracownik wiedzy z aplikacjami Microsoft 365 i optymalizacją Teams, deweloper/inżynier lub grafik/3D.
  • CPU: utrzymuj stałe obciążenie CPU poniżej 70–75% z krótkimi skokami poniżej 85%. Monitoruj

undefined

i

undefined

.

• Pamięć: celuj w <80% zatwierdzonej pamięci (committed), z

undefined

powyżej 500 MB na hosta; obserwuj stronicowanie (paging). Pamięć podręczna FSLogix może zwiększyć zestaw roboczy (working set) — odpowiednio dobierz rozmiar.

• Magazyn danych: doświadczenie użytkownika (user experience) zależy od liczby IOPS i opóźnień profilu FSLogix. Użyj Premium SSD v2, Ultra Disk dla scenariuszy intensywnie korzystających z plików tymczasowych/pamięci podręcznej oraz Azure Files Premium lub Azure NetApp Files dla profili o wysokiej liczbie IOPS. W przypadku bardzo dużych wdrożeń lub profili wymagających najniższych opóźnień, Azure NetApp Files zapewnia najlepszą spójność.

• Początkowe punkty odniesienia (multi-session):

  • Lekka praca biurowa: 4–8 vCPU, 16–32 GB RAM; skalowanie wszerz (breadth-first) dla responsywności.
  • Średnie obciążenie pracownika wiedzy: 8–16 vCPU, 32–64 GB RAM; skalowanie w głąb (depth-first) dla efektywności kosztowej.
  • Ciężkie zadania deweloperskie/kompilacja/dane: 16–32 vCPU, 64–128 GB RAM; rozważ dedykowane pule.

• Hosty sesji z obsługą GPU

  • Dla aplikacji CAD/GIS/3D/edycji wideo i złożonych wizualizacji, użyj maszyn NVads A10 v5 dla granularnych profili vGPU i dobrego stosunku ceny do wydajności; rozważ rodziny NV v4/v5 tam, gdzie jest to stosowne.
  • Wdróż rozszerzenie NVIDIA GPU Driver Extension for Windows na maszynach wirtualnych z serii N. Zweryfikuj kodowanie sprzętowe: włącz AVC/H.264 i skonfiguruj „Use hardware encoding for Remote Desktop” za pomocą zasad (policy), gdy jest to korzystne.
  • Monitoruj GPU za pomocą liczników wydajności (Performance Counters) (wykorzystanie silnika GPU, pamięć GPU) i metryk Azure Monitor. Zapewnij wystarczający zapas mocy CPU; aplikacje intensywnie korzystające z grafiki są nadal wrażliwe na niedobór zasobów CPU (CPU starvation).

• Telemetria i iteracyjne dostrajanie

  • Włącz Azure Monitor for AVD insights i Log Analytics. Śledź CPU, pamięć, opóźnienia profilu FSLogix, czas logowania, rozłączenia i czasy brokeringu.
  • Dostosuj MaxSessionLimit puli hostów i tryb równoważenia obciążenia na podstawie zaobserwowanej rywalizacji o zasoby (contention), a następnie dostrój progi automatycznego skalowania, aby je dopasować.

Optymalizacja kosztów: Zasilanie, autoskalowanie, rezerwacje, plany oszczędnościowe i AHB

• Dopasuj skalowanie do godzin pracy

  • Używaj strategii „najpierw w głąb” (depth-first) z konserwatywnymi progami pojemności, aby konsolidować sesje i przyspieszać skalowanie w dół (scale-in). Połącz to z dealokacją poza godzinami szczytu i funkcją „Uruchamianie maszyny wirtualnej przy połączeniu” (Start VM on connect) dla późnego/rzadkiego dostępu.
  • Ustaw małą, ale niezerową minimalną liczbę hostów, aby uniknąć „burzy zimnych startów” (cold-start storms).

• Rezerwacje i plany oszczędnościowe

  • Rezerwacje: 1-roczne lub 3-letnie rezerwacje maszyn wirtualnych blokują określone jednostki SKU w konkretnych regionach, zapewniając największe zniżki; idealne dla bazowej pojemności, która działa przez większość czasu (np. flota w godzinach szczytu w ciągu dnia).
  • Plany oszczędnościowe na zasoby obliczeniowe (Compute Savings Plans): oferują elastyczne zniżki na różne rodziny maszyn wirtualnych i regiony; przydatne przy mieszaniu rozmiarów lub dla dynamicznych środowisk, gdzie dokładna przewidywalność SKU jest niższa.
  • Rezerwacje magazynu: Zarezerwowana pojemność Azure Files może zredukować koszty magazynu FSLogix na dużą skalę.

• Azure Hybrid Benefit (AHB) i licencjonowanie

  • Zastosuj AHB do obciążeń Windows Server i kwalifikujących się obciążeń klienckich Windows, aby zmniejszyć opłaty licencyjne za system operacyjny zasobów obliczeniowych. Upewnij się co do kwalifikowalności i zgodności licencji.
  • W przypadku wdrożeń Microsoft 365, potwierdź, że licencjonowanie obejmuje Windows Enterprise multi-session i Microsoft 365 Apps, tam gdzie ma to zastosowanie.

• Skrypty operacyjne i elementy runbook

  • Użyj Azure Automation lub GitHub Actions do:
    • Sekwencji opróżniania/włączania floty (drain/enable) przed i po konserwacji.
    • Skryptów rozgrzewających (warm-up) przed skalowaniem w poniedziałki lub po świętach.
    • Naprawy stanu kondycji (restart usług agenta, ponowna rejestracja hosta w przypadku utraty pulsu).
  • Orkiestracja oparta na tagach upraszcza selektywne operacje (np. tag Environment=Pilot, aby wykluczyć ze skalowania w dół).

# 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
  }
}

Praktyczny scenariusz problemowy

IKEA doświadcza skoków obciążenia w dni robocze ze strony projektantów 3D, inżynierów produktu i personelu call center korzystającego z aplikacji zdalnych. Wieczorami i w weekendy zapotrzebowanie jest niskie. Sesje wspierane przez GPU muszą pozostać responsywne, przy jednoczesnej minimalizacji ogólnych kosztów zasobów obliczeniowych.

1. Podziel pule hostów według obciążenia

   • Utwórz trzy pule hostów typu „pooled”: GPU-CAD (NVads A10 v5), KnowledgeWorker (seria D/E) i ContactCenter (seria D).
   • Dlaczego: Dopasowuje to rozmiar i gęstość maszyn wirtualnych do odrębnych profili wydajności; umożliwia niezależne autoskalowanie i okna konserwacyjne.

2. Dołącz jeden plan skalowania z harmonogramami według godzin pracy

   • Zdefiniuj fazę wzrostu (ramp-up) o 07:00, szczyt 09:00–17:00, fazę spadku (ramp-down) 17:00–19:00, a poza tymi godzinami okres poza szczytem; ustaw strefę czasową na region każdej puli.
   • Dlaczego: Gwarantuje to, że pojemność jest gotowa przed przybyciem użytkowników, konsoliduje i wyłącza zasoby w sposób kontrolowany po godzinach pracy oraz uwzględnia czasy regionalne.

3. Dostosuj progi pojemności i minimalną dostępność hostów dla każdej puli

   • GPU-CAD: „najpierw wszerz” (breadth-first), próg pojemności 70%, minimum 30% hostów online; KnowledgeWorker: „najpierw w głąb” (depth-first), próg 65%, minimum 10%; ContactCenter: „najpierw w głąb”, próg 70%, minimum 15%.
   • Dlaczego: Obciążenia GPU preferują szersze rozproszenie dla lepszej responsywności; obciążenia biurowe zyskują na konsolidacji w celu cięcia kosztów; call center wymaga stałej rezerwy na zmiany wacht.

4. Włącz funkcję „Uruchamianie maszyny wirtualnej przy połączeniu” (Start VM on connect) dla pul KnowledgeWorker i ContactCenter

   • Nadaj tożsamości zarządzanej puli hostów uprawnienia „VM Start”; utrzymuj niskie minimum hostów poza godzinami szczytu.
   • Dlaczego: Redukuje to opłaty za bezczynny czas działania, zachowując jednocześnie dostęp „just-in-time” dla nieoczekiwanych logowań po godzinach.

5. Wdróż przepływ pracy dotyczący konserwacji i powiadomień

   • Przed Patch Tuesday: przełącz 20% każdej puli w tryb opróżniania (drain mode) za pomocą tagu; powiadom użytkowników 30 minut wcześniej; po zwolnieniu sesji, zainstaluj poprawki, uruchom ponownie, zweryfikuj agenta/puls, a następnie przejdź do następnej partii.
   • Dlaczego: Kroczące opróżnianie zapobiega masowym wylogowaniom, zachowuje ciągłość usług i zmniejsza skoki obciążenia dla działu pomocy technicznej.

6. Monitoruj i iteruj za pomocą Azure Monitor for AVD

   • Śledź wykorzystanie CPU, pamięci, GPU, czas trwania logowania, opóźnienie FSLogix; co miesiąc dostosowuj MaxSessionLimit i progi autoskalowania.
   • Dlaczego: Dostrajanie oparte na danych utrzymuje SLA i kontroluje wydatki w miarę ewolucji wzorców użytkowania.

7. Zastosuj dźwignie kosztowe

   • Zarezerwuj 3-letnią pojemność dla bazowego szczytu w dni robocze w pulach KnowledgeWorker i ContactCenter; użyj planu Compute Savings Plan dla zmiennego zapotrzebowania na GPU; zastosuj Azure Hybrid Benefit tam, gdzie jest to możliwe.
   • Dlaczego: Rezerwacje zapewniają największe oszczędności dla przewidywalnego obciążenia bazowego; plany oszczędnościowe są elastyczne wobec mniej przewidywalnych szczytów GPU; AHB obniża koszty licencjonowania systemu operacyjnego.

8. Wzmocnij proces rejestracji i kondycji

   • Utrzymuj stały element runbook do ponownej rejestracji każdego hosta, który wykazuje stan NoHeartbeat, i weryfikuj DNS/czas. Zachowaj tagi wykluczające dla hostów diagnostycznych.
   • Dlaczego: Szybka, zautomatyzowana naprawa ogranicza wpływ na użytkownika i zachowuje pojemność podczas nieoczekiwanych problemów z agentem.

Dzięki tej architekturze IKEA spełnia cele wydajnościowe w ciągu dnia — w tym responsywność GPU — jednocześnie agresywnie dealokując pojemność poza godzinami pracy i automatyzując konserwację, co skutkuje stabilnym doświadczeniem użytkownika i mierzalną redukcją kosztów.

← FSLogix · Wszystkie domeny · Aplikacje i doświadczenie użytkownika końcowego →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Microsoft →