Autoscale: vier Phasen, zwei stille Überschreibungen

Der Lastverteilungsalgorithmus, den eine Skalierungsphase setzt, überschreibt den des Host Pools. Wer am Pool DepthFirst konfiguriert hat und einen Plan mit BreadthFirst in der Ramp-up-Phase zuweist, betreibt seinen Pool morgens mit Breadth-first — ohne dass die Pool-Einstellung sich ändert oder irgendwo widersprochen wird. Die zweite stille Übernahme betrifft die Kapazitätsschwelle: Sie lässt sich nur in Ramp-up und Ramp-down setzen, Hauptlast- und Nachtphase erben den Wert. Dieses Modul behandelt die vier Phasen, die Rechnung hinter der Schwelle, warum der Mindestanteil aufgerundet wird, wie die erzwungene Abmeldung beim Absenken abläuft — und warum ein für Wartung getaggter Host weiterhin in den Mindestanteil zählt, ohne ihn erfüllen zu können.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-13

Kapazität muss vor der Welle da sein

Ein Skalierungsmechanismus, der auf Last reagiert, ist um die Zeit zu spät, die das Hochfahren eines Hosts braucht. Um 08:00 melden sich vierhundert Menschen an; ein Host, der um 08:05 gestartet wird, steht um 08:23 bereit. Für die ersten zwanzig Minuten war er nicht da.

Deshalb arbeitet Autoscale in Azure Virtual Desktop nicht rein reaktiv, sondern nach einem Zeitplan mit vier Phasen, innerhalb derer Schwellwerte greifen. Dieses Modul behandelt diese Phasen, die Rechnung hinter der Kapazitätsschwelle — und zwei Stellen, an denen ein Skalierungsplan Einstellungen des Host Pools überschreibt, ohne dass es irgendwo auffällt.

LernzielDu kannst einen Skalierungsplan aus Lastkurve, Vorlaufzeit und Ausfallreserve ableiten, die Kapazitätsschwelle für einen konkreten Pool ausrechnen und benennen, welche Einstellungen ein Skalierungsplan still übersteuert.

Vier Phasen, nicht eine Regel

Ramp-up — Hosts für den Tag vorbereiten→Peak — Hauptlast→Ramp-down — Absenken→Off-peak — Nachtbetrieb

Jede Phase hat eigene Parameter

Ein Zeitplan wiederholt sich an ausgewählten Wochentagen. Jede Phase beginnt zu einer festen Uhrzeit in der Zeitzone des Plans; der Beginn einer Phase ist zugleich das Ende der vorigen. Nicht alle Phasen nehmen dieselben Parameter entgegen — und genau das ist die erste Quelle für Missverständnisse.

Ramp-up: Startzeit, Lastverteilungsalgorithmus, Mindestanteil der Hosts, Kapazitätsschwelle.
Peak: Startzeit und Lastverteilungsalgorithmus. Die Kapazitätsschwelle ist hier nicht einstellbar.
Ramp-down: Startzeit, Algorithmus, Mindestanteil, Kapazitätsschwelle, erzwungene Abmeldung samt Wartezeit und Nachricht.
Off-peak: Startzeit und Algorithmus. Kapazitätsschwelle ebenfalls nicht einstellbar.

Die erste stille ÜbernahmeDie Kapazitätsschwelle lässt sich nur in Ramp-up und Ramp-down setzen. Für die Hauptlastphase wird der Wert aus Ramp-up übernommen, für die Nachtphase der aus Ramp-down. Wer die Schwelle für die Hauptlast anders haben will als für das Hochfahren, kann das nicht — und wer den Ramp-up-Wert später ändert, ändert unbemerkt auch den Wert für die Hauptlast.

Sind nicht alle Wochentage im Zeitplan ausgewählt, gelten für die fehlenden Tage die zuletzt gültigen Off-peak-Parameter bis zur nächsten Ramp-up-Phase. Ein Plan von Montag bis Freitag trägt also mit den Freitag-Nachtwerten durch das gesamte Wochenende.

Die Kapazitätsschwelle ausrechnen

Die Kapazitätsschwelle ist der Prozentsatz der verfügbaren Host-Pool-Kapazität, dessen Überschreiten eine Skalierung auslöst. Verfügbare Kapazität heißt: eingeschaltete Hosts multipliziert mit der Sitzungsgrenze.

Zwei Hosts, Schwelle 75 Prozent

Szenario

Ein gepoolter Pool hat MaxSessionLimit auf 20 gesetzt. Zwei Session Hosts sind eingeschaltet. Die Kapazitätsschwelle steht auf 75 Prozent. Gefragt ist, wann ein dritter Host startet und was danach gilt.

Anforderungen

Die Rechnung soll die verfügbare Kapazität und den Auslösepunkt benennen.
Das Ergebnis dient der Frage, wie oft skaliert wird.

Schritte

Verfügbare Kapazität: zwei Hosts mal 20 Sitzungen ergibt 40 Sitzungen.
75 Prozent davon sind 30. Überschreitet die Belegung 30 Sitzungen, startet Autoscale einen dritten Host.
Mit drei Hosts steigt die verfügbare Kapazität auf 60 Sitzungen.
Der nächste Auslösepunkt liegt damit bei 45 Sitzungen — die Abstände zwischen Skalierungsschritten wachsen mit jedem Host.

Merksatz: Die Schwelle ist ein Verhältnis, kein fester Wert. Je mehr Hosts laufen, desto größer der absolute Puffer, der vor dem nächsten Start liegt — und desto träger reagiert der Pool auf einen plötzlichen Andrang.

Wer die Schwelle senkt, kauft ReserveEine niedrige Kapazitätsschwelle startet früher zusätzliche Hosts und hält damit mehr Luft vor. Sie kostet entsprechend mehr laufende Maschinen. Eine hohe Schwelle spart Geld und schiebt den Start näher an den Moment, in dem die Kapazität tatsächlich gebraucht wird — mit der Vorlaufzeit des Hochfahrens als Risiko.

Der Mindestanteil und seine Aufrundung

Der Mindestanteil der Hosts legt fest, welcher Prozentsatz der Session Hosts in einer Phase auf jeden Fall eingeschaltet bleibt. Autoscale schaltet diese Hosts nicht ab, unabhängig davon, wie leer sie sind.

Aufgerundet, nicht gerundetErgibt der Prozentsatz keine ganze Zahl, wird aufgerundet. In einem Pool aus sieben Hosts bedeutet ein Mindestanteil von 10 Prozent, dass ein Host durchgehend läuft — 0,7 wird zu 1. Das klingt nach einer Kleinigkeit und entscheidet in kleinen Pools darüber, ob überhaupt jemand ohne Wartezeit hereinkommt.

Der Mindestanteil ist die eigentliche Antwort auf die Vorlaufzeit: Er hält die Hosts bereit, die eine Anmeldewelle ohne Startverzögerung auffangen. Wer den Morgenpeak verlässlich tragen will, erhöht in der Ramp-up-Phase den Mindestanteil — und verlässt sich nicht darauf, dass die Kapazitätsschwelle rechtzeitig auslöst.

Kurzcheck

Der Morgenpeak beginnt um 08:00. Neue Hosts brauchen 18 Minuten bis zur Betriebsbereitschaft, die Schwelle löst erst um 08:05 aus. Welche Anpassung adressiert das Erlebnis unmittelbar?

Die Ramp-up-Phase früher beginnen lassen und den Mindestanteil dort anheben.
Die Kapazitätsschwelle senken, damit früher skaliert wird.
Die Sitzungsgrenze erhöhen, damit mehr Nutzer auf die laufenden Hosts passen.
Auf Depth-first umstellen, damit weniger Hosts gebraucht werden.

Treffer. Richtig. Kapazität, die zur Welle bereitstehen soll, muss vor der Welle eingeschaltet werden. Der Mindestanteil hält sie unabhängig von der Auslastung bereit.

Die zweite stille Überschreibung

Jede der vier Phasen nimmt einen eigenen Lastverteilungsalgorithmus entgegen. Das ist nützlich — und es hat eine Folge, die in der Dokumentation in einem Nebensatz steht.

Der Plan gewinnt gegen den PoolDie in der Phase gewählte Lastverteilung überschreibt die Einstellung des Host Pools. Wer am Pool DepthFirst konfiguriert hat und einen Skalierungsplan mit BreadthFirst in der Ramp-up-Phase zuweist, betreibt seinen Pool morgens mit Breadth-first — ohne dass die Pool-Einstellung sich ändert oder irgendwo widersprochen wird. Wer den Algorithmus eines Pools prüft, muss deshalb beide Orte ansehen.

Sinnvoll ist die Trennung trotzdem: Für die Ramp-up-Phase empfiehlt die Dokumentation ausdrücklich Breadth-first, weil es Nutzer über die vorhandenen Hosts verteilt und damit die Zugriffszeiten kurz hält. Für die Hauptlast- und Nachtphase ist beides sinnvoll — Depth-first packt dichter und erlaubt, später mehr Maschinen abzuschalten.

Verfügbare Host-Pool-Kapazität — Die Zahl der Sitzungen, die eingeschaltete Hosts gemeinsam aufnehmen können — eingeschaltete Hosts mal Sitzungsgrenze. Sie ändert sich mit jedem Host, den Autoscale ein- oder ausschaltet, und ist die Bezugsgröße für die Kapazitätsschwelle.

Absenken: die unangenehme Phase

Hochfahren ist einfach — es kostet nur Geld. Absenken berührt Menschen, die noch arbeiten. Die Ramp-down-Phase ist deshalb die einzige mit einer Entscheidung über erzwungene Abmeldung.

Ist die erzwungene Abmeldung aktiviert, läuft der Vorgang in einer festen Reihenfolge: Autoscale wählt den Host mit der niedrigsten Zahl von Sitzungen — aktive und getrennte zusammengezählt —, setzt ihn in den Drain-Modus, schickt den betroffenen Sitzungen eine Benachrichtigung, wartet die eingestellte Zeit ab, meldet die verbliebenen Nutzer ab und hebt die Maschine dann auf.

Ohne erzwungene Abmeldung wird stattdessen gewählt, wann ein Host abgeschaltet werden darf: wenn er keine aktiven Sitzungen mehr hat, oder wenn er weder aktive noch getrennte Sitzungen mehr hat.
Die zweite Variante ist die schonendste — und die, bei der getrennte Sitzungen einen Host beliebig lange am Leben halten.
Eine Zeitlimitrichtlinie für getrennte Sitzungen wirkt in allen Phasen und senkt die belegte Kapazität, ohne jemanden aus aktiver Arbeit zu reißen.

Die Grenze, die immer giltOb erzwungen wird oder nicht: Kapazitätsschwelle und Mindestanteil bleiben in Kraft. Autoscale schaltet einen Host nur ab, wenn alle vorhandenen Sitzungen — aktive und getrennte — auf weniger Hosts zusammengelegt werden können, ohne die Kapazitätsschwelle zu überschreiten. Eine Absenkung, die nicht stattfindet, ist deshalb oft kein Fehler, sondern die Schwelle, die ihre Arbeit tut.

Hosts, die nicht mitspielen sollen

Für Wartung braucht man Hosts, die Autoscale in Ruhe lässt. Dafür gibt es den Ausschluss-Tag: Ein im Skalierungsplan benannter Tagname, etwa excludeFromScaling, den man auf einzelne Session Hosts setzt.

Trägt ein Host diesen Tag, wird er von Autoscale weder gestartet noch gestoppt — und, besonders wichtig, sein Drain-Modus wird nicht verändert. Ohne den Tag kann eine Skalierungsaktion den Drain-Modus während einer Wartung überschreiben und Nutzer auf einen Host lassen, den gerade jemand leerlaufen lässt.

Die Falle im KleingedrucktenGetaggte Session Hosts zählen laut Dokumentation weiterhin in die Berechnung des Mindestanteils. Wer in einem Pool aus zehn Hosts drei für Wartung taggt und einen Mindestanteil von 30 Prozent gesetzt hat, bekommt rechnerisch drei Pflicht-Hosts — die drei getaggten können diese Rolle aber nicht ausfüllen. Der wirksame Mindestbestand ist damit kleiner als geplant, genau während einer Wartung.

Zwei weitere Hinweise aus der Dokumentation: In den Ausschluss-Tags gehören keine sensiblen Angaben — keine Benutzernamen, keine personenbezogenen Daten. Und für Pools, deren Hosts in der Ramp-up-Phase bewusst nicht gestartet werden, wird Start VM on Connect ausdrücklich empfohlen, damit eine Anmeldung überhaupt eine Maschine vorfindet.

Die Reserve, die kein Plan ersetzt

Ein Skalierungsplan optimiert Kosten gegen Erlebnis im Normalbetrieb. Er ersetzt keine Ausfallreserve. Die beiden Fragen sind getrennt zu beantworten, und sie werden regelmäßig vermischt.

Fünf Hosts bei 75 Prozent

Szenario

Ein Pool erfüllt seine Tageslast mit fünf Hosts bei jeweils 75 Prozent Prozessorauslastung. Die vereinbarte Verfügbarkeit verlangt Fortbetrieb nach dem Ausfall eines Hosts.

Anforderungen

Die Bewertung soll die Zusage prüfen, nicht die Auslastung schönreden.
Das Ergebnis soll benennen, was fehlt.

Schritte

Fünf Hosts tragen die Last bei 75 Prozent — die Gesamtlast entspricht also 3,75 Hosts bei voller Auslastung.
Fällt ein Host aus, verteilt sich dieselbe Last auf vier Hosts: rechnerisch rund 94 Prozent je Host.
Das ist kein Fortbetrieb, sondern ein Betrieb am Anschlag — mit spürbarer Verschlechterung für alle und ohne Luft für den Anmeldeansturm der verdrängten Nutzer.
Der Plan erfüllt die Zusage nicht. Es fehlt mindestens ein Host, der im Normalbetrieb nicht gebraucht wird.

Merksatz: Eine Ausfallreserve ist per Definition Kapazität, die im Normalbetrieb ungenutzt ist. Wer sie über den Mindestanteil einer Skalierungsphase abbildet, muss sie dort auch bezahlen — ein Skalierungsplan, der auf den Bedarf optimiert, entfernt sie sonst zuverlässig.

Wo Autoscale mit anderem kollidiert

Hosterneuerung: Autoscale gehört vor einer Session-Host-Update-Erneuerung deaktiviert und bleibt es bis zum Abschluss — ein aktiver Skalierungsplan kann die Erneuerung mit einem Laufzeitfehler scheitern lassen.
Wartung einzelner Hosts: Ohne Ausschluss-Tag kann eine Skalierungsaktion den Drain-Modus zurücksetzen.
Pool-Einstellungen: Der Lastverteilungsalgorithmus der Phase übersteuert den des Pools.
Getrennte Sitzungen: Sie zählen in die Kapazität und verhindern Abschaltungen — eine Zeitlimitrichtlinie ist Teil der Kapazitätsstrategie, nicht der Kosmetik.
Der Mindestanteil: Getaggte Hosts zählen in seine Berechnung, können ihn aber nicht erfüllen. Während einer Wartung sinkt der wirksame Mindestbestand deshalb unter den geplanten Wert.

Das MusterAlle vier Konflikte entstehen daraus, dass zwei Mechanismen denselben Hostbestand anfassen. Die Regel dahinter ist immer dieselbe: Für jeden Zeitraum muss eindeutig sein, wer die Hosts führt. Wo das nicht geklärt ist, gewinnt der, der zuletzt zugegriffen hat — und das Ergebnis ist nicht vorhersagbar. Praktisch heißt das, dass jede Wartung am Hostbestand mit einer Frage beginnt: Ist Autoscale für diesen Zeitraum aus dem Weg, per Deaktivierung oder per Ausschluss-Tag? Wird sie nicht gestellt, fällt die Antwort mitten im Vorgang auf.

Der Plan als Objekt

Ein Skalierungsplan ist eine eigene Azure-Ressource mit Zeitzone, Host-Pool-Typ und Zeitplänen. Für gepoolte Pools entsteht ein Zeitplan über New-AzWvdScalingPlanPooledSchedule. Die Parameternamen lohnen einen Blick, weil sie die Struktur des Modells wörtlich abbilden.

RampUpStartTimeHour / -Minute: Beginn der Ramp-up-Phase — zugleich Ende der Nachtphase.
RampUpLoadBalancingAlgorithm: Algorithmus dieser Phase. Übersteuert die Pool-Einstellung.
RampUpMinimumHostsPct: Mindestanteil eingeschalteter Hosts in dieser Phase.
RampUpCapacityThresholdPct: Kapazitätsschwelle — gilt auch für die Hauptlastphase.
RampDownForceLogoffUser: Erzwungene Abmeldung beim Absenken, $true oder $false.
RampDownWaitTimeMinute: Wartezeit zwischen Benachrichtigung und Abmeldung.
RampDownNotificationMessage: Der Text, den betroffene Nutzer zu sehen bekommen.
RampDownStopHostsWhen: Wann ein Host abgeschaltet werden darf, etwa ZeroSessions.

Ein Feld, das oft leer bleibtRampDownNotificationMessage ist der einzige Text dieses Modells, den ein Mensch zu lesen bekommt — und zwar in dem Moment, in dem seine Arbeit gleich beendet wird. Ein Standardsatz wie eine bloße Aufforderung zum Abmelden lässt offen, wie viel Zeit bleibt und warum das passiert. Die Wartezeit steht daneben im Plan; sie gehört in die Nachricht.

Persönliche Pools skalieren anders

Autoscale gibt es auch für persönliche Host Pools, nur bedeutet es dort etwas anderes. Weil jede Maschine einem Menschen gehört, geht es nicht um Verteilung, sondern um An- und Abschalten zur richtigen Zeit.

Gestartet wird nach Zeitplan oder über Start VM on Connect, wenn sich jemand verbindet.
Abgeschaltet oder in den Ruhezustand versetzt wird anhand des Sitzungszustands — also danach, ob der Nutzer sich abgemeldet oder nur getrennt hat.
Statt eines Mindestanteils der Hosts gibt es einen Mindestanteil aktiver Hosts in Verbindung mit einer Mindestgröße des Pools: Bei 10 Prozent und einer Mindestgröße von 10 bleibt eine Maschine dauerhaft verfügbar.
Der eigene Zeitplan entsteht über New-AzWvdScalingPlanPersonalSchedule.

Warum das ein anderes Problem istIn einem gepoolten Pool ist die Frage, wie viele Maschinen für eine schwankende Zahl von Menschen bereitstehen müssen. In einem persönlichen Pool ist die Zahl fest — eine Maschine je Person — und die Frage lautet nur, wann sie laufen muss. Kosten entstehen dort nicht durch Überdimensionierung, sondern durch Laufzeit, die niemand nutzt.

Einen Plan aus Messwerten ableiten

Lastkurve über mehrere Wochen erfassen→Vorlaufzeit eines Hoststarts messen→Ausfallreserve als Zusage festlegen→Phasengrenzen an die Kurve legen→Mindestanteil und Schwelle daraus ableiten

Messen, dann planen

Die Reihenfolge ist nicht beliebig. Wer mit den Phasenzeiten beginnt, legt sie nach dem Arbeitszeitmodell fest statt nach der tatsächlichen Kurve — und die beiden weichen fast immer voneinander ab, weil Menschen sich nicht gleichzeitig anmelden und Sitzungen über den Feierabend hinaus offen bleiben.

Die Lastkurve wird in Sitzungen gemessen, nicht in Anwesenheit — getrennte Sitzungen zählen mit, weil sie Kapazität binden.
Die Vorlaufzeit ist die Spanne vom Startbefehl bis zur ersten erfolgreichen Anmeldung, nicht bis zur laufenden Maschine. Profilanbindung und Agentstart gehören dazu.
Die Ausfallreserve ist eine Zusage an das Geschäft und keine Kennzahl der Plattform. Sie wird verhandelt, dann abgebildet — nicht umgekehrt.
Ein Plan gehört nachgezogen, wenn sich Arbeitszeiten, Anwendungen oder die Zahl der Nutzer ändern. Ohne Termin dafür veraltet er lautlos.

Was ein guter Plan kostetEin Skalierungsplan senkt die Rechnung, indem er nachts Maschinen abschaltet — und er verschiebt dafür Risiko in die Ränder des Tages. Wer zu knapp plant, bezahlt es mit Wartezeiten am Morgen und abgebrochener Arbeit am Abend. Wer zu großzügig plant, hat einen Plan, der praktisch nichts spart. Die Mitte lässt sich nicht ausrechnen, nur messen und nachziehen — und sie ändert sich, sobald sich Arbeitszeiten oder Anwendungen ändern.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität5 Primärquellen · zuletzt geprüft: 2026-09-13