View a markdown version of this page

Kontinuierliche Bereitstellung für erweiterte Cluster-Operationen auf Amazon EKS - Amazon SageMaker KI

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 der Amazon EKS-Orchestrierung 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. 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 EKS-Orchestrierung erstellt wurden. HyperPod Cluster, die mit der Slurm-Orchestrierung erstellt wurden, unterstützen auch die kontinuierliche Bereitstellung. Details hierzu finden Sie unter Kontinuierliche Bereitstellung für einen verbesserten Cluster-Betrieb mit Slurm.

Funktionsweise

Das Continuous Provisioning System führt eine Architektur mit gewünschtem Status ein, die das traditionelle, auf Anfragen basierende Modell ersetzt. Diese neue Architektur ermöglicht parallel, blockierungsfreie Operationen auf verschiedenen Ressourcenebenen unter Beibehaltung der Systemstabilität und -leistung. Das System zur kontinuierlichen Bereitstellung:

  • Akzeptiert die Anfrage: Zeichnet die Anzahl der ZielInstances für jede Instance-Gruppe auf

  • Initiiert die Bereitstellung: Beginnt mit dem Starten von Instances, um die Zielanzahl zu erreichen

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

  • Behandelt Fehler: Wiederholt automatisch fehlgeschlagene Starts

Die kontinuierliche Bereitstellung 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 Instance-Gruppen im selben Cluster gleichzeitig skalieren und mehrere Skalierungsanforderungen an dieselbe Instance-Gruppe senden.

Durch die kontinuierliche Bereitstellung erhalten Sie auch Zugriff auf DescribeClusterEvent und ListClusterEvent für eine detaillierte Ereignisüberwachung und betriebliche Transparenz.

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 Messung: Der Abrechnungszyklus jeder Instance wird separat verwaltet, wodurch kaskadierende Abrechnungsfehler vermieden werden

  • Real-time Abrechnungsaktualisierungen: Die Abrechnung beginnt, wenn eine Instanz mit der Ausführung ihres Lifecycle-Skripts beginnt, und endet, wenn die Instanz in den Status „Beenden“ ü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 zusammengefasst und unter dem Amazon-Ressourcennamen (ARN) Ihres Clusters gemeldet.

Erstellen Sie einen Cluster mit aktivierter kontinuierlicher Bereitstellung

Anmerkung

Sie müssen einen Amazon-EKS-Cluster mit VPC-Netzwerk konfiguriert und das erforderliche Helm-Diagramm installiert haben. Erstellen Sie außerdem ein Skript für die Lebenszykluskonfiguration und laden Sie es in einen Amazon-S3-Bucket hoch, auf den Ihre Ausführungsrolle zugreifen kann. Weitere Informationen finden Sie unter Verwaltung von SageMaker HyperPod Clustern, die von Amazon EKS orchestriert werden.

Der folgende AWS CLI Vorgang erstellt einen HyperPod Cluster mit einer Instanzgruppe und aktivierter kontinuierlicher Bereitstellung.

aws sagemaker 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 ListClusterNodes oder verwenden, DescribeClusterNode um weitere Informationen über die Knoten im Cluster zu erhalten.

Beim Aufrufen dieser Operationen wird ein ClusterInstanceStatusDetails Objekt 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 EC2-Instance zu wiederholen.

  • Ausstehend: Der Knoten wird bereitgestellt oder neu gestartet.

  • ShuttingDown: Die Knotenbeendigung ist im Gange. Der Knoten wechselt entweder in den Status Fehlgeschlagen, wenn bei der Terminierung Probleme auftreten, oder er wird erfolgreich aus dem Cluster entfernt.

  • SystemUpdating: Für den Knoten wird derzeit ein AMI-Patching durchgeführt, das entweder manuell oder im Rahmen des Patchens von Cronjobs ausgelöst wird.

  • DeepHealthCheckInProgress: Es werden gründliche Gesundheitschecks (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 BatchAddClusterNodes als Antwort verwendet, um anzuzeigen, dass ein Knoten während einer idempotenten Wiedergabe gelöscht wurde.

Mindestanforderungen an die Kapazität () 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 wirdInService. 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 zuInService.

  • 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.

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 wieBatchAddClusterNodes,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 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 \ --orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \ --vpc-config '{ "SecurityGroupIds": ["'$SECURITY_GROUP'"], "Subnets": ["'$SUBNET'"] }' \ --instance-groups '{ "InstanceGroupName": "worker-group", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 64, "MinInstanceCount": 50, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'" }' \ --node-provisioning-mode Continuous

Wichtige Überlegungen zur MinCount Verwendung:

  • MinInstanceCountmuss zwischen 0 und dem InstanceCount (einschließlich) Wert der Instanzgruppe liegen, die in unserer CreateCluster UpdateCluster Anfrage angegeben ist

  • Bei Einstellung MinInstanceCount auf 0 (Standard) bleibt das standardmäßige kontinuierliche Skalierungsverhalten erhalten

  • Die Einstellung „MinInstanceCountGleich“ InstanceCount sorgt für ein Alles-oder-Nichts-Skalierungsverhalten

  • MinCount ist nur für Cluster mit dem NodeProvisioningMode Wert auf verfügbar Continuous

Flexible Instanzgruppen

Mit flexiblen Instanzgruppen können Sie mehrere Instanztypen innerhalb einer einzelnen Instanzgruppe angeben. Dies vereinfacht die Clusterverwaltung, indem die Anzahl der Instanzgruppen, die Sie erstellen und verwalten müssen, reduziert wird, insbesondere für Inferenz-Workloads, die Autoscaling verwenden.

Mit flexiblen Instanzgruppen: HyperPod

  • Versucht, Instanzen mithilfe des ersten Instanztyps in Ihrer Liste bereitzustellen

  • Falls die Kapazität nicht verfügbar ist, wird auf nachfolgende Instanztypen zurückgegriffen

  • Beendet beim Herunterskalieren zuerst Instanzen des Instanztyps mit der niedrigsten Priorität

Anmerkung

Flexible Instanzgruppen sind nur für Cluster mit der Einstellung auf verfügbar. NodeProvisioningMode Continuous Die InstanceRequirements Eigenschaften InstanceType und schließen sich gegenseitig aus. Sie können das eine oder das andere angeben, aber nicht beide.

Erstellen Sie einen Cluster mit einer flexiblen Instanzgruppe

Verwenden Sie InstanceRequirements stattInstanceType, um eine flexible Instanzgruppe zu erstellen. Die Reihenfolge der Instanztypen in der Liste bestimmt die Priorität der Bereitstellung.

aws sagemaker create-cluster \ --cluster-name $HP_CLUSTER_NAME \ --orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \ --vpc-config '{ "SecurityGroupIds": ["'$SECURITY_GROUP'"], "Subnets": ["'$SUBNET_AZ1'", "'$SUBNET_AZ2'"] }' \ --instance-groups '[{ "InstanceGroupName": "flexible-ig", "InstanceRequirements": { "InstanceTypes": ["ml.p5.48xlarge", "ml.p4d.24xlarge", "ml.g6.48xlarge"] }, "InstanceCount": 10, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'" }]' \ --node-provisioning-mode Continuous

Gezielte Skalierung mit BatchAddClusterNodes

Wenn Sie flexible Instanzgruppen verwenden, können Sie BatchAddClusterNodes sie verwenden, um Knoten mit bestimmten Instanztypen und Verfügbarkeitszonen hinzuzufügen. Dies ist besonders nützlich, wenn Karpenter Autoscaling den optimalen Instanztyp und die optimale Verfügbarkeitszone für Ihre Arbeitslast bestimmt.

aws sagemaker batch-add-cluster-nodes \ --cluster-name $HP_CLUSTER_NAME \ --nodes-to-add '[ { "InstanceGroupName": "flexible-ig", "IncrementTargetCountBy": 1, "InstanceTypes": ["ml.p5.48xlarge"], "AvailabilityZones": ["us-west-2a"] } ]'

Details zu flexiblen Instanzgruppen anzeigen

Verwenden Sie diese DescribeCluster Option, um die Instanztypen und die Aufschlüsselung Ihrer flexiblen Instanzgruppe nach Typen anzuzeigen. Die Antwort enthält:

  • InstanceRequirements— Der aktuelle und der gewünschte Instanztyp für die Instanzgruppe

  • InstanceTypeDetails— Eine Aufschlüsselung pro Instanztyp, die die Anzahl und Konfiguration der einzelnen Instanztypen in der Gruppe zeigt

Verwendung flexibler Instanzgruppen mit Karpenter Autoscaling

Flexible Instanzgruppen lassen sich in das verwaltete Karpenter HyperPod Autoscaling integrieren. Weitere Informationen zur Einrichtung von Karpenter finden Sie unter. Autoscaling auf EKS SageMaker HyperPod Wenn Sie in einer HyperPodNodeClass Konfiguration auf eine flexible Instanzgruppe verweisen, geht Karpenter automatisch wie folgt vor:

  • Erkennt die unterstützten Instanztypen aus der flexiblen Instanzgruppe

  • Wählt den optimalen Instanztyp und die optimale Verfügbarkeitszone auf der Grundlage der Pod-Anforderungen und der Preisgestaltung aus

  • Skaliert die flexible Instanzgruppe mithilfe gezielter BatchAddClusterNodes Aufrufe mit dem ausgewählten Instanztyp und der ausgewählten Verfügbarkeitszone

Anmerkung

Wenn Karpenter die Skalierung verwaltet, verwendet es seine eigene Auswahllogik, die auf den Pod-Anforderungen und der Preisgestaltung basiert, um zu bestimmen, welcher Instanztyp bereitgestellt werden soll. Dies unterscheidet sich von der Priorität in der Listenreihenfolge, die beim nativen Provisioning verwendet wird (z. B. CreateCluster undUpdateCluster), bei dem der erste Instanztyp in der Liste immer zuerst versucht wird. HyperPod

Dadurch entfällt die Notwendigkeit, separate Instanzgruppen für jeden Instanztyp zu erstellen und Karpenter manuell so zu konfigurieren, dass es auf mehrere Gruppen verweist.