Intelligentes Cost Management mit Azure Virtual Desktop
Azure Virtual Desktop bietet Vorteile wie Flexibilität, hohe Verfügbarkeit und einen geringen Verwaltungsaufwand für Administratoren. Allerdings können die Kosten pro Benutzer auch höher sein. Es gibt zwei verschiedene Szenarien für AVD, die ein besseres Kosten-Nutzer-Verhältnis erzielen können.
Die Nutzung von Azure Virtual Desktop setzt voraus, dass der Benutzer, der den Dienst nutzt, über eine M365-Lizenz verfügt. Dabei kann es sich um eine Windows 10 Enterprise E3/E5, Windows VDA E3/E5, M365 Business Premium Lizenz oder um eine M365 Enterprise Lizenz F3/E3/E5 handeln. Wenn ein Server-Betriebssystem für den AVD-Host verwendet wird, müssen zusätzlich eine Windows Server CAL und eine RDS CAL gekauft werden. Eine gültige Lizenz, die zur Nutzung des AVD-Dienstes berechtigt, ist also immer auch Teil der Kosten.
Pooled Host-Ansatz
Wenn Sie den Pooled Host-Ansatz mit AVD verwenden, können Sie einem AVD-Host eine variable Anzahl von Benutzern zuweisen. Die Anzahl der Benutzer hängt von der verwendeten Arbeitslast und der Größe des Hosts ab. In unserem Beispiel rechnen wir mit 10 Benutzern pro AVD-Host. Dies entspricht in etwa einem mittleren Workload-Verhältnis. Ein Teil der Kosten setzt sich aus den Lizenzkosten zusammen. Der andere Teil sind die Infrastrukturkosten. Wenn Sie einen D4s_v3 mit 4 vCPU-Kernen und 16 GB RAM verwenden, belaufen sich die Kosten auf etwa 260,- EUR pro Monat. Hinzu kommen weitere Kosten für den Speicherplatz, den Sie nutzen. Wenn Sie also ein Azure Storage-Konto als Profilfreigabe für die Benutzer verwenden, müssen Sie auch diese Kosten einkalkulieren. Wenn Sie den Benutzern in unserem Beispiel diesen Host zuweisen und die Kosten durch 10 teilen, bedeutet es, dass der Host etwa 26,- EUR pro Monat und Benutzer kostet, zuzüglich der Kosten für die Profilfreigabe und Lizenz. Diese Kosten können mit den Skalierungsplänen für AVD gesenkt werden.
Lassen Sie uns ein anderes Szenario annehmen: Sie haben fünf AVD-Hosts mit einer Depth-First-Konfiguration. Hier verwenden Sie erneut die D4s_v3 SKU, d.h. Sie zahlen 5x 260,- EUR pro Monat und Host. Alles in allem sind das 1.300,- EUR pro Monat. Nicht ganz preiswert. Aber werden überhaupt alle Hosts ständig benötigt? Sicher nicht. Warum also nicht die Hosts außerhalb der Geschäftszeiten abschalten oder nur so viele Hosts starten, wie wirklich erforderlich sind. Warum fünf Hosts betreiben, wenn zwei davon vollkommen leer sind. Für diese Art der horizontalen Skalierung hilft Ihnen die Funktion “Scaling Plans” von Azure Virtual Desktop, um Kosten zu sparen.
Mit den Skalierungsplänen können Sie Ramp-up, Peak Time, Ramp-Down und Off-Peak definieren. Nachfolgend finden Sie eine Übersicht über die Einstellungen und ihre Beschreibung für die Skalierungspläne.
| Scaling Plan Settings | Scaling Plan Sub-Settings | Value | Description |
|---|---|---|---|
| General | Timezone | CEST | CEST would be standard TimeZone |
| Schedule Name | Name of the Schedule | ||
| Repeat on | Monday, Tuesday, Wednesday, ... | Days when this Schedule applies | |
| Ramp-Up | Start Time | 07:00 | Point in Time, when to start the Hosts |
| Balancing Algorithm | Breath-First / Depth-First | For using Autoscaling, the Depth-first load balancing option would be more relevant to {CUSTOMERS} needs as it is distributing the new user sessions to the available session host with the highest number of connections but has not reached its maximum session limit threshold which leads to minimizing the number of powered host sessions. | |
| Min. Percentage of Hosts | 30 | Specify the minimum percentage of session hosts to start for ramp-up and peak hours, the percentage is based on the total number of session hosts in {CUSTOMER} host pool, so if the host pool includes 10 VMs and the percentage is 30% as in the above image, autoscale will ensure a minimum of 3 session host is available to take user connections. | |
| Capacity Threshold | 70 | This percentage evaluates whether to turn on/off VMs during the ramp-up and peak hours. So, if your total host pool capacity is 10 sessions, and you specify a 70% Capacity threshold, once you exceed it, then autoscale will turn on additional session hosts. | |
| Peak Time | Start Time | 07:00 | Point in Time when Peak-Time Starts |
| Balancing Algorithm | Breath-First / Depth-First | For using Autoscaling, the Depth-first load balancing option would be more relevant to {CUSTOMERS} needs as it is distributing the new user sessions to the available session host with the highest number of connections but has not reached its maximum session limit threshold which leads to minimizing the number of powered host sessions. | |
| Ramp-Down | Start Time | 07:00 | Point in Time, when to start Ramp-Down Phase |
| Balancing Algorithm | Breath-First / Depth-First | For using Autoscaling, the Depth-first load balancing option would be more relevant to {CUSTOMERS} needs as it is distributing the new user sessions to the available session host with the highest number of connections but has not reached its maximum session limit threshold which leads to minimizing the number of powered host sessions. | |
| Min. Percentage of Hosts | 10 | Specify the minimum percentage of session hosts to start for ramp-up and peak hours, the percentage is based on the total number of session hosts in {CUSTOMER} host pool, so if the host pool includes 10 VMs and the percentage is 10% as in the above image, autoscale will ensure a minimum of 1 session host is available to take user connections. | |
| Capacity Threshold | 80 | This percentage evaluates whether to turn on/off VMs during the ramp-up and peak hours. So, if your total host pool capacity is 10 sessions, and you specify a 80% Capacity threshold, once you exceed it, then autoscale will turn on additional session hosts. | |
| Force logoff Users | Yes / No | Settings for logging of the connected users to be enforced. | |
| Delay time before logging out Users (minutes) | 10 | This option will set the session host VMs to drain mode, notify any currently signed-in users to save their work, and wait the configured amount of time before forcing the users to log off. Once all user sessions on the session host VM have been logged off, autoscale will shut down the VM. | |
| Notification Message | You’ll be signed out soon! | You can provide a Message to currently logged in Users to take care to save work and logoff in time. | |
| Off Peak Time | Start Time | 20:00 | Point in Time, when Off-Peak-Time Starts |
| Balancing Algorithm | Breath-First / Depth-First | For using Autoscaling, the Depth-first load balancing option would be more relevant to {CUSTOMERS} needs as it is distributing the new user sessions to the available session host with the highest number of connections but has not reached its maximum session limit threshold which leads to minimizing the number of powered host sessions. | |
| Host Pool Assignment | Hostpool 1 + 2 + n | Select Hostpools, where the Scaling Plan is assigned to. |
Mit dieser Option können Sie die Kosten für Ihre “Pooled Hosts” schnell und einfach senken. Es kann Skalierungspläne für alle “Pooled Hosts” sowie für verschiedene “Pooled Hosts” geben, die jederzeit angepasst werden können. Dies kann die Kosten um bis zu 50% senken. Darüber hinaus können Sie mit Compute-Reservierungen arbeiten, indem Sie einen oder zwei Hosts zu einem bestimmten Zeitpunkt reservieren, denn mindestens ein bis zwei Hosts sollten immer verfügbar sein. Alle zusätzlichen Hosts werden pro Nutzung bezahlt und nach Bedarf gestartet und gestoppt. Eine vertikale Skalierung für die AVD-Hosts wird nicht empfohlen. Dies würde bedeuten, dass die SKU der VM nach oben oder unten skaliert wird.
Personal Host-Ansatz
Bei “Personal Hosts” besteht, anders als beim “Pooling”, eine 1:1-Beziehung zwischen Benutzern und Hosts. Das bedeutet, dass ein Host nur von einem Benutzer verwendet wird und ihm als eigener virtueller Desktop dient. Zu diesen Szenarien gehören Entwickler-Workstations oder Workstations für andere spezielle Workloads wie beispielsweise CAD. Dieser Ansatz kann auch als schnelle Lösung für Akquisitionen oder neue Mitarbeiter sowie als Arbeitsplatz für externe Lieferanten dienen.
Bei der Verwendung des Personal Host-Ansatzes ist es wichtig zu verstehen, wie der Benutzer den Host nutzt. Nutzt er ihn rund um die Uhr oder nur für ein paar Stunden am Tag? Hier können Reservierungen eine gute Lösung sein, um Kosten zu sparen. Sie lohnen sich jedoch nur, wenn der Host nicht die meiste Zeit ungenutzt ist. In den Szenarien, in denen der Host größtenteils unbelegt ist, empfiehlt es sich, mit einer Deallokation des Hosts zu arbeiten, da hierfür keine Kosten anfallen. Microsoft hat derzeit keine automatische Out-of-the-Box-Lösung für “Personal Hosts” auf Lager, wie etwa die Skalierungspläne. Sie müssen also selbst entscheiden, wie Sie Ihre Kosten senken wollen:
- Ungenutzte Hosts manuell herunterfahren
- Verwenden der Auto-Shutdown-Funktion der Azure VMs
- Nutzen der Azure-Funktion zum Herunterfahren und Freigeben der Hosts
Wir sind uns sicher alle einig, dass die erste Option in einer Produktionsumgebung nicht wirklich praktikabel ist. Die zweite Option ist ein guter Anfang, aber sie hat auch ihre Schwächen. So können Sie z.B. nur eine Uhrzeit pro Tag festlegen (22 Uhr) und der Benutzer kann den Rechner sofort neu starten und er läuft für die nächsten 23 Stunden weiter, bevor das automatische Herunterfahren ihn wieder stoppt. Gut, aber manuell zu konfigurieren, ist, dass der Benutzer per E-Mail gewarnt werden kann, dass sich der Rechner in 30 Minuten abschalten wird und er das Herunterfahren verschieben oder abbrechen kann.
Die dritte Möglichkeit besteht darin, eine Azure-Funktion zu verwenden und weitere Parameter für das Herunterfahren zu definieren. Wir haben dafür eine Funktion geschrieben, die die Hosts überprüft, ob es gestoppte, aber nicht freigegebene sowie leere Hosts (kein angemeldeter Benutzer) gibt. Diese werden mit deallocate heruntergefahren. Die Funktion wird alle 5 Minuten nach einem freien Zeitplan gestartet und tut, was sie tun soll. Es stellt sich jedoch die Frage, was mit den Hosts geschieht, auf denen zwar Benutzer angemeldet, aber nicht verbunden sind? Diese Hosts werden nicht heruntergefahren, da wir nicht wissen, ob der Benutzer auf dem Host einen Auftrag ausführt oder ungespeicherte Arbeit hat. Für dieses Szenario bleibt uns nur die Möglichkeit, mit den Benutzern zu vereinbaren, dass sie den Host herunterfahren oder sich wirklich abmelden, sobald sie ihre Arbeit beendet haben, aber wir alle wissen, dass dies nur in 50% der Fälle funktioniert. Alternativ können Sie lokale Registrierungseinstellungen für die Leerlaufzeit und die maximale Trennungszeit verwenden und festlegen, dass die Sitzung des Benutzers nach, sagen wir, 4 Stunden abgemeldet wird.
Alle diese Optionen sind nicht perfekt, aber sie funktionieren für den Moment und reduzieren die Kosten für persönliche Hosts bisher sehr gut.