Verwenden von Spot-VMs in Azure CycleCloud

Azure CycleCloud unterstützt die Bereitstellung von Spot-VMs in Knotenarrays, um die Betriebskosten von Clustern erheblich zu verringern.

Achtung

Spot-VMs sind nicht für alle Workloads und Clustertypen geeignet. Sie bieten keine SLA für Verfügbarkeit oder Kapazität. Sie sind "preemptible" oder "Low-Priority"-Instanzen und können von der Azure-Fabric entfernt werden, um Kapazität zu verwalten und während sich der Spotpreis ändert.

Konfigurieren eines Nodearrays für Spot

Um Spot für ein Knotenarray zu aktivieren, legen Sie einfach auf "true" im [[nodearray]] Abschnitt festInterruptible.

CycleCloud ermöglicht Clustern die Angabe einer MaxPrice Spotinstanz. Da der Spotpreis regelmäßig angepasst werden kann und zwischen Regionen und SKUs erheblich variieren kann, können Benutzer MaxPrice den Höchstpreis (in $/Stunde) steuern, den sie für eine VM bezahlen möchten. Standardmäßig legt MaxPrice=-1 CycleCloud fest, wenn sie nicht anders angegeben ist, was bedeutet, dass "nicht basierend auf spotpreisen" ausfällt. Bei dieser Einstellung werden Instanzen nur aufgrund von Änderungen an Kapazitätsanforderungen oder anderen Entscheidungen auf Plattformebene entfernt.

Details zu variablen Preisen für Spotinstanzen finden Sie unter Spotpreise .

Für die meisten HPC-Anwendungen MaxPrice=-1 ist eine gute Standardauswahl. Wenn ein Nodearray jedoch die automatische Multiauswahl über einen Bereich von VM-SKUs unterstützt, kann es auch angepasst werden, MaxPrice um eine Einstellung für niedrigere Preis-SKUs in der Multiauswahlliste zu erstellen.

[cluster demo]

  [[nodearray execute]]
  Interruptible = true
  MaxPrice = 0.2

Ausführliche Informationen finden Sie unter Spot Virtual Machines im Clustervorlagenhandbuch.

Spot VM Eviction

CycleCloud überwacht Spoträumungen über das Feature "Geplante Ereignisse ". Wenn ein Spot preemption-Ereignis erkannt wird, wird CycleCloud von der VM benachrichtigt, und die Instanz wird in einen Zustand "Warten auf Eviction" verschoben.

Häufig gestellte Fragen

Die Verwendung von Spot with CycleCloud weist einige Überlegungen auf, die für HPC-Workloads und die automatische Skalierung von CycleCloud spezifisch sind.

Wann sollte ich die Verwendung von Spot in Betracht ziehen?

• Sind Ihre individuellen Arbeitsplätze relativ kurz?
  • Eine gute Faustregel besteht darin, dass Aufträge, die in einer Stunde ausgeführt werden, für Spotinstanzen geeignet sein können, da relativ wenig Vorwärtsfortschritt verloren geht, wenn die Instanz entfernt wird.
• Wird der Zeitplaner automatisch erneut versuchen/erneut auf Hosts zurückstellen, die fehlschlagen?
• Sind Ihre Aufträge sicher, erneut auszuführen, wenn der Host während der Ausführung weggeräumt wird?
  • Im Allgemeinen eignen sich Spotinstanzen am besten für zustandslose Workloads.
• Ist die Minimierung der Kosten für die Ausführung wichtiger als die Fertigstellungszeit?
  • Spot ist häufig perfekt für Arbeitslasten, die in lokalen Oder Back-Fill-Warteschlangen geplant werden können.
  • Dies ist eines der Fälle, in denen Spot auch für kurze MPI-Aufträge geeignet sein kann.

Wann sollte ich die Verwendung von Spot vermeiden?

• Wenn Ihre Jobs eng gekoppelte HPC-Aufträge (z. B. MPI-Aufträge) sind, sind sie wahrscheinlich keine guten Kandidaten für Spot.
• Wenn Ihr Auftrag kritisch ist und/oder einen Stichtag für den Abschluss hat, kann es sich bei regelmäßigen Prioritätsinstanzen um eine bessere Anpassung ergeben, da Vertreibungen und Wiederholungen die Zeit bis zum Abschluss verlängern können.
  • Dies kann jedoch eine hervorragende Möglichkeit sein, Ihren Cluster so zu konfigurieren, dass eine Mischung aus regelmäßigen Prioritäts- und Spotinstanzen verwendet wird, um sicherzustellen, dass der Stichtag erfüllt ist, während versucht wird, die Laufzeit und die Kosten durch Hinzufügen von Spotinstanzen zu reduzieren.
• Wenn Ihre Aufträge nicht sicher sind, erneut auszuführen, sollte Spot vermieden werden.
  • Wenn Ihr Auftrag beispielsweise eine Datenbank während der Ausführung ändert, kann die erneute Ausführung des Auftrags zu Fehlern oder ungültigen Ergebnissen führen.
• Wenn Ihre Jobs-Laufzeiten sehr lang sind, ist Spot möglicherweise nicht gut geeignet.
  • Für lange Prozesse, sowohl die Chance der Spot-Vertreibung als auch der Zeitkosten von Wiederholungen zu erhöhen.
  • Dies ist jedoch ein Fall, der eine Messung nach Fall erfordern kann.

Eviction / Preemption

Details zur Spot-Eviction-Richtlinie finden Sie unter Spot-Eviction-Richtlinie in Azure.

Q. Kann CycleCloud Spot-Instanz evictions/Preemptions nachverfolgen?

A. Ja. Ein Spot-Eviction-Ereignis generiert eine Ereignisprotokollbenachrichtigung auf der Ui-Seite "Cluster".

Q. Wie werden Die Benutzer über Dieräumung benachrichtigt?

A. Nachdem ein CycleCloud-Knoten ausgezogen wurde, wird benutzern eine Protokollmeldung im Ereignisprotokoll der CycleCloud-Benutzeroberfläche für den Cluster angezeigt. Benutzer können sich auch registrieren, um ein Ereignis von CycleCloud über Azure EventGrid zu erhalten, nachdem eine Spotinstanz entfernt wurde.

• Benutzer können vor der Vertreibung auf dem Computer 30 Sekunden nach einer Benachrichtigung suchen. Ausführliche Informationen zum Registrieren für das Ereignis finden Sie unter "Geplante Ereignisse ".
• Im Allgemeinen sollte die Vertreibung ähnlich wie das Ziehen des Plug-Ins auf einem lokalen Computer betrachtet werden, und es sollte auf die gleiche Weise behandelt werden.
• WICHTIG Ereignishandler sollten das Spot Eviction-Ereignis nicht bestätigen , da der Cyclecloud-Ereignishandler das Ereignis möglicherweise nicht empfängt, wenn es bestätigt wird.

Q. Wie häufig tritt Eviction auf?

A. Die Vertreibungsrate ist sehr variabel und hängt weitgehend von den Veränderungen der Nachfrage in der gesamten Region ab.

Q. Warum werden Instanzen entfernt?

A. Spot-VMs garantieren keine Garantien über die Verfügbarkeit und können jederzeit verworfen werden. Ausführliche Informationen finden Sie in der Spot-VM-Dokumentation . Wenn ein Nodearray eine MaxPrice Instanz festgelegt hat, wird die Instanz entfernt, wenn der Spotpreis über dem MaxPriceWert steigt. Dies ist tendenziell selten , da sich der Spotpreis sehr langsam bewegt. Nachfolgend sind einige Szenarien aufgeführt, die eine Auslassung auslösen können :

1. Reduzierung der Spotkapazität, da die Nachfrage nach regelmäßigen Prioritäts-VMs steigt.
2. Ereignisse auf Plattformebene, z. B. geplante Hardwarewartung.

Wie wirkt sich mein Workflow durch Eviction aus?

Q. Was geschieht mit meinen Jobs, wenn eine Spot-Instanz weggeräumt wird?

A. Es sei denn, die Aufträge werden codiert, um die 30 zweite Eviction-Benachrichtigung zu behandeln und entsprechend zu behandeln, wird der Knoten einfach beendet, und der Auftrag ist fehlgeschlagen (und hoffentlich erneut versucht).

Q. Werden die Knoten aus dem Cluster gelöscht?

A. Ja, die Knoten werden in der CycleCloud-Benutzeroberfläche bereinigt. In unterstützten Schedulern werden die Knoten auch im Scheduler bereinigt.

Q. Müssen Aufträge erneut ausgeführt werden?

A. Im Allgemeinen ist es der Auftrag des Planers, die Aufträge erneut auszuführen/ auszuführen, die weggeräumt werden. Viele Auftragsklassen sind jedoch nicht tolerant für Erneute Versuche (z. B. wenn sie Teildaten während der Ausführung in beständigen Speicher schreiben). Diese Aufträge sind möglicherweise nicht gut für die Ausführung auf Spotinstanzen geeignet.

Q. Kann ich eine Mischung aus Spot- und On-Demand/Regular-Priority-VMs verwenden?

A. Ja. Sie können separate Spot(Interruptible) und Nicht-Spot-Knotenarrays verwenden, um eine Mischung aus Spot und Regulärer Priorität zu erstellen. Die Verwendung einer Mischung aus Instanztypen erfordert in der Regel einige Konfigurationsentscheidungen abhängig von den Anforderungen und dem Zeitplan, den der Benutzer ausgewählt hat. Hier sind einige gängige Konfigurationen:

• Trennen Sie Spot- und Regular-Priority-VMs in separate Warteschlangen im Zeitplaner.
  • Mit dieser Konfiguration kann der Übermittlungsgeber ganz einfach Aufträge auf den entsprechenden VM-Typ ausrichten.
• Erstellen Sie einen einzelnen großen Ressourcenpool mit Spot- und Regular-Priority Instanzen.
  • Diese Konfiguration kann für hoch skalierbare Workloads nützlich sein, die einen kleinen Prozentsatz regelmäßiger Prioritätsinstanzen verwenden, um den Fortschritt vorwärts und einen großen Prozentsatz von Spot sicherzustellen, um Kosten und Laufzeit zu reduzieren.

Q. Kann ich die Spot-Eviction-Richtlinie für CycleCloud-Knotenarrays ändern?

A. Ja. Sie können das EvictionPolicy Attribut direkt auf dem Knotenarray festlegen, um die Richtlinie entweder Delete oder Deallocate (Standard: Delete) zu ändern. Dies ist derzeit jedoch nur für benutzerdefinierte Autoscaler nützlich, die Deallocations entsprechend behandeln. Die aktuellen Azure CycleCloud-Autoscaler erwarten, dass Spotinstanzen nach Löschvorgang gelöscht werden.

Planerunterstützung für Spot-Eviktion in CycleCloud

Weitere Informationen zur CycleCloud-Implementierung für Ihren Terminplaner finden Sie in dem zeitplanspezifischen Leitfaden.

Q. Wie behandelt der Autoscaler für meinen Terminplaner spot eviction?

A. Alle Autoscaler für die integrierten/unterstützten Zeitplaner (HTCondor, GridEngine, PBS Professional, Slurm, LSF) versuchen, Spot-Eviktionen ordnungsgemäß zu behandeln. Im Allgemeinen wird die gevicte Instanz aus dem Zeitplan entfernt und wenn die Kapazitätsnachfrage höher ist als die neue verfügbare Kapazität nach Löschung, ersetzt der Autoscaler die Instanz.

Benutzerdefinierte Autoscaler sollten gebaut werden, um Spot-Eviktionen oder allgemeine Maschinenfehler zu erwarten und sie ordnungsgemäß zu behandeln.

Q. Was sollte ich mit den Aufträgen erwarten, die auf der vicierten Instanz ausgeführt wurden?

A. Dies ist weitgehend bis zum Benutzer erforderlich, um beim Übermitteln des Auftrags zu konfigurieren. Einige Zeitplaner, z. B. GridEngine, zulassen, dass die Standardaktion auch pro Warteschlange konfiguriert werden kann. Standardmäßig werden alle integrierten CycleCloud-Zeitplanerbereitstellungen mit Ausnahme von HTCondor so konfiguriert, dass die Aufträge beim Ausführen des Knotens als fehlgeschlagen gekennzeichnet oder unerwartet beendet werden. Dieses Verhalten ist vom Entwurf aus, da nur der Benutzer wissen kann, ob ihre Aufträge sicher erneut bearbeitet werden können.