Richtlinien - Amazon SageMaker KI
Beispiele für die gemeinsame Nutzung inaktiver RechenressourcenSo funktioniert die gemeinsame Nutzung nicht zugewiesener RessourcenEignung des Knotens für die gemeinsame Nutzung nicht zugewiesener Ressourcen

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.

Richtlinien

Amazon SageMaker HyperPod Task Governance vereinfacht die Zuweisung Ihrer Amazon EKS-Cluster-Ressourcen und die Priorisierung von Aufgaben. Im Folgenden finden Sie Informationen zu HyperPod EKS-Clusterrichtlinien. Weitere Informationen dazu, wie Sie Aufgaben-Governance einrichten, finden Sie unter Einrichtung der Aufgaben-Governance.

Die Richtlinien sind in Rechenpriorisierung und Rechenzuweisung unterteilt. Die folgenden Richtlinienkonzepte werden im Kontext dieser Richtlinien strukturiert.

Die Rechenpriorisierung oder Clusterrichtlinie bestimmt, wie ungenutzte Rechenleistung ausgeliehen wird und wie Aufgaben von Teams priorisiert werden.

  • Die Zuweisung inaktiver Rechenleistung definiert, wie ungenutzte Rechenleistung den Teams zugewiesen wird. Das heißt, wie ungenutzte Rechenleistung von Teams ausgeliehen werden kann. Bei der Auswahl einer Zuweisung inaktiver Rechenleistung können Sie zwischen folgenden Optionen wählen:

    • First-come first-serve: Bei der Anwendung werden Teams nicht gegeneinander priorisiert, und jede eingehende Aufgabe hat die gleiche Wahrscheinlichkeit, Ressourcen über die Quote hinaus zu erhalten. Aufgaben werden in der Reihenfolge ihrer Einreichung priorisiert. Das bedeutet, dass ein Benutzer möglicherweise 100 % der inaktiven Rechenleistung nutzen kann, wenn er dies zuerst anfordert.

    • Fair-Share: Bei Anwendung dieser Option leihen sich Teams ungenutzte Rechenleistung auf der Grundlage des ihnen zugewiesenen Fair-Share-Gewichts. Diese Gewichtungen sind unter Rechenzuweisung definiert. Weitere Informationen zur Verwendung finden Sie unter Beispiele für die gemeinsame Nutzung inaktiver Rechenressourcen.

  • Aufgabenpriorisierung definiert, wie Aufgaben in die Warteschlange gestellt werden, sobald Rechenleistung verfügbar ist. Bei der Auswahl einer Aufgabenpriorisierung können Sie zwischen folgenden Optionen wählen:

    • First-come first-serve: Wenn diese Option angewendet wird, werden sie in der Reihenfolge, in der sie angefordert wurden, in die Warteschlange gestellt.

    • Rangfolge der Aufgaben: Wenn diese Option angewendet wird, werden sie in der Reihenfolge, die durch ihre Priorisierung definiert ist, in die Warteschlange gestellt. Wenn diese Option ausgewählt ist, müssen Sie Prioritätsklassen zusammen mit den Gewichtungen hinzufügen, nach denen sie priorisiert werden sollen. Aufgaben derselben Prioritätsklasse werden nach dem Prinzip „first-come first-serve“ ausgeführt. Wenn diese Option in der Rechenzuweisung aktiviert ist, werden Aufgaben mit niedrigerer Priorität durch Aufgaben mit höherer Priorität innerhalb des Teams vorgezogen.

      Wenn Datenwissenschaftler Aufträge an den Cluster senden, verwenden sie den Namen der Prioritätsklasse in der YAML-Datei. Die Prioritätsklasse hat das Format priority-class-name-priority. Ein Beispiel finden Sie unter Senden Sie einen Job an eine von SageMaker KI verwaltete Warteschlange und einen Namespace.

    • Prioritätsklassen: Diese Klassen legen eine relative Priorität für Aufgaben beim Ausleihen von Kapazitäten fest. Wenn eine Aufgabe mit geliehenem Kontingent ausgeführt wird, kann sie von einer anderen Aufgabe mit höherer Priorität verdrängt werden, wenn für die eingehende Aufgabe keine Kapazität mehr verfügbar ist. Wenn Preemption in der Rechenzuweisung aktiviert ist, kann eine Aufgabe mit höherer Priorität auch Aufgaben innerhalb ihres eigenen Teams vorrangig behandeln.

  • Die gemeinsame Nutzung nicht zugewiesener Ressourcen ermöglicht es Teams, Rechenressourcen auszuleihen, die im Rahmen der Rechenquote keinem Team zugewiesen wurden. Wenn diese Option aktiviert ist, steht Teams nicht zugewiesene Clusterkapazität automatisch zur Verfügung. Weitere Informationen finden Sie unter So funktioniert die gemeinsame Nutzung nicht zugewiesener Ressourcen.

Die Rechenzuweisung oder das Rechenkontingent definiert die Rechenzuweisung eines Teams und legt fest, welche Gewichtung (oder Prioritätsstufe) ein Team erhält, wenn es ungenutzte Rechenleistung fair verteilt.

  • Teamname: Der Teamname. Es wird ein entsprechender Namespace des Typs hyperpod-ns-team-name erstellt.

  • Mitglieder: Mitglieder des Team-Namespace. Sie müssen eine rollenbasierte Zugriffskontrolle (RBAC) von Kubernetes für Data Scientist-Benutzer einrichten, die Teil dieses Teams sein sollen, um Aufgaben auf HyperPod Clustern auszuführen, die mit Amazon EKS orchestriert wurden. Um einen Kubernetes-RBAC einzurichten, folgen Sie den Anweisungen unter Teamrolle erstellen.

  • Fair-Share-Gewichtung: Dies ist die Priorisierungsstufe, die dem Team zugewiesen wird, wenn Fair-Share für die Zuweisung von inaktiver Rechenleistung angewendet wird. Die höchste Priorität hat eine Gewichtung von 100 und die niedrigste Priorität hat eine Gewichtung von 0. Eine höhere Gewichtung ermöglicht es einem Team, früher auf ungenutzte Ressourcen innerhalb gemeinsam genutzter Kapazitäten zuzugreifen. Eine Gewichtung von Null bedeutet die niedrigste Priorität, was bedeutet, dass dieses Team im Vergleich zu anderen Teams immer im Nachteil sein wird.

    Die Fair-Share-Gewichtung verschafft diesem Team einen Wettbewerbsvorteil, wenn es um verfügbare Ressourcen gegen andere wetteifert. Die Zulassung priorisiert die Planung von Aufgaben von Teams mit den höchsten Gewichtungen und den geringsten Ausleihen. Wenn beispielsweise Team A ein Gewicht von 10 und Team B ein Gewicht von 5 hat, hätte Team A Vorrang beim Zugriff auf ungenutzte Ressourcen, da es Aufgaben hätte, die früher als Team B geplant sind.

  • Aufgaben-Preemption: Die Berechnung wird basierend auf der Priorität von einer Aufgabe übernommen. Standardmäßig hat das Team, das inaktive Rechenleistung ausleiht, Vorrang vor Aufgaben anderer Teams.

  • Verleihen und Ausleihen: Wie inaktive Rechenleistung vom Team verliehen wird und ob das Team Rechenleistung von anderen Teams ausleihen kann.

    • Prozentuales Kreditlimit: Das Limit für ungenutzte Rechenleistung, das ein Team ausleihen darf, ausgedrückt als Prozentsatz der garantierten Quote. Ein Team kann bis zu 10.000% der zugewiesenen Rechenleistung ausleihen. Der Wert, den Sie hier angeben, wird als Prozentsatz interpretiert. Ein Wert von 500 wird beispielsweise als 500 % interpretiert. Dieser Prozentsatz gilt einheitlich für alle Ressourcentypen (CPU, GPU, Arbeitsspeicher) und Instanztypen, die im Kontingent des Teams enthalten sind.

    • Absolutes Kreditlimit: Das Limit für ungenutzte Rechenleistung, das ein Team ausleihen darf, definiert als absolute Ressourcenwerte pro Instanztyp. Dies ermöglicht eine detaillierte Steuerung des Ausleihverhaltens für bestimmte Instance-Typen. Sie müssen absolute Grenzwerte angeben, indem Sie dasselbe Schema wie das Compute-Kontingent verwenden, einschließlich Instanzanzahl, Beschleuniger, vCPU, Arbeitsspeicher oder Beschleunigerpartitionen. Sie können absolute Grenzwerte für einen oder mehrere Instanztypen in der Quote Ihres Teams angeben.

Informationen zur Verwendung dieser Konzepte, wie Prioritätsklassen und Namensräume, finden Sie unter Beispiele für HyperPod Task-Governance-Befehle AWS CLI.

Beispiele für die gemeinsame Nutzung inaktiver Rechenressourcen

Das reservierte Gesamtkontingent sollte die verfügbare Kapazität des Clusters für diese Ressource nicht überschreiten, um eine ordnungsgemäße Kontingentverwaltung zu gewährleisten. Wenn ein Cluster beispielsweise 20 ml.c5.2xlarge-Instances umfasst, sollte das den Teams zugewiesene Gesamtkontingent unter 20 bleiben.

Wenn die Richtlinien Rechenzuweisung für Teams Verleihen und Ausleihen oder Verleihen zulassen, wird die freie Kapazität zwischen diesen Teams geteilt. Beispielsweise haben Team A und Team B die Option Ausleihen und Verleihen aktiviert. Team A hat ein Kontingent von 6, nutzt aber nur 2 für seine Aufgaben, und Team B hat ein Kontingent von 5 und nutzt 4 für seine Aufgaben. Ein Job, der bei Team B eingereicht wird und 4 Ressourcen benötigt. 3 werden von Team A ausgeliehen.

Wenn die Compute-Zuweisungsrichtlinie eines Teams auf „Nicht leihen“ gesetzt ist, kann sich das Team keine zusätzliche Kapazität leihen, die über die eigenen Zuweisungen hinausgeht.

So funktioniert die gemeinsame Nutzung nicht zugewiesener Ressourcen

Durch die gemeinsame Nutzung nicht zugewiesener Ressourcen wird automatisch der Pool von Ressourcen verwaltet, die keinem Rechenkontingent in Ihrem Cluster zugewiesen sind. Das bedeutet, dass Ihr Clusterstatus HyperPod kontinuierlich überwacht und im Laufe der Zeit automatisch auf die richtige Konfiguration aktualisiert wird.

Ersteinrichtung

  • Wenn Sie dies Enabled in Ihrem festlegen IdleResourceSharing ClusterSchedulerConfig (standardmäßig ist dies der FallDisabled), beginnt HyperPod Task Governance mit der Überwachung Ihres Clusters und berechnet die verfügbaren ungenutzten Ressourcen, indem die Teamkontingente von der gesamten Knotenkapazität abgezogen werden.

  • Die gemeinsame Nutzung ClusterQueues nicht zugewiesener Ressourcen wird erstellt, um den ausleihbaren Ressourcenpool darzustellen.

  • Wenn Sie die gemeinsame Nutzung nicht zugewiesener Ressourcen zum ersten Mal aktivieren, dauert die Einrichtung der Infrastruktur mehrere Minuten. Sie können den Fortschritt anhand von Richtlinien Status und DetailedStatus in ClusterSchedulerConfig überwachen.

Kontinuierliche Versöhnung

  • HyperPod Task Governance überwacht kontinuierlich Änderungen wie das Hinzufügen oder Entfernen von Knoten und Aktualisierungen der Cluster-Warteschlangenkontingente.

  • Wenn Änderungen vorgenommen werden, werden bei der gemeinsamen Nutzung nicht zugewiesener Ressourcen das Kontingent und die Aktualisierungen neu berechnet. ClusterQueues Der Abgleich ist in der Regel innerhalb von Sekunden abgeschlossen.

Überwachung

Sie können überprüfen, ob die gemeinsame Nutzung nicht zugewiesener Ressourcen vollständig konfiguriert ist, indem Sie nach der gemeinsamen Nutzung nicht zugewiesener Ressourcen suchen: ClusterQueues 

kubectl get clusterqueue | grep hyperpod-ns-idle-resource-sharing

Wenn Sie Namen wie sehen ClusterQueues hyperpod-ns-idle-resource-sharing-cq-1, ist die gemeinsame Nutzung nicht zugewiesener Ressourcen aktiv. Beachten Sie, dass je nach Anzahl der Ressourcenvarianten in Ihrem Cluster mehrere nicht zugewiesene Ressourcen gemeinsam genutzt werden ClusterQueues können.

Eignung des Knotens für die gemeinsame Nutzung nicht zugewiesener Ressourcen

Die gemeinsame Nutzung nicht zugewiesener Ressourcen umfasst nur Knoten, die die folgenden Anforderungen erfüllen:

  1. Status „Knoten bereit“

    • Knoten müssen Ready den Status haben, dass sie zum nicht zugewiesenen Ressourcenpool beitragen können.

    • Knoten im Zustand NotReady oder in einem anderen Zustand, der nicht bereit ist, werden von der Kapazitätsberechnung ausgeschlossen.

    • Wenn ein Knoten zu einem Knoten wirdReady, wird er automatisch in den nächsten Abstimmungszyklus aufgenommen.

  2. Status des Knotens planbar

    • Knoten mit spec.unschedulable: true sind von der gemeinsamen Nutzung nicht zugewiesener Ressourcen ausgeschlossen.

    • Wenn ein Knoten wieder planbar ist, wird er automatisch in den nächsten Abstimmungszyklus aufgenommen.

  3. MIG-Konfiguration (nur GPU-Knoten)

    • Bei GPU-Knoten mit MIG-Partitionierung (Multi-Instance-GPU) muss die nvidia.com/mig.config.state Bezeichnung angezeigt success werden, damit der Knoten MIG-Profile zur gemeinsamen Nutzung nicht zugewiesener Ressourcen beitragen kann.

    • Diese Knoten werden automatisch erneut versucht, sobald die MIG-Konfiguration erfolgreich abgeschlossen wurde.

  4. Unterstützte Instance-Typen

    • Bei der Instanz muss es sich um einen unterstützten SageMaker HyperPod Instanztyp handeln.

    • Sehen Sie sich die Liste der unterstützten Instance-Typen im SageMaker HyperPod Cluster an.

Themen