Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Die Aufgabenverwaltung für interaktive Spaces ist aktiviert HyperPod
In diesem Abschnitt wird beschrieben, wie Sie Ihre gemeinsam genutzten Amazon SageMaker HyperPod EKS-Cluster für Interactive Spaces-Workloads optimieren können. Sie lernen, die Aufgabenverwaltungsfunktionen von Kueue — einschließlich Kontingentverwaltung, Prioritätenplanung und Richtlinien zur gemeinsamen Nutzung von Ressourcen — zu konfigurieren, um sicherzustellen, dass Ihre Entwicklungsworkloads unterbrechungsfrei laufen und gleichzeitig eine faire Verteilung der Schulungs-, Evaluierungs- und Stapelverarbeitungsaktivitäten Ihrer Teams gewahrt bleibt.
So funktioniert interaktives Raummanagement
Um Interactive Spaces in gemeinsam genutzten HyperPod EKS-Clustern effektiv zu verwalten, implementieren Sie mithilfe der vorhandenen Funktionen von Kueue die folgenden Strategien zur Aufgabenverwaltung.
Konfiguration der Prioritätsklasse
Definieren Sie spezielle Prioritätsklassen für Interactive Spaces mit hoher Gewichtung (z. B. 100), um sicherzustellen, dass Entwicklungs-Pods vor anderen Aufgabentypen zugelassen und geplant werden. Diese Konfiguration ermöglicht es Interactive Spaces, Jobs mit niedrigerer Priorität beim Laden des Clusters zu verhindern, was für die Aufrechterhaltung unterbrechungsfreier Entwicklungsabläufe unerlässlich ist.
Größe und Zuteilung von Kontingenten
Reservieren Sie genügend Rechenressourcen in Ihrem Team, um die erwarteten Entwicklungslasten ClusterQueue zu bewältigen. In Zeiten, in denen Entwicklungsressourcen ungenutzt sind, können ungenutzte Quotenressourcen vorübergehend den Aufgaben anderer Teams zugewiesen werden. Wenn die Entwicklungsnachfrage steigt, können diese geliehenen Ressourcen zurückgefordert werden, um ausstehenden Interactive Space-Pods Priorität einzuräumen.
Strategien zur gemeinsamen Nutzung von Ressourcen
Wählen Sie zwischen zwei Anwesungen zur Aufteilung der Kontingente, die Ihren Anforderungen entsprechen:
Strikte Ressourcenkontrolle: Deaktiviere das Ausleihen und Ausleihen von Quoten, um sicherzustellen, dass reservierte Rechenkapazität für deine Interactive Spaces immer verfügbar ist. Bei diesem Ansatz sind Größenkontingente erforderlich, die groß genug sind, um den hohen Entwicklungsbedarf eigenständig abzudecken. In Zeiten geringer Auslastung kann dies dazu führen, dass Knoten im Leerlauf sind.
Flexible gemeinsame Nutzung von Ressourcen: Ermöglichen Sie die Ausleihe von Kontingenten, damit andere Teams ungenutzte Entwicklungsressourcen bei Bedarf nutzen können. Deaktivieren Sie jedoch die Ausleihe, um sicherzustellen, dass Interactive Spaces niemals mit geliehenen, rückzahlbaren Ressourcen betrieben werden, was zu unerwarteten Räumungen führen könnte.
Intra-Team Präventiv
Aktivieren Sie die teaminterne Präemption, wenn Sie gemischte Workloads (Schulung, Evaluierung und interaktive Bereiche) unter derselben Quote ausführen. Auf diese Weise kann Kueue Aufgaben innerhalb Ihres Teams mit niedrigerer Priorität verhindern, um Interactive Space-Pods mit hoher Priorität unterzubringen. So wird sichergestellt, dass die Entwicklungsarbeit ohne externe Quotenausleihe fortgesetzt werden kann.
Beispiel für eine Einrichtung von Interactive Space
Das folgende Beispiel zeigt, wie Kueue die Rechenressourcen für Interactive Spaces in einem gemeinsam genutzten SageMaker HyperPod Amazon-Cluster verwaltet.
Cluster-Konfiguration und Einrichtung von Richtlinien
Ihr Cluster hat die folgende Konfiguration:
-
Team Alpha (Entwicklerteam): 8 CPU-Kontingent für interaktive Bereiche
-
Team Beta (ML Team): 16 CPU-Kontingent für Training und Bewertung
-
Team Gamma (Forschung): Quote von 6 CPUs für Experimente
-
Statische Bereitstellung: Keine automatische Skalierung
-
Gesamtkapazität: 30 CPUs
Der gemeinsam genutzte CPU-Pool verwendet diese Prioritätsrichtlinie:
-
Interaktive Bereiche: Priorität 100
-
Schulung: Priorität 75
-
Bewertung: Priorität 50
-
Stapelverarbeitung: Priorität 25
Kueue setzt Teamquoten und Prioritätsklassen durch, wobei die Präemption für das Entwicklerteam aktiviert und die Kreditaufnahme deaktiviert ist.
Ausgangszustand: Normale Cluster-Auslastung
Im Normalbetrieb:
-
Team Alpha: Führt 6 interaktive Spaces mit 6 CPUs aus, 2 CPUs sind inaktiv
-
Team Beta: Führt Trainingsjobs (12 CPUs) und Evaluierungsaufgaben (4 CPUs) im Rahmen seines 16-CPU-Kontingents aus
-
Team Gamma: Führt Forschungs-Workloads auf allen 6 CPUs aus
-
Gemeinsame Nutzung von Ressourcen: Team Beta leiht sich die 2 inaktiven CPUs von Team Alpha für zusätzliches Training
Entwicklungsschub: Team Alpha benötigt zusätzliche Ressourcen
Wenn die Entwickler von Team Alpha ihre Entwicklungsarbeit ausweiten müssen, benötigen zusätzliche Interactive Space-Pods 4 weitere CPUs. Kueue stellt fest, dass es sich bei den neuen Pods um:
-
Im Namespace von Team Alpha
-
Priorität 100 (Interaktive Räume)
-
Aufgrund von Quotenbeschränkungen steht die Zulassung noch aus
Der Antwortprozess von Kueue
Kueue folgt einem dreistufigen Prozess zur Zuweisung von Ressourcen:
-
Kontingentprüfung
Frage: Hat Team Alpha ein ungenutztes Kontingent?
-
Aktuelle Nutzung: 6 CPUs verwendet, 2 CPUs verfügbar
-
Neue Anforderung: 4 CPUs erforderlich
-
Ergebnis: Ungenügendes Kontingent → Fahren Sie mit Schritt 2 fort
-
-
Self-preemption innerhalb von Team Alpha
Frage: Können Team-Alpha-Jobs mit niedrigerer Priorität verhindert werden?
-
Verfügbare Ziele: Keine Jobs mit niedrigerer Priorität in Team Alpha
-
Ergebnis: Keine Präemption möglich → Fahren Sie mit Schritt 3 fort
-
-
Geliehene Ressourcen zurückfordern
Frage: Werden Team Alpha-Ressourcen von anderen Teams ausgeliehen?
-
Ausgeliehene Ressourcen: Team Beta verwendet 2 CPUs von Team Alpha
-
Aktion: Kueue entfernt die geliehenen Trainingseinheiten von Team Beta und gibt 2 CPUs frei
-
Verbleibender Bedarf: Benötigt noch 2 CPUs → Interactive Spaces bleiben im Status, bis Ressourcen verfügbar sind NotAdmitted
-
Bei diesem Ansatz werden interaktive Bereiche priorisiert und gleichzeitig die Grenzen der Teamquoten beibehalten und verhindert, dass die Entwicklungsarbeit auf instabilen, geliehenen Ressourcen läuft.