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 Cluster-Operationen auf Amazon EKS
SageMaker HyperPod Amazon-Cluster, die mit Amazon EKS-Orchestration erstellt wurden, unterstützen jetzt Continuous Provisioning, eine neue Funktion, die mehr Flexibilität und Effizienz bei der Ausführung AI/ML umfangreicher Workloads ermöglicht. Mit Continuous Provisioning können Sie schnell mit dem Training beginnen, nahtlos skalieren, Wartungsarbeiten ohne Betriebsunterbrechung durchführen und einen detaillierten Einblick in den Clusterbetrieb haben.
Anmerkung
Continuous Provisioning ist für HyperPod Cluster verfügbar, die mit EKS-Orchestrierung erstellt wurden. Mit Slurm-Orchestrierung erstellte Cluster verwenden ein anderes Skalierungsmodell.
Funktionsweise
Continuous Provisioning basiert auf einer ereignisgesteuerten Architektur, die jede Instanz unabhängig verwaltet. Wenn Sie einen HyperPod Cluster erstellen, geben Sie die gewünschte Anzahl von Instanzen für jede Instanzgruppe an. Das System zur kontinuierlichen Bereitstellung:
-
Akzeptiert die Anfrage: Zeichnet die Anzahl der Zielinstanzen für jede Instanzgruppe auf
-
Initiiert die Bereitstellung: Beginnt mit dem Starten von Instanzen, um die Zielanzahl zu erreichen
Verfolgt den Fortschritt: Überwacht jeden Instance-Startversuch und zeichnet den Status auf
-
Behandelt Fehler: Wiederholt automatisch fehlgeschlagene Starts
Continuous Provisioning ist standardmäßig deaktiviert. Um diese Funktion zu verwenden, stellen Sie --node-provisioning-mode
auf Continuous
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 Instanzgruppen im selben Cluster gleichzeitig skalieren und mehrere Skalierungsanforderungen an dieselbe Instanzgruppe senden.
Durch die kontinuierliche Bereitstellung erhalten Sie außerdem Zugriff auf DescribeClusterEventund ListClusterEventfür eine detaillierte Ereignisüberwachung und betriebliche Transparenz.
Messung der Nutzung
HyperPod Cluster mit kontinuierlicher Bereitstellung verwenden die Messung 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 Instanz unabhängig verfolgt wird.
Abrechnung auf Instanzebene
Bei kontinuierlicher Bereitstellung beginnt und endet die Abrechnung auf der Ebene der einzelnen Instanzen, anstatt auf Statusänderungen auf Clusterebene zu warten. Dieser Ansatz bietet die folgenden Vorteile:
-
Präzise Abrechnungsgenauigkeit: 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 Lifecycle-Skripts beginnt, und endet, wenn die Instance in den Endzustand übergeht
Lebenszyklus der Abrechnung
Jede Instanz in Ihrem HyperPod Cluster folgt diesem Abrechnungszyklus:
-
Die Abrechnung beginnt: Wenn die Instance erfolgreich gestartet wurde 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 aggregiert und unter dem Amazon-Ressourcennamen (ARN) Ihres Clusters gemeldet.
Erstellen Sie einen Cluster mit aktivierter kontinuierlicher Bereitstellung
Anmerkung
Sie müssen einen vorhandenen Amazon EKS-Cluster mit VPC-Netzwerk konfiguriert und das erforderliche Helm-Diagramm installiert haben. Bereiten Sie außerdem ein Lifecycle-Konfigurationsskript vor und laden Sie es in einen Amazon S3 S3-Bucket hoch, auf den Ihre Ausführungsrolle zugreifen kann.
Der folgende AWS CLI Vorgang erstellt einen HyperPod Cluster mit einer Instance-Gruppe und aktivierter kontinuierlicher Bereitstellung.
aws sagemaker-dev create-cluster \ --cluster-name $HP_CLUSTER_NAME \ --orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \ --vpc-config '{ "SecurityGroupIds": ["'$SECURITY_GROUP'"], "Subnets": ["'$SUBNET'"] }' \ --instance-groups '{ "InstanceGroupName": "ig-1", "InstanceType": "ml.c5.2xlarge", "InstanceCount": 2, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create_noop.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'", "ThreadsPerCore": 1, "TrainingPlanArn": "" }' \ --node-provisioning-mode Continuous // Expected Output: { "ClusterArn": "arn:aws:sagemaker:us-west-2:<account-id>:cluster/<cluster-id>" }
Nachdem Sie Ihren Cluster erstellt haben, können Sie ListClusterNodesoder verwenden, DescribeClusterNodeum weitere Informationen über die Knoten im Cluster zu erhalten.
Beim Aufrufen dieser Operationen wird ein ClusterInstanceStatusDetailsObjekt mit einem der folgenden Werte zurückgegeben:
-
Wird ausgeführt: Der Knoten ist fehlerfrei und beim Cluster-Orchestrator (EKS) registriert.
-
Fehler: Die Bereitstellung des Knotens ist fehlgeschlagen, aber das System versucht automatisch, die Bereitstellung mit einer neuen Instanz zu wiederholen. EC2
-
Ausstehend: Der Knoten wird bereitgestellt oder neu gestartet.
-
ShuttingDown: Die Knotenbeendigung ist im Gange. Der Knoten wechselt entweder in den Status Fehler, wenn bei der Kündigung Probleme auftreten, oder er wird erfolgreich aus dem Cluster entfernt.
-
SystemUpdating: Der Knoten wird gerade einem AMI-Patching unterzogen, das entweder manuell oder im Rahmen von Patching-Cronjobs ausgelöst wird.
-
DeepHealthCheckInProgress: Es werden tiefgreifende Integritätsprüfungen (DHCs) durchgeführt. Dies kann je nach Art der Tests zwischen einigen Minuten und mehreren Stunden dauern. Fehlerhafte Knoten werden ersetzt und gesunde Knoten werden in den Status Running umgeschaltet.
-
NotFound: Wird BatchAddClusterNodesals Reaktion darauf verwendet, dass ein Knoten während der idempotenten Wiedergabe gelöscht wurde.