Dev- und Test-Workloads verhalten sich normalerweise anders als Standard-Desktops. Sie haben oft einen höheren CPU- und RAM-Bedarf, variablere Anmeldemuster und eine geringere Toleranz gegenüber Kaltstarts oder leistungsschwachen Hosts. Daher ist die beste Auto-Scale-Strategie in der Regel nicht die aggressivste. Es ist diejenige, die genügend Kapazität für Bursts bereithält und gleichzeitig Verschwendung in Leerlaufzeiten reduziert.
Ein einzelnes Auto-Scale-Muster passt nicht zu jedem Engineering-Workload. Gemeinsam genutzte QA- und Test-User profitieren normalerweise von gepoolter Elastizität, während Power-User und persistente Entwickler-Desktops oft mehr von persönlichen Desktops mit Ruhezustand, Rightsizing und Speicheroptimierung profitieren. Die Trennung dieser Workloads führt normalerweise zu einer besseren Leistung und einer besseren Kostenkontrolle, als alle User in einen Hostpool zu zwingen.
Verwenden Sie gepoolte Desktops, wenn User Hosts teilen können und das Hauptziel Elastizität und Kostenkontrolle ist.
Verwenden Sie persönliche Desktops, wenn User dedizierte Maschinen, beibehaltene Anpassungen oder ein Verhalten wie bei einer Workstation erfordern.
Wenn die Umgebung beide User-Typen umfasst, teilen Sie diese in separate Hostpools auf und optimieren Sie jeden einzeln.
Für die meisten gemeinsam genutzten Engineering-Workloads empfiehlt es sich, vor dem Hauptarbeitsfenster eine geringe Basiskapazität bereitzuhalten, die User während der Hochlaufphase breiter zu verteilen und nach der Stabilisierung des Spitzenbedarfs aggressiver zu konsolidieren. Ein Rolling Drain sollte vor geplanten Herunterfahrfenstern verwendet werden, und Start VM on Connect sollte zur Unterstützung außerhalb der Geschäftszeiten oder bei unerwartetem Zugriff genutzt werden, anstatt als einzige Strategie für die Verfügbarkeit zu dienen.
Als Ausgangspunkt ist eine kleine warme Baseline während der Randzeiten oft effektiver, als den Pool komplett kalt zu betreiben. Dies reduziert Anmeldeverzögerungen und ermöglicht dennoch, dass Nerdio Manager während Zeiten geringer Nachfrage herunterskaliert.
Bei dedizierten Entwickler-Workstations sollte sich der Fokus von der Elastizität gemeinsam genutzter Hosts auf die Reduzierung der Kosten für ungenutzte Ressourcen verlagern. Persönliche Desktops sind in der Regel am besten optimiert durch den Einsatz von Ruhezustand oder zeitbasierten Energieaktionen, regelmäßiger VM-Größenanpassung und der Optimierung der angehaltenen Disk, wenn die Sitzungshost-VM nicht verwendet wird.
Wenn die meisten User zu festen Zeiten arbeiten, halten Sie eine kleine Basiskapazität bereit, bevor der Arbeitstag beginnt, skalieren Sie dann während des Hauptfensters horizontal hoch und nach Rückgang der Nachfrage horizontal herunter. Dies funktioniert gut für Entwicklungsteams mit regelmäßiger Nutzung während der Geschäftszeiten sowie einer kleinen Anzahl von Usern, die früh oder spät arbeiten.
Wenn die Nutzung inkonsistent ist, wie bei der Qualitätssicherung, bei Release-Tests oder kurzzeitigen Compute-Bursts, halten Sie eine sehr kleine warme Baseline bereit und verwenden Sie Start VM on Connect für den Zugriff bei geringer Auslastung. In diesen Umgebungen sollten Auto-scale-Einstellungen sorgfältig anhand der tatsächlichen Anmeldezeiten und der Host-Leistung validiert werden, um eine übermäßige Konsolidierung zu vermeiden.
Wenn User komplexe Toolchains, benutzerdefinierte lokale Dienste oder individuelle Workstation-Konfigurationen ausführen, sind persönliche Desktops oft die bessere Wahl. In diesen Fällen ergibt sich die Kostenkontrolle eher durch intelligentes Herunterfahren oder Versetzen in den Ruhezustand und die Optimierung der Disk-Kosten als durch die Dichte gemeinsam genutzter Hosts.
Start VM on Connect ermöglicht das Einschalten eines Sitzungshosts, wenn ein Benutzer eine Verbindung herstellt und der Host noch nicht läuft. Dies ist nützlich für den Zugriff außerhalb der Geschäftszeiten und kleinere Rand-Workloads. In Umgebungen mit sprunghaften oder gleichzeitigen Anmeldungen kann es jedoch zu einer langsameren Benutzerbereitschaft führen, wenn man sich allein darauf verlässt, anstatt eine gewisse warme Kapazität aufrechtzuerhalten.
Die Compute-Kosten sind nur ein Teil der Gesamtausgaben. Speicherkosten fallen auch dann an, wenn eine Sitzungshost-VM angehalten ist. Nerdio Manager kann den Betriebssystem-Disk-Typ angehaltener Sitzungshost-VMs automatisch auf eine günstigere Speicherstufe umstellen und die Disk vor dem Start wieder auf die leistungsstärkere Stufe zurücksetzen. Dies gilt sowohl für gepoolte als auch für persönliche Hostpools und kann bei korrekter Konfiguration erhebliche Einsparungen ermöglichen.
Anmerkung
Wenn die Azure Start VM on Connect-Funktion einen Sitzungshost außerhalb von Nerdio Manager einschaltet, erfolgt die Änderung der Disk-Leistung möglicherweise nicht automatisch. In diesem Fall sollten die Pre-Staging-Einstellungen so konfiguriert werden, dass die Hosts bereits den aktiven Disk-Typ verwenden, bevor sich Benutzer verbinden.
Wenn die bevorzugte Sitzungshost-VM-Größe in einer Azure-Region häufig nicht verfügbar ist, kann Azure Capacity Extender dazu beitragen, dass Hostpool-Erstellungs-, Auto-Scale-, Auto-Grow- und Auto-Heal-Vorgänge nicht fehlschlagen, indem alternative Sitzungshost-VM-Größen nacheinander verwendet werden können. Wählen Sie bei der Auswahl von Fallback-Größen Optionen mit ähnlichen Ressourcenprofilen, um eine inkonsistente Benutzerleistung zu vermeiden.
-
Verwenden Sie gepoolte Desktops für gemeinsam genutzte, elastische Workloads.
-
Verwenden Sie persönliche Desktops für dedizierte Power-User.
-
Behalten Sie während der Randzeiten eine kleine warme Baseline bei, anstatt vollständig kalt zu fahren.
-
Verwenden Sie Start VM on Connect für den Zugriff außerhalb der Geschäftszeiten, nicht als einzigen Bereitschaftsplan für Teams mit schwankendem Bedarf.
-
Kombinieren Sie Auto-scale mit der Optimierung des Betriebssystem-Datenträgers, um sowohl Compute- als auch Speicher-Verschwendung zu reduzieren.
-
Unterteilen Sie wesentlich unterschiedliche Benutzerprofile in separate Hostpools, anstatt eine Kompromisskonfiguration auf alle anzuwenden.
Für die meisten Entwicklungs- und Testumgebungen ist eine ausgewogene Auto-scale-Strategie am besten geeignet. Halten Sie genügend Kapazität bereit, um die Benutzererfahrung zu schützen, verwenden Sie gepoolte Desktops, wenn Workloads geteilt werden können, verwenden Sie persönliche Desktops, wenn Persistenz wichtig ist, und kombinieren Sie Auto-scale mit Speicheroptimierung und Planung von Ausweichkapazitäten. Dieser Ansatz bringt in der Regel eine bessere Leistung und weniger Verschwendung als ein vollständig statisches Design oder ein zu aggressives Modell des horizontalen Herunterskalierens.
Kommentare (0 Kommentare)