Microsoft AZ-140: Sitzungshost-Betrieb, Skalierung und Optimierung — Lernleitfaden

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

Teil des Microsoft Azure Virtual Desktop Specialty AZ-140 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Übersicht

Der Betrieb von Sitzungshosts in Azure Virtual Desktop (AVD) konzentriert sich auf drei Kerndisziplinen: Right-Sizing und Performance-Engineering, intelligente Skalierung und Energieverwaltung sowie zuverlässiger Day-2-Betrieb. Das Ziel ist es, ein konsistentes Benutzererlebnis während der Spitzennachfrage zu gewährleisten und gleichzeitig die Ausgaben außerhalb der Geschäftszeiten zu minimieren, ohne dabei die Wartbarkeit oder Wiederherstellbarkeit zu beeinträchtigen. Dieser Abschnitt erklärt, wie man die AVD-Autoskalierung mit Skalierungsplänen, Zeitplan- und Kapazitätskonfigurationen, Betriebszuständen wie dem Drain-Modus und der Fehlerbehebung bei Integrität und Registrierung entwirft und betreibt. Anschließend werden Anleitungen zur Dimensionierung (einschließlich GPU-fähiger Workloads) und Automatisierung mit Hebeln zur Kostenoptimierung wie Reservierungen, Sparplänen und dem Azure Hybrid Benefit verknüpft.

Entwurf der Autoskalierung: Skalierungspläne, Zeitpläne und Hostpool-Zuweisung

• Skalierungspläne und Zuweisung

  • Ein Skalierungsplan legt fest, wann und wie ein gepoolter Hostpool Sitzungshosts startet, in den Drain-Modus versetzt, stoppt und dealloziert. Ein Skalierungsplan kann auf mehrere Hostpools ausgerichtet sein, sogar über Regionen hinweg.
  • Jeder zugewiesene Hostpool führt den Skalierungsplan unabhängig in seinem eigenen Zeitzonenkontext aus. Verwenden Sie die Zeitzoneneinstellung des Skalierungsplans pro Zeitplan, um ihn an die lokalen Geschäftszeiten anzupassen.
  • Ausschluss-Tag: Definieren Sie ein Tag-Schlüssel/Wert-Paar, damit die Autoskalierung bestimmte VMs ignoriert (z. B. für betriebliche Canaries oder Wartungspiloten).
  • Der Lastenausgleichsmodus ist entscheidend: Breitenorientiert (breadth-first) verteilt Sitzungen auf alle Hosts (verbessert die sofortige Leistung, verlangsamt das Herunterskalieren); Tiefenorientiert (depth-first) bündelt Sitzungen auf weniger Hosts (maximiert die Konsolidierung und Kosteneinsparungen). Für eine kostenorientierte Autoskalierung verwenden Sie den tiefenorientierten Modus mit entsprechenden Kapazitätsschwellenwerten.

• Zeitpläne: Ramp-up, Peak, Ramp-down, Off-Peak

  • Ramp-up: Startet und wärmt die minimale Flotte vor dem erwarteten Bedarf auf und skaliert dann hoch, wenn Kapazitätsschwellenwerte überschritten werden.
  • Peak: Hält mehr Kapazität online, um Latenz und Warteschlangen zu minimieren; das Hochskalieren wird fortgesetzt, wenn Schwellenwerte überschritten werden.
  • Ramp-down: Versetzt ausgewählte Hosts in den Drain-Modus, konsolidiert Sitzungen und fährt nach einer Schonfrist inaktive Hosts herunter.
  • Off-Peak: Behält eine kleine Baseline für den Zugriff außerhalb der Geschäftszeiten bei; verbleibende inaktive Hosts werden dealloziert, um die Ausgaben zu minimieren.

• Kapazitätsschwellenwerte, Mindestverfügbarkeit von Hosts und Verhalten der Autoskalierung

  • Der Kapazitätsschwellenwert (%) wird an der Gesamtsitzungskapazität der Online-Hosts gemessen. Wenn die durchschnittliche Auslastung den Schwellenwert überschreitet, startet die Autoskalierung zusätzliche VMs. Die Auslastung wird durch die maximale Anzahl von Sitzungen pro Host und die aktuellen Sitzungszahlen bestimmt. Passen Sie dies pro Workload an; beginnen Sie mit 60–70 % für den tiefenorientierten und 70–80 % für den breitenorientierten Modus.
  • Die Mindestverfügbarkeit von Hosts kann als Anzahl oder Prozentsatz der Hosts definiert werden, die in jeder Zeitplanphase betriebsbereit bleiben sollen. Halten Sie immer mindestens einen „Reserve“-Host bereit, um plötzliche Lastspitzen abzufangen.
  • Sicherheit beim Herunterskalieren: Die Autoskalierung verwendet den Drain-Modus und Prüfungen auf „keine aktiven Sitzungen“, um zu vermeiden, dass Benutzer getrennt werden. Nur inaktive Hosts werden angehalten/dealloziert.

• Energieverwaltung und kostenbewusste Deallokation

  • Anhalten (Deallokieren) gibt Compute-Gebühren frei; für Betriebssystem- und Daten-Datenträger fallen weiterhin Speichergebühren an. Die Autoskalierung dealloziert inaktive Hosts während der Ramp-down- und Off-Peak-Phasen.
  • „VM bei Verbindungsaufbau starten“ kann die Off-Peak-Konfiguration ergänzen, indem deallozierte VMs gestartet werden, wenn ein Benutzer versucht, eine Verbindung herzustellen. Stellen Sie sicher, dass die verwaltete Identität oder der Dienstprinzipal des Hostpools die Berechtigung „VM Start“ für die Ressourcengruppe der Sitzungshosts besitzt.
  • Vermeiden Sie das Herunterfahren innerhalb des Gastbetriebssystems ohne Deallokation; dadurch bleibt die VM zugewiesen und kostenpflichtig.

Betriebszustand, Wartung und Integrität: Drain-Modus, Benachrichtigungen und Registrierung

• Drain-Modus und Wartungsfenster

  • Der Drain-Modus (AllowNewSession=false) verhindert neue Anmeldungen, während bestehende Sitzungen abgeschlossen werden können. Verwenden Sie ihn zum Patchen, zur Aktualisierung von Agents, zum Austausch von Images oder zum Herunterskalieren.
  • Wartungsansatz: Setzen Sie den/die Host(s) in den Drain-Modus, warten Sie auf Inaktivität, melden Sie verbleibende Sitzungen nach einer Benachrichtigung ordnungsgemäß ab, wenden Sie dann Updates an und starten Sie neu. Überprüfen Sie die Integrität/den Heartbeat und aktivieren Sie neue Sitzungen wieder.

• Strategie zur Benutzerbenachrichtigung

  • Benachrichtigungen des Skalierungsplans: Konfigurieren Sie die Abmeldenachricht und die Schonfrist während des Ramp-down. Verwenden Sie eine klare, zeitlich definierte Sprache.
  • Zusätzliche Benachrichtigungen: Verwenden Sie Azure Automation (Send-AzVMRunCommand, Toast-Benachrichtigungen über PowerShell) oder Endpoint Manager, um vor Wartungsarbeiten Nachrichten innerhalb der Sitzung anzuzeigen.

• Status des Sitzungshosts, Heartbeat und Agenten-Integrität

  • Typische Status: Available, Unavailable (NoHeartbeat), NeedsAssistance, Unhealthy, Shutdown, NotJoinedToDomain, Upgrading.
  • Voraussetzungen für Heartbeat/Agent: Ausgehender Datenverkehr auf Port 443 zu AVD-Dienstendpunkten (verwenden Sie das Service-Tag AzureVirtualDesktop), stabile DNS-Auflösung, Zeitsynchronisation und, falls zutreffend, erfolgreicher Domänenbeitritt.
  • Agenten-Dienste: Der Remote Desktop Agent Loader und der Remote Desktop Agent müssen ausgeführt werden. Der AVD-Agent und der Side-by-Side-Stack aktualisieren sich automatisch, wenn ausgehender Zugriff erlaubt ist.

• Registrierung und Fehlerbehebung

  • Um bestehende VMs einem Hostpool hinzuzufügen, erstellen Sie ein Registrierungstoken (für eine begrenzte Zeit gültig) und installieren/registrieren Sie den AVD-Agenten mit diesem Token.
  • Gängige Schritte zur Fehlerisolierung:
    • Prüfen Sie, ob der Host im Hostpool als „Registered“ und „Available“ angezeigt wird; falls nicht, registrieren Sie ihn mit einem neuen Token erneut.
    • Überprüfen Sie die Ereignisanzeige: Die Protokolle Microsoft-RDInfra-RDAgent, Microsoft-RDInfra-RDAgentBootLoader und RDS/TerminalServices auf Konnektivitäts- oder Authentifizierungsfehler.
    • Validieren Sie DNS: Die Domänenauflösung und die Auflösung der Dienstendpunkte müssen erfolgreich sein; bei Verwendung von Azure AD DS stellen Sie sicher, dass das VNet-DNS auf die verwalteten Domänencontroller verweist.
    • Bestätigen Sie, dass die Windows Firewall oder Netzwerksicherheitsregeln ausgehenden Verkehr auf Port 443 zulassen und dass keine TLS-Interception das Dienstvertrauen bricht.

• Hilfreiche Automatisierungsbeispiele

# 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

Dimensionierung, Auslastung und GPU-fähige Workloads

• Auswahl der VM-Größe und Workload-gesteuerte Dimensionierung

  • Beginnen Sie mit der Charakterisierung der Workloads: Büro/Produktivität, Wissensarbeiter mit Optimierung für Microsoft 365 Apps und Teams, Entwickler/Engineering oder Grafik/3D.
  • CPU: Halten Sie die dauerhafte CPU-Auslastung unter 70–75 % mit kurzen Spitzen unter 85 %. Überwachen Sie Processor(_Total)% Processor Time und System\Processor Queue Length.
  • Arbeitsspeicher: Streben Sie eine zugesicherte Speichernutzung von <80 % an, wobei Memory\Available MBytes über 500 MB pro Host liegen sollte; achten Sie auf Paging (Auslagerung). Der FSLogix-Cache kann das Working Set vergrößern – dimensionieren Sie entsprechend.
  • Speicher: Die Benutzererfahrung hängt von den IOPS und der Latenz des FSLogix-Profils ab. Premium SSD v2, Ultra Disk für temporäre/cache-intensive Szenarien und Azure Files Premium oder Azure NetApp Files für Profile mit hohen IOPS-Anforderungen. Für sehr große Umgebungen oder Profile mit niedrigster Latenz bietet Azure NetApp Files die beste Konsistenz.
  • Anfängliche Basiswerte (Multi-Session):
    • Leichte Produktivitäts-Workloads: 4–8 vCPU, 16–32 GB RAM; Breadth-First für eine gute Reaktionsfähigkeit.
    • Mittlere Wissensarbeiter-Workloads: 8–16 vCPU, 32–64 GB RAM; Depth-First für Kosteneffizienz.
    • Anspruchsvolle Entwicklungs-/Kompilierungs-/Daten-Workloads: 16–32 vCPU, 64–128 GB RAM; erwägen Sie dedizierte Pools.

• GPU-fähige Sitzungshosts

  • Für CAD/GIS/3D/Videobearbeitung und komplexe Visualisierungen verwenden Sie NVads A10 v5 für granulare vGPU-Profile und ein starkes Preis-Leistungs-Verhältnis; ziehen Sie gegebenenfalls die NV v4/v5-Familien in Betracht.
  • Stellen Sie die NVIDIA GPU Driver Extension für Windows auf VMs der N-Serie bereit. Validieren Sie die Hardware-Kodierung: Aktivieren Sie AVC/H.264 und konfigurieren Sie „Hardwarekodierung für Remotedesktop verwenden“ per Richtlinie, wenn dies vorteilhaft ist.
  • Überwachen Sie die GPU mit Leistungsindikatoren (GPU engine utilization, GPU memory) und Azure Monitor-Metriken. Stellen Sie ausreichenden CPU-Headroom sicher; grafikintensive Anwendungen reagieren weiterhin empfindlich auf CPU-Starvation (CPU-Mangel).

• Telemetrie und iterative Feinabstimmung

  • Aktivieren Sie Azure Monitor für AVD Insights und Log Analytics. Verfolgen Sie CPU, Arbeitsspeicher, Latenz der FSLogix-Profile, Anmeldedauer, Verbindungstrennungen und Brokering-Zeiten.
  • Passen Sie den MaxSessionLimit des Host-Pools und den Lastenausgleichsmodus basierend auf beobachteten Konflikten (Contention) an und stimmen Sie anschließend die Schwellenwerte für die automatische Skalierung darauf ab.

Kostenoptimierung: Leistung, Autoskalierung, Reservierungen, Savings Plans und AHB

• Skalierung an Geschäftszeiten ausrichten

  • Verwenden Sie Depth-First-Skalierung plus konservative Kapazitätsschwellenwerte, um Sitzungen zu konsolidieren und das Scale-In zu beschleunigen. Kombinieren Sie dies mit der Aufhebung der Zuordnung außerhalb der Spitzenzeiten und „Start VM on connect“ für späten/seltenen Zugriff.
  • Legen Sie eine kleine, aber von Null verschiedene Mindestanzahl an Hosts fest, um Kaltstart-Stürme zu vermeiden.

• Reservierungen und Savings Plans

  • Reservierungen: 1-jährige oder 3-jährige VM-Reservierungen binden bestimmte SKUs in bestimmten Regionen für die größten Rabatte; ideal für die Basiskapazität, die die meiste Zeit läuft (z. B. die Flotte während der Tagesspitzen).
  • Compute Savings Plans: Bieten flexible Rabatte über VM-Familien und Regionen hinweg; nützlich bei der Mischung von Größen oder für dynamische Umgebungen, in denen die genaue SKU-Vorhersagbarkeit geringer ist.
  • Speicherreservierungen: Reservierte Kapazität für Azure Files kann die Speicherkosten für FSLogix bei entsprechender Skalierung reduzieren.

• Azure Hybrid Benefit (AHB) und Lizenzierung

  • Wenden Sie AHB auf Windows Server und berechtigte Windows-Client-Workloads an, um die Lizenzgebühren für das Betriebssystem der Recheninstanzen zu reduzieren. Stellen Sie die Lizenzberechtigung und Compliance sicher.
  • Bestätigen Sie bei Microsoft 365-Bereitstellungen, dass die Lizenzierung gegebenenfalls Windows Enterprise Multi-Session und Microsoft 365 Apps abdeckt.

• Betriebsskripte und Runbooks

  • Verwenden Sie Azure Automation oder GitHub Actions für:
    • Drain/Enable-Sequenzen für die Flotte vor und nach der Wartung.
    • Pre-Scale-Warm-up-Skripte an Montagen oder nach Feiertagen.
    • Fehlerbehebung (Neustart von Agent-Diensten, Neuregistrierung des Hosts bei verlorenem Heartbeat).
  • Tag-gesteuerte Orchestrierung vereinfacht selektive Operationen (z. B. Tag Environment=Pilot, um vom Scale-In auszuschließen).

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

Praktisches Problemszenario

IKEA verzeichnet wochentags Lastspitzen durch 3D-Planer, Produktingenieure und Call-Center-Mitarbeiter, die Remote-Apps verwenden. Abends und an Wochenenden ist die Nachfrage gering. GPU-gestützte Sitzungen müssen reaktionsschnell bleiben, während die gesamten Computekosten minimiert werden.

1. Hostpools nach Workload segmentieren

   • Erstellen Sie drei gepoolte Hostpools: GPU-CAD (NVads A10 v5), KnowledgeWorker (D/E-Serie) und ContactCenter (D-Serie).
   • Warum: Gleicht VM-Größe und -Dichte mit unterschiedlichen Leistungsprofilen ab; ermöglicht unabhängige Autoskalierung und Wartungsfenster.

2. Einen einzigen Skalierungsplan mit Zeitplänen gemäß den Geschäftszeiten anfügen

   • Definieren Sie Ramp-Up um 07:00 Uhr, Spitzenlast von 09:00–17:00 Uhr, Ramp-Down von 17:00–19:00 Uhr, ansonsten Nebenzeiten; stellen Sie die Zeitzone auf die Region jedes Pools ein.
   • Warum: Garantiert, dass die Kapazität bereitsteht, bevor die Benutzer eintreffen, konsolidiert und fährt nach Feierabend ordnungsgemäß herunter und berücksichtigt regionale Zeiten.

3. Kapazitätsschwellenwerte und minimale Host-Verfügbarkeit pro Pool anpassen

   • GPU-CAD: Breadth-First, Kapazitätsschwellenwert 70 %, mindestens 30 % der Hosts online; KnowledgeWorker: Depth-First, Schwellenwert 65 %, mindestens 10 %; ContactCenter: Depth-First, Schwellenwert 70 %, mindestens 15 %.
   • Warum: GPU-Workloads bevorzugen eine breitere Verteilung für eine bessere Reaktionsfähigkeit; Office-Workloads profitieren von der Konsolidierung zur Kostensenkung; das Call Center benötigt eine stabile Reserve für Schichtwechsel.

4. „Start VM on connect“ für KnowledgeWorker und ContactCenter aktivieren

   • Erteilen Sie der verwalteten Identität des Hostpools VM-Startberechtigungen; halten Sie das Minimum für die Nebenzeiten niedrig.
   • Warum: Reduziert die Kosten für ungenutzte Laufzeit und bewahrt gleichzeitig den Just-in-Time-Zugriff für unerwartete Anmeldungen außerhalb der Geschäftszeiten.

5. Wartungs- und Benachrichtigungs-Workflow implementieren

   • Vor dem Patch Tuesday: 20 % jedes Pools über ein Tag in den Drain-Modus versetzen; Benutzer 30 Minuten vorher benachrichtigen; nach Leerlauf patchen, neu starten, Agent/Heartbeat validieren, dann zur nächsten Charge rotieren.
   • Warum: Ein rollierender Drain-Modus vermeidet Massenabmeldungen, erhält die Servicekontinuität aufrecht und reduziert Helpdesk-Spitzen.

6. Mit Azure Monitor für AVD überwachen und iterieren

   • Verfolgen Sie CPU-, Arbeitsspeicher-, GPU-Auslastung, Anmeldedauer, FSLogix-Latenz; passen Sie MaxSessionLimit und die Schwellenwerte für die Autoskalierung monatlich an.
   • Warum: Datengesteuertes Tuning sichert das SLA und kontrolliert die Ausgaben, während sich die Nutzungsmuster weiterentwickeln.

7. Kostenhebel anwenden

   • Reservieren Sie 3-Jahres-Kapazität für die Basisauslastung während der wöchentlichen Spitzenzeiten in KnowledgeWorker und ContactCenter; verwenden Sie einen Compute Savings Plan für den variablen GPU-Bedarf; wenden Sie Azure Hybrid Benefit an, wo berechtigt.
   • Warum: Reservierungen sichern die größten Einsparungen für eine vorhersagbare Grundlast; Savings Plans sind flexibel bei weniger vorhersagbaren GPU-Spitzen; AHB senkt die Lizenzkosten für das Betriebssystem.

8. Registrierung und Systemzustand härten

   • Pflegen Sie ein ständiges Runbook, um jeden Host, der „NoHeartbeat“ anzeigt, neu zu registrieren und DNS/Zeit zu validieren. Behalten Sie Ausschluss-Tags für Diagnose-Hosts bei.
   • Warum: Eine schnelle, automatisierte Fehlerbehebung begrenzt die Auswirkungen auf die Benutzer und sichert die Kapazität bei unerwarteten Agent-Problemen.

Mit diesem Design erfüllt IKEA die Leistungsziele während des Tages – einschließlich der GPU-Reaktionsfähigkeit – während gleichzeitig die Kapazität außerhalb der Geschäftszeiten aggressiv freigegeben und die Wartung automatisiert wird, was zu einer stabilen Benutzererfahrung und einer messbaren Kostenreduzierung führt.

← FSLogix · Alle Domänen · Anwendungen und Endbenutzererlebnis →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Microsoft durchsuchen →