Azure Virtual Desktop Autoscale – So sparen Sie aktiv Kosten beim Betrieb von cloudbasierten virtuellen Desktops

Flexible Arbeitszeitmodelle, Schichtbetrieb, Urlaubs- oder Brückentage – virtuelle Desktoparbeitsplätze unterliegen permanenten Nutzungsschwankungen, wodurch eine homogene Auslastung faktisch niemals gegeben ist. Dies macht es für Unternehmen schwer, benötigte Ressourcen kosteneffizient zu planen und einzusetzen: Während im eigenen Rechenzentrum die benötigten Hardware-Ressourcen bereits vor der Implementierung penibel genau kalkuliert werden, um möglichst alle Eventualitäten in Sachen Nutzungsintensität abzudecken, besteht in der Cloud zumindest die Freiheit, Ressourcen flexibel zu skalieren. Doch möchte man natürlich auch hier unnötige Kosten, verursacht durch leerlaufende Ressourcen, tunlichst vermeiden.

Der einfachste Grundsatz für cloudbasierte Workloads lautet: Stelle sicher, dass keine kostenpflichtigen Ressourcen beansprucht werden, wenn sie nicht gebraucht werden. Im Falle von virtuellen Maschinen (VMs) bedeutet das, diese zu stoppen und zu deallokieren. Für die Deallokation existieren verschiedene Ansätze – beispielsweise in Form von Skripten oder zeitbasierten Mechanismen. Voraussetzung hierfür sind jedoch entsprechende Intelligenzen seitens der eingesetzten Hyperscaler, was uns zum eigentlichen Thema dieses Beitrags führt. Denn mit Azure Virtual Desktop (AVD) Autoscale ist nun so eine Intelligenz als Public Review seitens des Hyperscalers Microsoft verfügbar.

AVD Autoscale trägt dazu bei, auf intelligente Weise ungenutzte Ressourcen innerhalb virtueller Desktopumgebungen auf Basis von Nutzungsintensitäten und Zeitplänen zu reduzieren. So lassen sich Ressourcen und somit auch Kosten effizient einsparen.

Inhaltsverzeichnis

• Was macht Autoscale eigentlich?
• Erster Schritt: Voraussetzungen schaffen
• Zweiter Schritt: Erstellung eines Scaling Plans
• Dritter Schritt: Zuweisung eines Scaling Plans
• Häufig gestellte Fragen 
• Zusammenfassung 

Was macht Autoscale eigentlich?

Anhand der Nutzerauslastung und der verfügbaren Maschinen kann in definierten Zeitfenstern (z.B. eine typische Arbeitswoche mit Kernarbeitszeiten von 9-17 Uhr) die Anzahl der notwendigen VMs dynamisch angepasst werden. Das bedeutet: Sofern man weiß, wie viele Benutzer auf einer Maschine arbeiten, kann die Anzahl der eingeschalteten VMs so reguliert werden, dass sich keine kostenverursachenden Ressourcen im Leerlauf befinden und gleichzeitig die User Experience gewahrt bleibt. Selbstverständlich lassen sich verschiedene Autoscale-Varianten auch miteinander kombinieren.

Rahmenbedingungen

• Autoscale kann nur auf bestehenden AVD-Hostpools des Typs „Pooled Desktops“ verwendet werden. Für Hostpools vom Typ „Personal“ ist die Funktion „Start at connect“ die Richtige.
• Ein Scaling Plan muss immer in der Region erstellt werden, in der sich auch die Hostpools befinden. Nur so kann er richtig zugewiesen werden. Dabei kann der Hostpool aber durchaus einen anderen Standort haben wie die eigentlichen Compute-Instanzen. Hinweis: Ein Scaling Plan kann aktuell nicht auf Hostpools anderer Regionen angewendet werden. Sind Hostpools in unterschiedlichen Regionen im Einsatz, wird pro Region ein Scaling Plan benötigt.
• Alle Hostpools, auf die die Autoscale-Funktion Anwendung finden soll, müssen den Parameter MaxSessionLimitkonfiguriert haben. Damit Autoscale optimal genutzt wird, muss dieser Parameter an die Nutzungscharakteristik der Umgebung angepasst sein.
• Die AVD-App muss über entsprechende Berechtigungen verfügen, um Compute-Instanten starten und stoppen sowie Benutzer abmelden zu können. Mehr dazu im nachfolgenden Abschnitt.

Erster Schritt: Voraussetzungen schaffen

Die Erfüllung bestimmter Voraussetzungen kann eine kleine Einstiegshürde darstellen, ist aber relativ einfach zu bewerkstelligen.

So muss zunächst eine angepasste RBAC-Rolle innerhalb der Azure Subscription erstellt werden, welche den Zugriff auf gewisse Funktionen innerhalb des AVD-Deployments erhält. Dies kann wie folgt umgesetzt werden:

1. Rufen Sie im Azure Portal den Punkt „Subscriptions“ auf.
2. Wählen Sie die entsprechende Subscription aus
3. Gehen Sie im linken Bereich auf „Access control (IAM)“ und erstellen Sie via „+Add“ -> „Add custom role“ eine neue benutzerdefinierte Rolle. Hinweis: Der Name kann beliebig gewählt werden; es bietet sich bspw. der Name „AVD Autoscale“ an.

4. Tragen Sie im Reiter „Permissions“ folgende Berechtigungen ein und speichern Sie die Custom Role im Anschluss.

Microsoft.Insights/eventtypes/values/read
Microsoft.Compute/virtualMachines/deallocate/action
Microsoft.Compute/virtualMachines/restart/action
Microsoft.Compute/virtualMachines/powerOff/action
Microsoft.Compute/virtualMachines/start/action
Microsoft.Compute/virtualMachines/read
Microsoft.DesktopVirtualization/hostpools/read
Microsoft.DesktopVirtualization/hostpools/write
Microsoft.DesktopVirtualization/hostpools/sessionhosts/read
Microsoft.DesktopVirtualization/hostpools/sessionhosts/write
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/delete
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/sendMessage/action

5. Weisen Sie nun die Custom Role über „+ Add“ -> „Add role assignment” auf die Azure-eigene Applikation „Windows Virtual Desktop” zu.

6. Abschließend wird die Zuweisung der Rolle zur Applikation mittels Bestätigung über „Review + assign“ umgesetzt.

Zweiter Schritt: Erstellung eines Scaling Plans

Im Bereich „Azure Virtual Desktop“ -> „Scaling Plans“ werden alle Scaling Pläne konfiguriert und im Anschluss einem oder mehreren Hostpools zugewiesen.

Grundsätzlich ist die Erstellung eines Scaling Plans unkompliziert, jedoch existieren viele individuell anpassbare Parameter, deren Bedeutung nicht immer ganz klar und nachvollzierbar ist. Daher wollen wir nachfolgend auf die einzelnen Parameter eingehen, um damit die Konfiguration eines passgenauen Scaling Plans zu erleichtern.

Doch beginnen wir zunächst mit der Erstellung eines neuen Scaling Plans über „+ Create“:

Grundparameter

Zuerst konfigurieren Sie die Grundparameter eines Scaling Plans. Dazu gehören die Resource Group, der Name des Scaling Plans und der Standort, der dem Standort des Hostpools entsprechen muss. Optional kann ein erweiterter, sprechender Name und eine Beschreibung angegeben werden.

Im Feld Exclusion tag können Tags eingegeben werden, die bspw. den Ausschluss einer oder mehrerer Compute-Instanzen aus der Anwendung eines Scaling Plans ermöglichen. Die Angabe ist optional.

Schedule

Jeder Scaling Plan muss über mindestens einen Zeitplan verfügen. Kommt mehr als ein Zeitplan zum Einsatz, müssen sich die Zeitpläne in den zugewiesenen Tagen unterscheiden. Best-Practice hierfür ist, sowohl einen Zeitplan für die Arbeitstage von montags bis freitags zu erstellen als auch einen Zeitplan für das Wochenende.

Ramp-up

Ramp-up (deutsch: Anlaufzeit) gibt die Zeit an, ab wann und unter welcher Berechnungsgrundlage Autoscale beginnt, Maschinen aktiv hochzufahren.

Hinsichtlich der Berechnungsgrundlagen ist der Wert Capacity Threshold (%) von enormer Wichtigkeit. Denn dieser Kapazitätsschwellwert bezieht sich auf die Berechnung der Gesamtkapazität an möglichen Benutzersitzungen auf den aktiven Compute-Instanzen – mathematisch ausgedrückt: Anzahl Benutzersitzungen pro Host x Anzahl eingeschalteter Hosts im jeweiligen Pool. Hierbei wird nun direkt ersichtlich, warum der oben angegebene Wert MaxSessionLimit so relevant ist. Denn ohne eine definierte Angabe, wie viele Sitzungen pro Sitzungshost maximal innerhalb eines Hostpools erlaubt sind, kann Autoscale die Schwellwerte nicht korrekt berechnen. Man sollte also beachten, dass die Angabe des Parameters MaxSessionLimit für die Funktionalität von Autoscale zwingend erforderlich ist.

Berechnung der Werte anhand eines konkreten Beispiels:

Nimmt man zur Vereinfachung an, dass ein Hostpool aus 10 Hosts mit maximal 10 Benutzersitzungen/Host (MaxSessionLimit = 10) besteht. Die maximale Kapazität dieses Hostpools beträgt somit 100 Nutzer, sofern alle Compute-Instanzen eingeschaltet sind.

Über den Parameter “Minimum percentage of hosts (%)” wird nun festgelegt, wie viele Compute-Instanzen definitv gestartet werden sollen. Das macht insofern Sinn, da vermutlich sowohl in der “Ramp-up”-Phase (Anlaufzeit) als auch in der “Ramp-down”-Phase (Abklingphase) eine gewisse Minimalanzahl an betriebsbereiten Compute-Instanzen vorgehalten werden soll. Zudem ist die Anzahl der aktiv eingeschalteten Compute-Instanzen relevant für die aktuelle Kapazität der Benutzersitzungen (gemessen in %).

Bezugnehmend auf das oben genannte Beispiel würde eine Konfiguration mit „Capacity Threshold (%) = 60“ und „Minimum percentage of hosts (%) = 20“ also Folgendes bedeuten:

• • Ab 8.00 Uhr mitteleuropäischer Zeit sollen 2 Compute-Instanzen eingeschaltet sein.
  • Eine Kapazität von 100 Prozent bedeutet: 2 Compute-Instanzen x 10 Benutzer pro Instanz = 20 Benutzer, die die Möglichkeit haben, sich anzumelden. Folglich würde ein Capacity Threshold von 60 Prozent bedeuten, dass eine weitere Instanz gestartet wird, sobald sich der 13. Benutzer in der Umgebung angemeldet hat (20 x 0,6 = 12).

Gehen wir nun noch einen Schritt weiter:

• • Nun bedeutet eine 100%-ige Kapazität bei 3 aktiven Compute-Instanzen: 3 Compute Instanzen x 10 Benutzer pro Instanz = 30 Benutzer.
  • Auch hierauf wird erneut der Kapazitätsschwellwert von 60 Prozent angewendet, wodurch eine vierte Instanz mit Anmeldung des 19. Benutzers startet.

Nicht unwichtig im Kontext der verschiedenen Phasen ist auch der Load Balancing Algorithm (Lastverteilungs-Algorithmus). Breadth-First bedeutet, dass alle Benutzer gleichmäßig und umlaufend über alle zur Verfügung stehenden Compute-Instanzen verteilt werden, wohingegen mit Depth-First definiert wird, dass Benutzer der Compute-Instanz mit der höchsten Benutzeranzahl (< MaxSessionLimit-Wert) zugewiesen werden.

Die Möglichkeit, zwischen Breite und Tiefe zu wechseln, macht gerade im Kontext der verschiedenen Phasen Sinn. So ist es in der Ramp-Up-Phase wichtig, den Benutzern eine zügige und ungehinderte Anmeldung zu ermöglichen. Dies gelingt am besten, indem die Lastverteilung auf Breadth-first gestellt wird, denn so werden die rechenintensiven Prozesse gleichmäßiger auf alle Compute-Instanzen verteilt, was wiederum zu einer hohen Nutzererfahrung, während der Anmeldephase führt.

Peak hours

Die Konfiguration der Peak hours (deutsch: Kernarbeitszeit) ist simpel, da hier lediglich die Lastverteilung umgestellt werden kann. Hier macht ein Wechsel auf Depth-first Sinn, wenn die meisten Nutzeranmeldungen bereits erfolgt sind und die Compute- und Storage-Kapazitäten nicht mehr so beansprucht sind. Folglich wird dann ab der festgelegten Uhrzeit jede Instanz mit Sitzungen befüllt, bis der MaxSessionLimit-Wert und später der in der Ramp-up-Phase angegebene Capacity Threshold erreicht wird. Durch diese Lastverteilung kann also sichergestellt werden, dass während der Kernarbeitszeit stets die geringste Zahl an eingeschalteten Compute-Instanzen genutzt wird, was wiederum sehr kosteneffizient ist.

Ramp-down
Ramp-down steht übersetzt für Abklingphase und beschreibt die Zeit, in der die Anwender aufhören zu arbeiten. Hier ist es ebenso möglich, eine Uhrzeit für eine Lastverteilung zu definieren. Empfehlenswert ist hier die Angabe „Depth-first“, da es das Ziel ist, die geringste Anzahl an aktiven Compute-Instanzen bereitzustellen.

Weiterhin ist es sinnvoll, dem Parameter Minimum Percentage of Hosts (%) einen geringen Wert zuzuweisen und dem Capacity Threshold (%) einen höheren. Dies bewirkt, dass in der Abklingphase nur wenige Hosts mit einer hohen Anzahl an Benutzersitzungen belegt werden. Hintergrund ist, dass wir es in der Ramp-down-Phase oft mit Anwender:innen zu tun haben, die nicht abgemeldet sind, sondern lediglich ihre Sitzung getrennt haben.

Um diesem Verhalten einen durchaus sanften Riegel vorzuschieben, bieten sich beispielsweise die zusätzlichen Parameter „Force logoff users“ oder „Delay time before logging out users and shutting down VM‘s“. Doch Vorsicht: Diese Einstellung sollte erst nach reiflicher Überlegung und Tests getätigt werden, da man sonst Gefahr läuft, die User durch erzwungene Abmeldungen zu verärgern.

Off-peak hours
Off-peak hours beschreiben die Zeit, in der in der Regel mit der geringsten Anzahl an Anwender:innen gerechnet werden kann. Ziel ist es natürlich, für diese wenigen Personen so wenige Compute-Instanzen wie möglich bereitzustellen und gleichzeitig eine hohe Benutzer-Packungsdichte zu erreichen. Somit ist auch hier der Lastverteilungsalgorithmus „Depth-First“ weiterhin sinnvoll.

Abschluss
Mit Klick auf „Review + create“ wird der erste Zeitplan im Scaling Plan angelegt. Optional können jetzt weitere Zeitpläne innerhalb des Scaling Plans erstellt werden, um bspw. eine andere Konfiguration für das Wochenende festzulegen. Sind alle benötigten Zeitpläne eingerichtet, schließen Sie das Anlegen des Scaling Plans mit erneutem Klick auf „Review + create“ ab.

Dritter Schritt: Zuweisung eines Scaling Plans

Zum einen kann ein Scaling Plan über Azure Virtual Desktop -> Scaling Plan -> Overview -> Host pool assignments direkt einem Hostpool zugewiesen werden, zum anderen kann dies auch aus der Konfiguration des jeweiligen Hostpools erfolgen. Dabei ist zu beachten, dass jedem Hostpool nur ein Scaling Plan zugewiesen kann und der entsprechende Scaling Plan sofort nach seiner Zuweisung Anwendung findet.

Häufig gestellte Fragen

Viele Kunden setzen die Autoscale-Funktion bereits aktiv ein und ihr Feedback ist durchweg positiv. Dennoch treten immer wieder einige Fragen im Zusammenhang mit Autoscale auf, die nachfolgend aufgeführt werden.

Kann ich unter Off-peak hours alle Maschinen ausschalten?
Nein, denn in keiner Phase kann der Kapazitätsschwellwert auf 0 Prozent gestellt werden. Die minimale Anzahl an Compute-Instanzen ist daher auf mindestens eine Instanz limitiert.

Kann Autoscale neue Compute-Instanzen erstellen oder bestehende Instanzen löschen?
Im aktuellen Release von Autoscale gibt es diese Funktion nicht. Es besteht aber die Möglichkeit, dass Microsoft in einem der nächsten Releases diese Funktionalität aufnimmt. Wer dieses Feature befürwortet, kann seine Meinung im AVD-Forum von Microsoft äußern.

Können spezielle Zeitpläne für Feiertage erstellt werden?
Die Idee dahinter ist, Zeitpläne zu erstellen, die bestehende Tages- oder Wochenzeitpläne bei Bedarf überschreiben können. Dies ist allerdings aktuell noch nicht möglich.

Mit welchen Kosten muss ich für Autoscale rechnen?
Autoscale ist wie die gesamte AVD-Infrastruktur Bestandteil der entsprechenden Nutzungslizenzen und führt somit zu keinen zusätzlichen Kosten.

Kann ich Autoscale auch für Personal Desktops einsetzen?
Nein. Stattdessen ermöglicht die Funktion „Start VM on connect“ diesem Desktop-Typ, sich erst nach Verbindungsanforderung einzuschalten. Diese stellt in Kombination mit dem Feature „Auto shutdown“ eine ebenbürtige Alternative zu Autoscale dar, um Kosten im Betrieb von Personal Desktops innerhalb von AVD zu sparen.

Ist Autoscale auf für Pooled VDI-Umgebungen einsetzbar?
Ja. Autoscale kann sowohl für Single-Session (Windows 10/11) als auch für Multi-Session Hosts (Terminal Server basierend auf einem Windows Server als auch Windows 10/11 Enterprise for Virtual Desktop OS) genutzt werden. Hier macht wieder einmal der Parameter MaxSessionLimit den Unterschied. Dieser wird logischerweise bei Single-Session VDI-Instanzen auf den Wert 1 gesetzt. Dadurch kann Autoscale die Kapazitäten in einer pooled VDI-Umgebung berechnen.

Zusammenfassung

Autoscale bietet Ihnen eine einfache und benutzerfreundliche Möglichkeit, die Betriebskosten einer cloudbasierten Desktopumgebung zu optimieren. Um die richtigen Schwellwerte zu finden, werden gewisse Rahmenparameter für den kosteneffektiven Einsatz von Autoscale zwar an Analyse- und Monitoringtools übermittelt, es ist dennoch ein Meilenstein verglichen mit den vorherigen Möglichkeiten, welche ausschließlich über Skripte realisiert wurden und keinerlei Komfort in Form von Konfigurationsoberfläche zuließen.