View a markdown version of this page

Kontinuierliche Bereitstellung für erweiterte Clusteroperationen mit Slurm - Amazon SageMaker KI
FunktionsweisePrioritätsbasierte BereitstellungBehandlung von Controller-FehlernVoraussetzungenNutzungsmessungErstellen Sie einen Cluster mit aktivierter kontinuierlicher BereitstellungVerwaltung der Slurm-Konfiguration

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.

Kontinuierliche Bereitstellung für erweiterte Clusteroperationen mit Slurm

SageMaker HyperPod Amazon-Cluster, die mit Slurm-Orchestrierung erstellt wurden, unterstützen jetzt Continuous Provisioning, eine Funktion, die mehr Flexibilität und Effizienz bei der Ausführung großer Workloads ermöglicht. AI/ML Durch die kontinuierliche Bereitstellung können Sie schnell mit dem Training beginnen, nahtlos skalieren, Wartungsarbeiten ohne Betriebsunterbrechung durchführen und einen detaillierten Einblick in den Clusterbetrieb erhalten.

Anmerkung

Continuous Provisioning ist als optionale Konfiguration für neue HyperPod Cluster verfügbar, die mit Slurm-Orchestrierung erstellt wurden. Bestehende Cluster, die das vorherige Skalierungsmodell verwenden, können derzeit nicht auf Continuous Provisioning migriert werden.

Funktionsweise

Das Continuous Provisioning System führt eine Architektur mit gewünschtem Status ein, die das herkömmliche Skalierungsmodell ersetzt. all-or-nothing Wenn beim vorherigen Modell eine Instanzgruppe nicht vollständig bereitgestellt werden konnte, schlug der gesamte Vorgang zur Clustererstellung oder -aktualisierung fehl und wurde zurückgesetzt. Bei kontinuierlicher Bereitstellung akzeptiert das System Teilkapazität und stellt die verbleibenden Instanzen weiterhin asynchron bereit.

Das System zur kontinuierlichen Bereitstellung:

  • Akzeptiert die Anfrage: Zeichnet die Anzahl der Zielinstanzen für jede Instanzgruppe auf.

  • Initiiert die Bereitstellung: Beginnt mit dem parallel Start von Instanzen für alle Instanzgruppen.

  • Stellt zuerst Prioritätsknoten bereit: Der Cluster wechselt zu, InService nachdem mindestens ein Controller-Knoten (und ein Login-Node, falls eine Login-Instanzgruppe angegeben wurde) erfolgreich bereitgestellt wurde.

  • Verfolgt den Fortschritt: Überwacht jeden Instance-Startversuch und zeichnet den Status auf.

  • Behandelt Fehler: Wiederholt automatisch asynchron fehlgeschlagene Starts für Worker-Knoten.

Die kontinuierliche Bereitstellung ist standardmäßig deaktiviert. Um diese Funktion zu verwenden, stellen Sie Continuous in Ihrer NodeProvisioningMode CreateCluster Anfrage auf ein.

Wenn Continuous Provisioning aktiviert ist, können Sie mehrere Skalierungsvorgänge gleichzeitig initiieren, ohne auf den Abschluss früherer Operationen warten zu müssen. Auf diese Weise können Sie verschiedene Instance-Gruppen im selben Cluster gleichzeitig skalieren und mehrere Skalierungsanforderungen an dieselbe Instance-Gruppe senden.

Prioritätsbasierte Bereitstellung

Slurm-Cluster erfordern, dass ein Controller-Knoten betriebsbereit ist, bevor sich Worker-Knoten registrieren und Jobs annehmen können. Continuous Provisioning erledigt dies automatisch durch prioritätsbasiertes Provisioning:

  1. Die Controller-Instanzgruppe wird zuerst bereitgestellt.

  2. Sobald ein Controller-Knoten fehlerfrei ist, beginnen Anmelde- und Worker-Knoten parallel mit der Bereitstellung.

  3. Der Cluster wechselt zu dem InService Zeitpunkt, zu dem ein Controller-Knoten und ein Login-Node aktiv sind (sofern eine Login-Instanzgruppe angegeben ist). Wenn keine Login-Instanzgruppe angegeben ist, wechselt der Cluster zu, InService sobald der Controller-Knoten bereitgestellt ist.

  4. Worker-Knoten, die aufgrund von Kapazitätsbeschränkungen nicht sofort bereitgestellt werden können, treten in eine asynchrone Wiederholungsschleife ein und werden dem Slurm-Cluster automatisch hinzugefügt, sobald sie verfügbar sind.

Behandlung von Controller-Fehlern

Wenn der Controller-Knoten bei der Clustererstellung die Bereitstellung fehlschlägt, hängt das Verhalten davon ab, ob der Fehler erneut versucht werden kann oder nicht.

Fehler, die wiederholt werden können (z. B. fehlerhafte Instanzen oder vorübergehende Ausfälle):

  • HyperPod ersetzt kontinuierlich die Instanz und versucht erneut, sie bereitzustellen, bis der Controller wieder verfügbar ist.

  • Worker- und Login-Knoten, die bereits bereitgestellt wurden, bleiben verfügbar, aber der Cluster wechselt InService erst, wenn der Controller fehlerfrei ist.

Fehler, die nicht wiederholt werden können (z. B. keine verfügbare Kapazität für den Controller-Instanztyp oder Fehler im Lifecycle-Skript):

  • Der Cluster ist markiert als. Failed

  • Sie werden über die Ursache des Fehlers informiert und müssen Abhilfemaßnahmen ergreifen, z. B. einen anderen Instance-Typ wählen, Lebenszyklusskripts korrigieren oder es in einer anderen Availability Zone erneut versuchen.

Voraussetzungen

Kontinuierliches Provisioning erfordert, dass die Slurm-Bereitstellungsparameter (Knotentypen, Partitionsnamen) über die API-Payload im Feld jeder Instanzgruppe bereitgestellt werden. SlurmConfig Cluster, die auf der provisioning_parameters.json Legacy-Datei in Amazon S3 basieren, sind nicht mit Continuous Provisioning kompatibel.

Anmerkung

Die folgenden Funktionen werden derzeit bei der kontinuierlichen Bereitstellung auf Slurm-Clustern nicht unterstützt: Migration vorhandener Cluster, Konfiguration mehrerer Knoten über eine API-basierte Slurm-Topologie und. SlurmConfigStrategy Die kontinuierliche Bereitstellung erfolgt ausschließlich im Merge-Modus für die Verwaltung. slurm.conf

Nutzungsmessung

HyperPod Cluster mit kontinuierlicher Bereitstellung verwenden Metering auf Instanzebene, um eine genaue Abrechnung zu gewährleisten, die die tatsächliche Ressourcennutzung widerspiegelt. Dieser Zählungsansatz unterscheidet sich von der herkömmlichen Abrechnung auf Clusterebene dadurch, dass jede Instance unabhängig verfolgt wird.

Abrechnung auf Instance-Ebene

Bei kontinuierlicher Bereitstellung beginnt und endet die Abrechnung auf der Ebene der einzelnen Instances, anstatt auf Statusänderungen auf Clusterebene zu warten. Diese Methode bietet folgende Vorteile:

  • Präzise Rechnungsgenauigkeit: Die Abrechnung beginnt, wenn die Ausführung des Lifecycle-Skripts beginnt. Wenn das Lifecycle-Skript fehlschlägt, wird die Instance-Bereitstellung erneut versucht, und Ihnen wird die Dauer der Laufzeit des Lifecycle-Skripts in Rechnung gestellt.

  • Unabhängige Messung: Der Abrechnungszyklus jeder Instanz wird separat verwaltet, wodurch kaskadierende Abrechnungsfehler vermieden werden.

  • Abrechnungsupdates in Echtzeit: Die Abrechnung beginnt, wenn eine Instance mit der Ausführung ihres Lebenszyklus-Konfigurationsskripts beginnt, und endet, wenn die Instance in den Endzustand übergeht.

Lebenszyklus der Abrechnung

Jede Instance in Ihrem HyperPod Cluster folgt diesem Abrechnungszyklus:

  • Die Abrechnung beginnt: Wenn die Instance erfolgreich gestartet wird und mit der Ausführung ihres Lebenszyklus-Konfigurationsskripts beginnt.

  • Die Abrechnung wird fortgesetzt: Während der gesamten Betriebsdauer der Instance.

  • Die Abrechnung wird beendet: Wenn die Instance unabhängig vom Grund für die Kündigung in den Status „Beenden“ übergeht.

Anmerkung

Die Abrechnung für Instances, die nicht gestartet werden können, beginnt nicht. Wenn der Start einer Instance aufgrund unzureichender Kapazität oder anderer Probleme fehlschlägt, wird Ihnen dieser fehlgeschlagene Versuch nicht in Rechnung gestellt. Die Abrechnung wird auf Instance-Ebene berechnet und die Kosten werden zusammengefasst und unter dem Amazon-Ressourcennamen (ARN) Ihres Clusters gemeldet.

Erstellen Sie einen Cluster mit aktivierter kontinuierlicher Bereitstellung

Anmerkung

Bereiten Sie ein Lifecycle-Konfigurationsskript vor und laden Sie es in einen Amazon S3 S3-Bucket hoch, auf den Ihre Ausführungsrolle zugreifen kann. Weitere Informationen finden Sie unter SageMaker HyperPod Slurm-Clusteroperationen.

Bereiten Sie eine CreateCluster API-Anforderungsdatei im JSON-Format vor. Stellen NodeProvisioningMode Sie diese Option ein Continuous und geben Sie im Feld jeder Instanzgruppe Informationen zur Slurm-Topologie anSlurmConfig.

// create_cluster.json
{
    "ClusterName": "my-training-cluster",
    "NodeProvisioningMode": "Continuous",
    "Orchestrator": {
        "Slurm": {}
    },
    "InstanceGroups": [
        {
            "InstanceGroupName": "controller-group",
            "InstanceType": "ml.m5.xlarge",
            "InstanceCount": 1,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Controller"
            }
        },
        {
            "InstanceGroupName": "login-group",
            "InstanceType": "ml.m5.xlarge",
            "InstanceCount": 1,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Login"
            }
        },
        {
            "InstanceGroupName": "worker-gpu-a",
            "InstanceType": "ml.p5.48xlarge",
            "InstanceCount": 16,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Compute",
                "PartitionNames": ["gpu-training"]
            }
        }
    ],
    "VpcConfig": {
        "SecurityGroupIds": ["sg-12345678"],
        "Subnets": ["subnet-12345678"]
    }
}

Führen Sie den create-cluster Befehl aus, um die Anfrage einzureichen.

aws sagemaker create-cluster \
    --cli-input-json file://complete/path/to/create_cluster.json

Dies gibt den ARN des neuen Clusters zurück.

{
    "ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde12345"
}

Verwaltung der Slurm-Konfiguration

Die kontinuierliche Bereitstellung erfolgt ausschließlich im Merge-Modus für die slurm.conf Partitionsverwaltung. HyperPodWendet im Zusammenführungsmodus die Änderungen der Partitionskonfiguration zusätzlich zu den Änderungen an, an denen Sie Änderungen vorgenommen haben. slurm.conf HyperPod aktualisiert nur die partitionsbezogenen Abschnitte von slurm.conf (wie Partitionsnamen- und Knotennameneinträge); andere Slurm-Konfigurationsparameter werden nicht geändert. Das bedeutet Folgendes:

  • Ihre manuellen Änderungen an bleiben erhalten. slurm.conf

  • Es gibt keine automatische Erkennung von Abweichungen oder eine automatische Lösung von Konflikten zwischen Ihren Änderungen und HyperPod dem erwarteten Status.

Der SlurmConfigStrategy Parameter (Managed,Merge,Overwrite) wird bei kontinuierlicher Bereitstellung nicht unterstützt. Die Übergabe eines beliebigen SlurmConfigStrategy Werts führt zu einem API-Fehler.