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 einen verbesserten Cluster-Betrieb mit Slurm SageMaker HyperPod Amazon-Cluster, die mit der Slurm-Orchestrierung erstellt wurden, unterstützen jetzt die kontinuierliche Bereitstellung, eine Funktion, die mehr Flexibilität und Effizienz bei der Ausführung umfangreicher 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 HyperPod Cluster verfügbar, die mit Slurm-Orchestrierung erstellt wurden. ## Funktionsweise Das Continuous Provisioning System führt eine Desired-State-Architektur ein, die das traditionelle Alles-oder-Nichts-Skalierungsmodell ersetzt. Wenn im vorherigen Modell eine Instanzgruppe nicht vollständig bereitgestellt werden konnte, schlug der gesamte Vorgang zur Clustererstellung oder -aktualisierung fehl und es wurde ein Rollback durchgeführt. Bei der kontinuierlichen 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 parallelen Starten von Instances für alle Instanzgruppen. + **Stellt zuerst Prioritätsknoten ** bereit: Der Cluster wechselt zum Cluster, `InService` nachdem mindestens ein Controller-Knoten (und ein Anmeldeknoten, falls eine Anmelde-Instanzgruppe angegeben ist) erfolgreich bereitgestellt wurde. + **Verfolgt den Fortschritt**: Überwacht jeden Versuch, eine Instanz zu starten, und zeichnet den Status auf. + **Behandelt Fehler**: Wiederholt automatisch und asynchron fehlgeschlagene Starts für Worker-Knoten. Die kontinuierliche Bereitstellung ist standardmäßig deaktiviert. Um diese Funktion zu verwenden, setzen Sie `Continuous` in Ihrer `NodeProvisioningMode` Anfrage auf. `CreateCluster` 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. ## Priority-based Bereitstellung Slurm-Cluster benötigen einen Controller-Knoten, um betriebsbereit zu sein, bevor Worker-Knoten Jobs registrieren und annehmen können. Continuous Provisioning erledigt dies automatisch durch prioritätsbasierte Bereitstellung: 1. Die Controller-Instanzgruppe wird zuerst bereitgestellt. 1. Sobald ein Controller-Knoten fehlerfrei ist, beginnen Anmelde- und Worker-Knoten parallel mit der Bereitstellung. 1. Der Cluster wechselt in den `InService` Zustand, in dem ein Controller-Knoten aktiv ist und ein Login-Knoten aktiv ist (sofern eine Login-Instanzgruppe angegeben ist). Wenn keine Login-Instanzgruppe angegeben ist, wechselt der Cluster zu `InService` diesem, sobald der Controller-Knoten bereitgestellt ist. 1. 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-Ausfällen Wenn der Controller-Knoten bei der Clustererstellung nicht bereitgestellt werden kann, hängt das Verhalten davon ab, ob der Fehler wiederholt werden kann oder nicht. **Wiederholbare Fehler ** (z. B. fehlerhafte Instanz oder vorübergehende Ausfälle): + HyperPod ersetzt kontinuierlich die Instanz und versucht erneut, sie bereitzustellen, bis der Controller aktiviert wird. + Worker- und Anmeldeknoten, die bereits bereitgestellt wurden, bleiben verfügbar, aber der Cluster wechselt `InService` erst, wenn der Controller fehlerfrei ist. **Non-retryable Fehler ** (z. B. keine verfügbare Kapazität für den Controller-Instanztyp oder Ausfall des Lifecycle-Skripts): + Der Cluster ist markiert als`Failed`. + Sie werden über den Grund des Fehlers informiert und müssen Abhilfemaßnahmen ergreifen, z. B. einen anderen Instanztyp auswählen, Lebenszyklus-Skripts korrigieren oder es in einer anderen Availability Zone erneut versuchen. ## Voraussetzungen Für die kontinuierliche Bereitstellung müssen 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 mit der kontinuierlichen Bereitstellung nicht kompatibel. **Anmerkung** Die folgenden Funktionen werden derzeit bei der kontinuierlichen Bereitstellung auf Slurm-Clustern nicht unterstützt: Mehrkopf-Knotenkonfiguration über die API-based Slurm-Topologie und. `SlurmConfigStrategy` Continuous Provisioning funktioniert ausschließlich im Merge-Modus für die Verwaltung. `slurm.conf` ## Nutzungsmessung HyperPod Cluster mit kontinuierlicher Bereitstellung verwenden Zähler auf Instanzebene, um eine genaue Abrechnung zu gewährleisten, die der tatsächlichen Ressourcennutzung entspricht. Dieser Zählungsansatz unterscheidet sich von der herkömmlichen Abrechnung auf Clusterebene dadurch, dass jede Instance unabhängig verfolgt wird. **Instance-level Fakturierung** 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 Erfassung**: Der Abrechnungszyklus jeder Instanz wird separat verwaltet, sodass kaskadierende Abrechnungsfehler vermieden werden. + **Real-time Abrechnungsaktualisierungen**: Die Abrechnung beginnt, wenn eine Instanz mit der Ausführung ihres Lebenszyklus-Konfigurationsskripts beginnt, und endet, wenn die Instanz in den Endzustand übergeht. **Lebenszyklus der Abrechnung** Jede Instanz in Ihrem HyperPod Cluster folgt diesem Abrechnungszyklus: + **Die Abrechnung beginnt**: Wenn die Instanz erfolgreich gestartet wurde und mit der Ausführung ihres Lebenszyklus-Konfigurationsskripts beginnt. + **Die Abrechnung wird fortgesetzt**: Während der gesamten Betriebsdauer der Instanz. + **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-Bucket hoch, auf den Ihre Ausführungsrolle zugreifen kann. Weitere Informationen finden Sie unter [SageMaker HyperPod Betrieb des Slurm-Clusters](sagemaker-hyperpod-operate-slurm.md). Bereiten Sie eine `CreateCluster` API-Anforderungsdatei im JSON-Format vor. Stellen Sie `NodeProvisioningMode` diese Option auf ein `Continuous` und geben Sie Informationen zur Slurm-Topologie in den Feldern jeder Instanzgruppe an`SlurmConfig`. ``` // 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 zu senden. ``` 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" } ``` ## Slurm-Konfigurationsverwaltung Continuous Provisioning funktioniert ausschließlich im Merge-Modus für die `slurm.conf` Partitionsverwaltung. HyperPodWendet im Zusammenführungsmodus die Änderungen an der Partitionskonfiguration zusätzlich zu den Änderungen an, die Sie 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 werden beibehalten. `slurm.conf` + Es gibt keine automatische Erkennung von Abweichungen oder die Lösung von Konflikten zwischen Ihren Änderungen und HyperPod dem erwarteten Zustand. Der `SlurmConfigStrategy` Parameter (`Managed`,`Merge`,`Overwrite`) wird bei der kontinuierlichen Bereitstellung nicht unterstützt. Die Übergabe eines beliebigen `SlurmConfigStrategy` Werts führt zu einem API-Fehler. ## Mindestkapazitätsanforderungen (MinCount) Mit dieser MinCount Funktion können Sie die Mindestanzahl von Instanzen angeben, die erfolgreich bereitgestellt werden müssen, bevor eine Instanzgruppe in den `InService` Status übergeht. Diese Funktion bietet eine bessere Kontrolle über Skalierungsvorgänge und hilft, Szenarien zu verhindern, in denen teilweise bereitgestellte Instanzgruppen nicht effektiv für das Training von Workloads verwendet werden können. **Wichtig** MinCount ist keine dauerhafte Garantie für eine Mindestkapazität. Es stellt nur sicher, dass die angegebene Mindestanzahl an Instances verfügbar ist, wenn die Instanzgruppe zum ersten Mal hinzugefügt wird`InService`. Bei normalem Betrieb, wie z. B. beim Austausch fehlerhafter Instanzen oder bei Wartungsarbeiten, MinCount kann es zu kurzen Unterschreitungen kommen. ### MinCount Wie funktioniert Wenn Sie eine Instanzgruppe mit MinCount aktivierter Option erstellen oder aktualisieren, tritt das folgende Verhalten auf: + **Neue Instanzgruppen**: Die Instanzgruppe behält `Creating` ihren Status, bis mindestens MinCount Instanzen erfolgreich bereitgestellt und bereit sind. Sobald dieser Schwellenwert erreicht ist, wechselt die Instanzgruppe zu`InService`. + **Bestehende Instanzgruppen**: Wenn eine bestehende Instanzgruppe aktualisiert MinCount wird, ändert sich der Status so lange, `Updating` bis die neue MinCount Anforderung erfüllt ist. + **Kontinuierliche Skalierung**: Wenn größer als TargetCount ist MinCount, versucht das System für kontinuierliche Skalierung so lange, weitere Instances zu starten, bis dieser TargetCount Wert erreicht ist. + **Timeout und Rollback**: Wenn MinCount nicht innerhalb von 3 Stunden erreicht werden kann, setzt das System die Instanzgruppe automatisch auf den letzten als funktionierend bekannten Zustand zurück. Weitere Informationen zum Rollback-Verhalten finden Sie unter [ Automatisches Rollback-Verhalten. ](#sagemaker-hyperpod-scaling-slurm-mincount-rollback) ### Status der Instanzgruppe während des Betriebs MinCount Instanzgruppen mit MinCount konfigurierter Konfiguration weisen das folgende Statusverhalten auf: Erstellen Für neue Instanzgruppen, wenn CurrentCount < MinCount. Die Instanzgruppe verbleibt in diesem Status, bis die Mindestkapazitätsanforderung erfüllt ist. Aktualisieren Für bestehende Instanzgruppen wann MinCount wird geändert und CurrentCount < MinCount. Die Instanzgruppe verbleibt in diesem Status, bis die neue Mindestkapazitätsanforderung erfüllt ist. InService Wenn MinCount ≤ CurrentCount ≤ TargetCount. Die Instanzgruppe ist einsatzbereit und alle mutierenden Operationen werden entsperrt. Während `Creating` unseres `Updating` Status gelten die folgenden Einschränkungen: + Mutierende Operationen wie`BatchAddClusterNodes`,`BatchDeleteClusterNodes`, oder `UpdateClusterSoftware` werden blockiert + Sie können die TargetCount Werte trotzdem ändern MinCount , um Konfigurationsfehler zu korrigieren + Das Löschen von Clustern und Instanzgruppen ist immer zulässig ### Automatisches Rollback-Verhalten Wenn eine Instanzgruppe ihren Wert nicht MinCount innerhalb von 3 Stunden erreicht, leitet das System automatisch ein Rollback ein, um ein unbegrenztes Warten zu verhindern: + **Neue Instanzgruppen**: MinCount und TargetCount werden auf (0, 0) zurückgesetzt + **Bestehende Instanzgruppen**: MinCount und TargetCount werden auf ihre Werte aus dem letzten `InService` Status zurückgesetzt + **Instanzauswahl für die Kündigung**: Wenn Instanzen während des Rollbacks beendet werden müssen, wählt das System zuerst die instabilen Instanzen aus, dann die, die zuletzt bereitgestellt wurden. + **Statusübergang**: Die Instanzgruppe geht nach der Initiierung des Rollbacks sofort in `InService` den Status über, sodass das System für kontinuierliche Skalierung die Kapazität gemäß den Rollback-Einstellungen verwalten kann Das 3-stündige Timeout wird bei jeder Aktualisierung zurückgesetzt. MinCount Wenn Sie beispielsweise MinCount mehrmals aktualisieren, beginnt der Timeout-Zeitraum mit dem letzten Update neu. ### MinCount Ereignisse Das System gibt bestimmte Ereignisse aus, um Ihnen bei der Verfolgung von MinCount Vorgängen zu helfen: + **Mindestkapazität erreicht**: Wird ausgegeben, wenn eine Instanzgruppe erfolgreich ihre Kapazität erreicht MinCount und zu `InService` + **Rollback eingeleitet**: Wird ausgelöst, wenn das 3-stündige Timeout abläuft und das automatische Rollback beginnt Sie können diese Ereignisse überwachen, indem Sie [ ListClusterEvents ](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusterEvents.html) den Fortschritt Ihrer Operationen verfolgen. MinCount ### Nutzung der API MinCount wird mithilfe des `MinInstanceCount` Parameters in Instanzgruppenkonfigurationen angegeben: ``` aws sagemaker create-cluster \ --cluster-name $HP_CLUSTER_NAME \ --instance-groups '[ { "InstanceGroupName": "controller-machine", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "SlurmConfig": {"NodeType": "Controller"}, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'", "ThreadsPerCore": 2 }, { "InstanceGroupName": "my-login-group", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "SlurmConfig": {"NodeType": "Login"}, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'", "ThreadsPerCore": 1 }, { "InstanceGroupName": "worker-group-1", "InstanceType": "ml.c5.xlarge", "MinInstanceCount": 1, "InstanceCount": 2, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["p1"] }, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'", "ThreadsPerCore": 1 } ]' \ --vpc-config '{ "SecurityGroupIds": ["'$SECURITY_GROUP'"], "Subnets": ["'$SUBNET'"] }' \ --node-provisioning-mode Continuous ``` Wichtige Überlegungen zur MinCount Verwendung: + `MinInstanceCount`muss zwischen 0 und dem `InstanceCount` (einschließlich) Wert der Instanzgruppe liegen, die in unserer [ CreateCluster ](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html) [ UpdateCluster ](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html) Anfrage angegeben ist + Bei Einstellung `MinInstanceCount` auf 0 (Standard) bleibt das standardmäßige kontinuierliche Skalierungsverhalten erhalten + Die Standardeinstellung `MinInstanceCount` für Controller und Anmeldung InstanceGroup ist bei der Clustererstellung auf 1 gesetzt + Die Einstellung „`MinInstanceCount`Gleich“ `InstanceCount` bietet ein Alles-oder-Nichts-Skalierungsverhalten + MinCount ist nur für Cluster mit dem `NodeProvisioningMode` Wert auf verfügbar `Continuous`