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. # Anpassen von SageMaker HyperPod Clustern mithilfe von Lifecycle-Skripten SageMaker HyperPod bietet up-and-running Always-Compute-Cluster, die in hohem Maße anpassbar sind, da Sie Lebenszyklus-Skripte schreiben können, die angeben, SageMaker HyperPod wie die Cluster-Ressourcen eingerichtet werden. Die folgenden Themen enthalten bewährte Methoden für die Vorbereitung von Lebenszyklusskripten für die Einrichtung von SageMaker HyperPod Clustern mit Open-Source-Workload-Manager-Tools. In den folgenden Themen werden ausführliche bewährte Methoden für die Vorbereitung von Lifecycle-Skripten für die Einrichtung von Slurm-Konfigurationen erörtert. SageMaker HyperPod ## Allgemeine Übersicht Das folgende Verfahren ist der Hauptablauf für die Bereitstellung eines HyperPod Clusters und dessen Einrichtung mit Slurm. Die Schritte werden dabei ***von unten nach oben*** angeordnet. 1. Planen Sie, wie Sie Slurm-Knoten auf einem Cluster erstellen möchten. HyperPod Wenn Sie beispielsweise zwei Slurm-Knoten konfigurieren möchten, müssen Sie zwei Instanzgruppen in einem HyperPod Cluster einrichten. 1. Bereiten Sie die Slurm-Konfiguration vor. Wählen Sie einen der folgenden Ansätze: + **Option A: API-gesteuerte Konfiguration (empfohlen)** — Definieren Sie Slurm-Knotentypen und -partitionen direkt in der `CreateCluster` API-Payload und verwenden Sie sie `SlurmConfig` innerhalb jeder Instanzgruppe. Mit diesem Ansatz: + Es wird keine `provisioning_parameters.json` Datei benötigt + Die Slurm-Topologie ist in der API-Nutzlast zusammen mit den Definitionen der Instanzgruppen definiert + FSx Dateisysteme werden konfiguriert über per-instance-group `InstanceStorageConfigs` + Die Konfigurationsstrategie wird gesteuert über `Orchestrator.Slurm.SlurmConfigStrategy` Beispiel `SlurmConfig` in einer Instanzgruppe: ``` { "InstanceGroupName": "gpu-compute", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 8, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["gpu-training"] } } ``` + **Option B: Legacy-Konfiguration** — Bereiten Sie eine `provisioning_parameters.json` Datei vor, bei der es sich um eine[Konfigurationsformular für provisioning\$1parameters.json](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm). `provisioning_parameters.json`sollte Informationen zur Konfiguration des Slurm-Knotens enthalten, der HyperPod auf dem Cluster bereitgestellt werden soll. Dies sollte das Design der Slurm-Knotens aus Schritt 1 widerspiegeln. 1. Bereiten Sie eine Reihe von Lifecycle-Skripten vor, auf denen Slurm eingerichtet werden HyperPod soll, um Softwarepakete zu installieren und eine Umgebung im Cluster für Ihren Anwendungsfall einzurichten. Sie sollten die Lebenszyklusskripte so strukturieren, dass sie gemeinsam in einem zentralen Python-Skript (`lifecycle_script.py`) ausgeführt werden, und ein Einstiegspunkt-Shell-Skript (`on_create.sh`) schreiben, um das Python-Skript auszuführen. Das Entrypoint-Shell-Skript müssen Sie später in Schritt 5 für eine Anfrage zur HyperPod Clustererstellung bereitstellen. Beachten Sie außerdem, dass Sie beim Schreiben der Skripts davon ausgehen sollten`resource_config.json`, dass sie HyperPod bei der Clustererstellung generiert werden. `resource_config.json`enthält HyperPod Cluster-Ressourceninformationen wie IP-Adressen, Instanztypen und, und ist genau das ARNs, was Sie für die Konfiguration von Slurm verwenden müssen. 1. Sammeln Sie alle Dateien aus den vorherigen Schritten in einem Ordner. Die Ordnerstruktur hängt vom Konfigurationsansatz ab, den Sie in Schritt 2 ausgewählt haben. Wenn Sie Option A (API-gesteuerte Konfiguration) ausgewählt haben: Ihr Ordner benötigt nur Lebenszyklusskripts für benutzerdefinierte Einrichtungsaufgaben. Die Konfiguration und FSx das Mounten von Slurm werden automatisch auf der HyperPod Grundlage der API-Payload durchgeführt. ``` └── lifecycle_files // your local folder ├── on_create.sh ├── lifecycle_script.py └── ... // more setup scripts to be fed into lifecycle_script.py ``` **Anmerkung** Die `provisioning_parameters.json` Datei ist bei Verwendung einer API-gesteuerten Konfiguration nicht erforderlich. Wenn Sie Option B (Legacy-Konfiguration) ausgewählt haben: Ihr Ordner muss den vollständigen Satz von Lebenszyklus-Skripten enthalten`provisioning_parameters.json`. ``` └── lifecycle_files // your local folder ├── provisioning_parameters.json ├── on_create.sh ├── lifecycle_script.py └── ... // more setup scrips to be fed into lifecycle_script.py ``` 1. Laden Sie alle Dateien in einen S3-Bucket hoch. Kopieren Sie den S3-Bucket-Pfad und behalten Sie ihn. Beachten Sie, dass Sie einen S3-Bucket-Pfad erstellen sollten, der mit `sagemaker-` beginnt, da Sie eine [IAM-Rolle für SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) auswählen müssen, an die [`AmazonSageMakerClusterInstanceRolePolicy`](security-iam-awsmanpol-AmazonSageMakerClusterInstanceRolePolicy.md) angefügt ist, wodurch nur S3-Bucket-Pfade zulässig sind, die mit dem Präfix `sagemaker-` beginnen. Der folgende Befehl ist ein Beispielbefehl zum Hochladen aller Dateien in einen S3-Bucket. ``` aws s3 cp --recursive ./lifecycle_files s3://sagemaker-hyperpod-lifecycle/src ``` 1. Bereiten Sie eine Anfrage zur HyperPod Clustererstellung vor. + Option 1: Wenn Sie die verwenden AWS CLI, schreiben Sie eine Anfrage zur Clustererstellung im JSON-Format (`create_cluster.json`) gemäß den Anweisungen unter[Erstellen eines neuen Clusters](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-create-cluster). + Option 2: Wenn Sie die Benutzeroberfläche der SageMaker AI-Konsole verwenden, füllen Sie das Formular „**Clusteranfrage erstellen**“ in der Benutzeroberfläche der HyperPod Konsole aus. Folgen Sie dabei den Anweisungen unter[Erstellen Sie einen SageMaker HyperPod Cluster](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-create-cluster). Stellen Sie in dieser Phase sicher, dass Sie Instance-Gruppen in derselben Struktur erstellen, die Sie in Schritt 1 und 2 geplant haben. Achten Sie außerdem darauf, dass Sie den S3-Bucket aus Schritt 5 in den Anforderungsformularen angeben. 1. Reichen Sie die Anfrage zur Clustererstellung ein. HyperPod stellt auf der Grundlage der Anfrage einen Cluster bereit, erstellt dann eine `resource_config.json` Datei in den HyperPod Cluster-Instanzen und richtet Slurm auf dem Cluster ein, auf dem die Lifecycle-Skripten ausgeführt werden. Die folgenden Themen führen Sie durch die einzelnen Schritte und gehen detailliert darauf ein, wie Sie Konfigurationsdateien und Lebenszyklusskripte so organisieren, dass sie bei der HyperPod Clustererstellung ordnungsgemäß funktionieren. **Topics** + [Allgemeine Übersicht](#sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-highlevel-overview) + [Die grundlegenden Lebenszyklusskripte werden bereitgestellt von HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) + [Welche speziellen Konfigurationen werden in Slurm-Konfigurationsdateien verwaltet HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-what-hyperpod-overrides-in-slurm-conf.md) + [Rotationen im Slurm-Protokoll](sagemaker-hyperpod-slurm-log-rotation.md) + [Einbinden von Amazon FSx for Lustre und Amazon FSx for OpenZFS in einem Cluster HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-setup-with-fsx.md) + [Validierung der JSON-Konfigurationsdateien vor der Erstellung eines Slurm-Clusters auf HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md) + [Validierung der Laufzeit vor der Ausführung von Produktionsworkloads auf einem Slurm-Cluster HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-runtime.md) + [Interaktive Entwicklung von Lebenszyklus-Skripten auf einem Clusterknoten HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-develop-lifecycle-scripts.md) # Die grundlegenden Lebenszyklusskripte werden bereitgestellt von HyperPod In diesem Abschnitt werden Sie von oben nach ***unten durch alle Komponenten des grundlegenden Ablaufs der Einrichtung von Slurm geführt***. HyperPod Es beginnt mit der Vorbereitung einer Anfrage zur HyperPod Clustererstellung zur Ausführung der `CreateCluster` API und taucht tief in die hierarchische Struktur ein, bis hin zu Lebenszyklus-Skripten. Verwenden Sie die Beispiel-Lebenszyklus-Skripte, die im [Awsome Distributed Training GitHub ](https://github.com/aws-samples/awsome-distributed-training/) Repository bereitgestellt werden. Klonen Sie das Repository, indem Sie den folgenden Befehl ausführen. ``` git clone https://github.com/aws-samples/awsome-distributed-training/ ``` Die grundlegenden Lebenszyklus-Skripte für die Einrichtung eines Slurm-Clusters SageMaker HyperPod finden Sie unter. [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config) ``` cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config ``` Das folgende Flussdiagramm zeigt eine detaillierte Übersicht darüber, wie Sie die Basis-Lebenszyklusskripte gestalten sollten. In den Beschreibungen unter dem Diagramm und dem Verfahrensleitfaden wird erklärt, wie sie während des HyperPod `CreateCluster` API-Aufrufs funktionieren. ![\[Ein detailliertes Flussdiagramm der HyperPod Clustererstellung und der Struktur von Lebenszyklusskripten.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod-lifecycle-structure.png) ***Abbildung:** Ein detailliertes Flussdiagramm der HyperPod Clustererstellung und der Struktur von Lebenszyklusskripten. (1) Die gestrichelten Pfeile zeigen in die Richtung, in die die Kästen „aufgerufen“ werden, und veranschaulichen den Ablauf der Vorbereitung von Konfigurationsdateien und Lebenszyklusskripten. Der erste Schritt besteht in der Vorbereitung von `provisioning_parameters.json` und den Lebenszyklusskripten. Diese werden dann für eine gemeinsame Ausführung in der richtigen Reihenfolge in `lifecycle_script.py` codiert. Und die Ausführung des `lifecycle_script.py` Skripts erfolgt durch das `on_create.sh` Shell-Skript, das im HyperPod Instanzterminal ausgeführt werden soll. (2) Die durchgezogenen Pfeile zeigen den Hauptablauf bei der HyperPod Clustererstellung und wie die Boxen „aufgerufen“ oder „eingereicht“ werden. `on_create.sh`ist für die Anfrage zur Clustererstellung erforderlich, entweder im Formular zur **Clustererstellung `create_cluster.json` oder im Formular zur Clustererstellung** in der Benutzeroberfläche der Konsole. Nachdem Sie die Anfrage eingereicht haben, HyperPod wird die `CreateCluster` API auf der Grundlage der angegebenen Konfigurationsinformationen aus der Anfrage und den Lebenszyklusskripts ausgeführt. (3) Der gepunktete Pfeil weist darauf hin, dass die HyperPod Plattform während der Bereitstellung von Clusterressourcen Instances `resource_config.json` in den Clustern erstellt. `resource_config.json`enthält HyperPod Clusterressourceninformationen wie den Cluster-ARN, Instanztypen und IP-Adressen. Es ist wichtig zu beachten, dass Sie die Lebenszyklusskripte so vorbereiten sollten, dass sie die `resource_config.json`-Datei während der Clustererstellung erwarten. Weitere Informationen finden Sie in der folgenden Verfahrensanleitung.* In der folgenden Anleitung wird erklärt, was bei der HyperPod Clustererstellung passiert und wie die grundlegenden Lebenszyklusskripts entworfen werden. 1. `create_cluster.json`— Um eine Anfrage zur HyperPod Clustererstellung einzureichen, bereiten Sie eine `CreateCluster` Anforderungsdatei im JSON-Format vor. In diesem Beispiel für bewährte Methoden gehen wir davon aus, dass die Anforderungsdatei `create_cluster.json` heißt. Schreiben Sie`create_cluster.json`, um einen HyperPod Cluster mit Instanzgruppen bereitzustellen. Es hat sich bewährt, die gleiche Anzahl von Instanzgruppen hinzuzufügen wie die Anzahl der Slurm-Knoten, die Sie auf dem HyperPod Cluster konfigurieren möchten. Stellen Sie sicher, dass Sie den Instance-Gruppen, die Sie den Slurm-Knoten zuweisen möchten, eindeutige Namen geben. Außerdem müssen Sie einen S3-Bucket-Pfad angeben, um Ihren gesamten Satz an Konfigurationsdateien und Lebenszyklusskripten im Feldnamen `InstanceGroups.LifeCycleConfig.SourceS3Uri` im `CreateCluster`-Anforderungsformular zu speichern, und den Dateinamen eines Einstiegspunkt-Shell-Skripts (angenommen, es heißt `on_create.sh`) als `InstanceGroups.LifeCycleConfig.OnCreate` angeben. **Anmerkung** Wenn Sie das Formular „**Cluster erstellen**“ in der Benutzeroberfläche der HyperPod Konsole verwenden, verwaltet die Konsole das Ausfüllen und Senden der `CreateCluster` Anfrage in Ihrem Namen und führt die `CreateCluster` API im Backend aus. In diesem Fall müssen Sie `create_cluster.json` nicht erstellen. Achten Sie stattdessen darauf, dass Sie die richtigen Informationen zur Cluster-Konfiguration in das zu übermittelnde Formular **Cluster erstellen** eingeben. 1. `on_create.sh`— Für jede Instanzgruppe müssen Sie ein Einstiegs-Shell-Skript bereitstellen, um Befehle auszuführen`on_create.sh`, Skripte zur Installation von Softwarepaketen auszuführen und die HyperPod Clusterumgebung mit Slurm einzurichten. Die beiden Dinge, die Sie vorbereiten müssen, sind ein `provisioning_parameters.json` erforderliches HyperPod für die Einrichtung von Slurm und eine Reihe von Lifecycle-Skripten für die Installation von Softwarepaketen. Dieses Skript sollte so geschrieben werden, dass es die folgenden Dateien findet und ausführt, wie im Beispielskript unter [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/on_create.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/on_create.sh) gezeigt. **Anmerkung** Stellen Sie sicher, dass Sie den gesamten Satz von Lebenszyklusskripten an den in den S3-Speicherort hochladen, den Sie in `create_cluster.json` angeben. Sie sollten Ihre `provisioning_parameters.json` auch an demselben Speicherort speichern. 1. `provisioning_parameters.json`— Das ist ein[Konfigurationsformular für provisioning\$1parameters.json](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm). Das `on_create.sh`-Skript findet diese JSON-Datei und definiert eine Umgebungsvariable, um den Pfad zu ihr zu identifizieren. Über diese JSON-Datei können Sie Slurm-Knoten und Speicheroptionen wie Amazon FSx for Lustre for Slurm für die Kommunikation konfigurieren. Stellen Sie sicher`provisioning_parameters.json`, dass Sie die HyperPod Cluster-Instanzgruppen mit den Namen, die Sie angegeben haben, den Slurm-Knoten entsprechend zuweisen, je nachdem, wie Sie sie einrichten möchten. `create_cluster.json` Das folgende Diagramm zeigt ein Beispiel dafür, wie die beiden JSON-Konfigurationsdateien `create_cluster.json` geschrieben werden `provisioning_parameters.json` sollten, um den HyperPod Slurm-Knoten Instanzgruppen zuzuweisen. In diesem Beispiel gehen wir von der Einrichtung von drei Slurm-Knoten aus: Controller-Knoten (Verwaltung), Anmeldeknoten (optional) und Rechenknoten (Worker). **Tipp** Um Ihnen bei der Validierung dieser beiden JSON-Dateien zu helfen, stellt das HyperPod Serviceteam ein Validierungsskript zur Verfügung. [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py) Weitere Informationen hierzu finden Sie unter [Validierung der JSON-Konfigurationsdateien vor der Erstellung eines Slurm-Clusters auf HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md). ![\[Direkter Vergleich zwischen .json-Dateien.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod-lifecycle-slurm-config.png) ***Abbildung:** Direkter Vergleich zwischen `create_cluster.json` der HyperPod Clustererstellung und `provisiong_params.json` der Slurm-Konfiguration. Die Anzahl der Instance-Gruppen in `create_cluster.json` sollte der Anzahl der Knoten entsprechen, die Sie als Slurm-Knoten konfigurieren möchten. Im Fall des Beispiels in der Abbildung werden drei Slurm-Knoten auf einem HyperPod Cluster aus drei Instanzgruppen konfiguriert. Sie sollten die HyperPod Cluster-Instanzgruppen den Slurm-Knoten zuweisen, indem Sie die Namen der Instanzgruppen entsprechend angeben.* 1. `resource_config.json`— Während der Clustererstellung wird das `lifecycle_script.py` Skript so geschrieben, dass es eine `resource_config.json` Datei von HyperPod erwartet. Diese Datei enthält Informationen über den Cluster, z. B. Instance-Typen und IP-Adressen. Wenn Sie die `CreateCluster` API ausführen, HyperPod erstellt es eine Ressourcenkonfigurationsdatei unter, die auf der `create_cluster.json` Datei `/opt/ml/config/resource_config.json` basiert. Der Dateipfad wird in der Umgebungsvariablen namens `SAGEMAKER_RESOURCE_CONFIG_PATH` gespeichert. **Wichtig** Die `resource_config.json` Datei wird automatisch von der HyperPod Plattform generiert und Sie müssen sie NICHT erstellen. Der folgende Code zeigt ein Beispiel für `resource_config.json`, die aus der Clustererstellung basierend auf `create_cluster.json` im vorherigen Schritt erstellt würde, und soll Ihnen helfen zu verstehen, was im Backend geschieht und wie eine automatisch generierte `resource_config.json` aussehen würde. ``` { "ClusterConfig": { "ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde01234yz", "ClusterName": "your-hyperpod-cluster" }, "InstanceGroups": [ { "Name": "controller-machine", "InstanceType": "ml.c5.xlarge", "Instances": [ { "InstanceName": "controller-machine-1", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" } ] }, { "Name": "login-group", "InstanceType": "ml.m5.xlarge", "Instances": [ { "InstanceName": "login-group-1", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" } ] }, { "Name": "compute-nodes", "InstanceType": "ml.trn1.32xlarge", "Instances": [ { "InstanceName": "compute-nodes-1", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" }, { "InstanceName": "compute-nodes-2", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" }, { "InstanceName": "compute-nodes-3", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" }, { "InstanceName": "compute-nodes-4", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" } ] } ] } ``` 1. `lifecycle_script.py`— Dies ist das wichtigste Python-Skript, das gemeinsam Lifecycle-Skripte ausführt, die Slurm auf dem HyperPod Cluster einrichten, während es bereitgestellt wird. Dieses Skript liest in `provisioning_parameters.json` und `resource_config.json` aus den in `on_create.sh` angegebenen oder identifizierten Pfaden, übergibt die relevanten Informationen an jedes Lebenszyklusskript und führt dann die Lebenszyklusskripte der Reihe nach aus. Lebenszyklusskripte sind eine Reihe von Skripten, die Sie vollständig flexibel anpassen können, um Softwarepakete zu installieren und während der Clustererstellung notwendige oder benutzerdefinierte Konfigurationen vorzunehmen, z. B. Slurm einrichten, Benutzer anlegen, Conda oder Docker installieren. Das [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py)Beispielskript ist darauf vorbereitet, andere grundlegende Lebenszyklusskripte im Repository auszuführen, z. B. Slurm deamons ([https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/start_slurm.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/start_slurm.sh)) zu starten, Amazon FSx for Lustre () zu mounten und MariaDB-Buchhaltung ([https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/mount_fsx.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/mount_fsx.sh)) und RDS-Buchhaltung ([https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_mariadb_accounting.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_mariadb_accounting.sh)) einzurichten. [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_rds_accounting.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_rds_accounting.sh) Sie können auch weitere Skripte hinzufügen, sie in dasselbe Verzeichnis packen und Codezeilen hinzufügen, um die Skripte ausführen zu `lifecycle_script.py` lassen. HyperPod Weitere Informationen zu den grundlegenden Lebenszyklus-Skripten finden Sie auch unter [3.1 Lifecycle-Skripten](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#31-lifecycle-scripts) im *Awsome Distributed Training GitHub Repository*. **Anmerkung** HyperPod läuft [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) auf jeder Instanz eines Clusters, und das AMI verfügt über vorinstallierte Softwarepakete, die Kompatibilitäten zwischen ihnen und Funktionen erfüllen. HyperPod Beachten Sie, dass Sie bei der Neuinstallation eines der vorinstallierten Pakete für die Installation kompatibler Pakete verantwortlich sind und beachten Sie, dass einige HyperPod Funktionen möglicherweise nicht wie erwartet funktionieren. Zusätzlich zu den Standardeinstellungen sind weitere Skripte zur Installation der folgenden Software im [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils)-Ordner verfügbar. Die `lifecycle_script.py`-Datei enthält bereits Codezeilen zum Ausführen der Installationsskripte. Suchen Sie diese Zeilen anhand der folgenden Angaben und entfernen Sie die Kommentare, um sie zu aktivieren. 1. Die folgenden Codezeilen beziehen sich auf die Installation von [Docker](https://www.docker.com/), [Enroot](https://github.com/NVIDIA/enroot) und [Pyxis](https://github.com/NVIDIA/pyxis). Diese Pakete sind erforderlich, um Docker-Container auf einem Slurm-Cluster auszuführen. Um diesen Installationsschritt zu aktivieren, legen Sie den `enable_docker_enroot_pyxis`-Parameter in der [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py)-Datei auf `True` fest. ``` # Install Docker/Enroot/Pyxis if Config.enable_docker_enroot_pyxis: ExecuteBashScript("./utils/install_docker.sh").run() ExecuteBashScript("./utils/install_enroot_pyxis.sh").run(node_type) ``` 1. Sie können Ihren HyperPod Cluster mit [Amazon Managed Service for Prometheus und Amazon Managed](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) [Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) integrieren, um Metriken über den HyperPod Cluster und die Clusterknoten in Amazon Managed Grafana-Dashboards zu exportieren. Um Metriken zu exportieren und das [Slurm-Dashboard](https://grafana.com/grafana/dashboards/4323-slurm-dashboard/), das [Dashboard von NVIDIA DCGM Exporter](https://grafana.com/grafana/dashboards/12239-nvidia-dcgm-exporter-dashboard/) und das [EFA-Metrics-Dashboard](https://grafana.com/grafana/dashboards/20579-efa-metrics-dev/) auf Amazon Managed Grafana zu verwenden, müssen Sie den [Slurm-Exporter für Prometheus](https://github.com/vpenso/prometheus-slurm-exporter), den [NVIDIA-DCGM-Exporter](https://github.com/NVIDIA/dcgm-exporter) und den [EFA-Knoten-Exporter](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/3.efa-node-exporter/README.md) installieren. Weitere Informationen zur Installation der Exportpakete und zur Verwendung von Grafana-Dashboards in einem Workspace von Amazon Managed Grafana finden Sie unter [SageMaker HyperPod Überwachung der Cluster-Ressourcen](sagemaker-hyperpod-cluster-observability-slurm.md). Um diesen Installationsschritt zu aktivieren, legen Sie den `enable_observability`-Parameter in der [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py)-Datei auf `True` fest. ``` # Install metric exporting software and Prometheus for observability if Config.enable_observability: if node_type == SlurmNodeType.COMPUTE_NODE: ExecuteBashScript("./utils/install_docker.sh").run() ExecuteBashScript("./utils/install_dcgm_exporter.sh").run() ExecuteBashScript("./utils/install_efa_node_exporter.sh").run() if node_type == SlurmNodeType.HEAD_NODE: wait_for_scontrol() ExecuteBashScript("./utils/install_docker.sh").run() ExecuteBashScript("./utils/install_slurm_exporter.sh").run() ExecuteBashScript("./utils/install_prometheus.sh").run() ``` 1. Stellen Sie sicher, dass Sie alle Konfigurationsdateien und Einrichtungsskripte aus **Schritt 2** in den S3-Bucket hochladen, den Sie in der `CreateCluster`-Anforderung in **Schritt 1** angegeben haben. Nehmen wir beispielsweise an, dass Ihre `create_cluster.json` Folgendes enthält. ``` "LifeCycleConfig": { "SourceS3URI": "s3://sagemaker-hyperpod-lifecycle/src", "OnCreate": "on_create.sh" } ``` Dann sollte ihr `on_create.sh`, `lifecycle_script.py`, `provisioning_parameters.json` und alle anderen Einrichtungsskripte enthalten. Angenommen, Sie haben die Dateien wie folgt in einem lokalen Ordner vorbereitet. ``` └── lifecycle_files // your local folder ├── provisioning_parameters.json ├── on_create.sh ├── lifecycle_script.py └── ... // more setup scrips to be fed into lifecycle_script.py ``` Verwenden Sie den S3-Befehl wie folgt, um die Dateien hochzuladen. ``` aws s3 cp --recursive ./lifecycle_scripts s3://sagemaker-hyperpod-lifecycle/src ``` # Welche speziellen Konfigurationen werden in Slurm-Konfigurationsdateien verwaltet HyperPod Wenn Sie einen Slurm-Cluster erstellen HyperPod, richtet der HyperPod Agent die [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html)Dateien [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html)und die Dateien unter ein, `/opt/slurm/etc/` um den Slurm-Cluster auf der Grundlage Ihrer Anfrage zur Clustererstellung und Ihrer HyperPod Lebenszyklusskripte zu verwalten. Die folgende Liste zeigt, welche spezifischen Parameter der HyperPod Agent verarbeitet und überschreibt. **Wichtig** Es wird dringend empfohlen, diese von HyperPod verwalteten Parameter **nicht** zu ändern. + [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html)In HyperPod richtet die folgenden grundlegenden Parameter ein: `ClusterName``SlurmctldHost`,`PartitionName`, und`NodeName`. Um die [Automatische Knotenwiederherstellung und automatische Wiederaufnahme](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) Funktionalität zu aktivieren, HyperPod müssen außerdem die `SchedulerParameters` Parameter `TaskPlugin` und wie folgt festgelegt werden. Der HyperPod Agent richtet diese beiden Parameter standardmäßig mit den erforderlichen Werten ein. ``` TaskPlugin=task/none SchedulerParameters=permit_job_expansion ``` + In [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html), HyperPod verwaltet `NodeName` für GPU-Knoten. # Rotationen im Slurm-Protokoll SageMaker HyperPod bietet automatische Protokollrotation für Slurm-Daemon-Logs, um die Speicherplatznutzung zu verwalten und die Systemleistung aufrechtzuerhalten. Die Rotation von Protokollen ist entscheidend, um zu verhindern, dass Protokolle übermäßig viel Speicherplatz beanspruchen, und um einen optimalen Systembetrieb sicherzustellen, indem alte Protokolldateien automatisch archiviert und entfernt werden, während die aktuellen Protokollierungsinformationen beibehalten werden. Slurm-Protokollrotationen sind standardmäßig aktiviert, wenn Sie einen Cluster erstellen. ## Wie funktioniert die Log-Rotation Wenn diese Option aktiviert ist, gilt für die Konfiguration der Protokollrotation Folgendes: + Überwacht alle Slurm-Protokolldateien mit der Erweiterung, die `.log` sich im `/var/log/slurm/` Ordner auf den Controller-, Anmelde- und Rechenknoten befinden. + Dreht die Protokolle, wenn sie eine Größe von 50 MB erreichen. + Behält bis zu zwei rotierte Protokolldateien bei, bevor sie gelöscht werden. + Sendet nach der Rotation SIGUSR2 ein Signal an die Slurm-Daemons (`slurmctld``slurmd`, und`slurmdbd`). ## Liste der rotierten Protokolldateien Slurm-Logs befinden sich im `/var/log/slurm/` Verzeichnis. Die Protokollrotation ist für alle `/var/log/slurm/*.log` übereinstimmenden Dateien aktiviert. Wenn eine Rotation stattfindet, haben rotierte Dateien numerische Suffixe (z. B.`slurmd.log.1`). Die folgende Liste erhebt keinen Anspruch auf Vollständigkeit, zeigt jedoch einige der kritischen Protokolldateien, die automatisch rotieren: + `/var/log/slurm/slurmctld.log` + `/var/log/slurm/slurmd.log` + `/var/log/slurm/slurmdb.log` + `/var/log/slurm/slurmrestd.log` ## Aktivieren oder deaktivieren Sie die Protokollrotation Sie können die Funktion zur Protokollrotation mithilfe des `enable_slurm_log_rotation` Parameters im `config.py` Skript der Lifecycle-Skripten Ihres Clusters steuern, wie im folgenden Beispiel gezeigt: ``` class Config: # Set false if you want to disable log rotation of Slurm daemon logs enable_slurm_log_rotation = True # Default value ``` Um die Log-Rotation zu deaktivieren, setzen Sie den Parameter auf`False`, wie im folgenden Beispiel gezeigt: ``` enable_slurm_log_rotation = False ``` **Anmerkung** Lifecycle-Skripten werden während der Clustererstellung auf allen Slurm-Knoten (Controller-, Anmelde- und Rechenknoten) ausgeführt. Sie werden auch auf neuen Knoten ausgeführt, wenn sie dem Cluster hinzugefügt werden. Die Aktualisierung der Protokollrotationskonfigurationen muss nach der Clustererstellung manuell erfolgen. Die Konfiguration der Protokollrotation ist in gespeichert`/etc/logrotate.d/sagemaker-hyperpod-slurm`. Wir empfehlen, die Protokollrotation aktiviert zu lassen, um zu verhindern, dass Protokolldateien übermäßig viel Speicherplatz beanspruchen. Um die Protokollrotation zu deaktivieren, löschen Sie die `sagemaker-hyperpod-slurm` Datei oder kommentieren Sie ihren Inhalt, indem Sie `#` am Anfang jeder Zeile in der `sagemaker-hyperpod-slurm` Datei etwas hinzufügen. ## Standardeinstellungen für die Protokollrotation Die folgenden Einstellungen werden automatisch für jede rotierte Protokolldatei konfiguriert: | Einstellung | Wert | Description | | --- | --- | --- | | rotate | 2 | Anzahl der rotierten Protokolldateien, die aufbewahrt werden sollen | | size | 50 MB | Maximale Größe vor der Rotation | | copytruncate | aktiviert | Kopiert und kürzt die ursprüngliche Protokolldatei | | compress | disabled | Rotierte Protokolle werden nicht komprimiert | | missingok | aktiviert | Kein Fehler, wenn die Protokolldatei fehlt | | notifempty | aktiviert | Rotiert keine leeren Dateien | | noolddir | aktiviert | Rotierte Dateien bleiben im selben Verzeichnis | # Einbinden von Amazon FSx for Lustre und Amazon FSx for OpenZFS in einem Cluster HyperPod Um ein gemeinsam genutztes Amazon FSx for Lustre-Dateisystem in Ihren HyperPod Cluster einzubinden, richten Sie Folgendes ein. 1. Verwenden Sie Ihre Amazon-VPC. 1. Damit HyperPod Cluster-Instances innerhalb Ihrer VPC kommunizieren können, stellen Sie sicher, dass Sie die der [Einrichtung SageMaker HyperPod mit einer benutzerdefinierten Amazon VPC](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc) IAM-Rolle für zuordnen. SageMaker HyperPod 1. Fügen Sie in `create_cluster.json` die folgenden VPC-Informationen ein. ``` "VpcConfig": { "SecurityGroupIds": [ "string" ], "Subnets": [ "string" ] } ``` Weitere Tipps zur Einrichtung von Amazon VPC finden Sie unter [Voraussetzungen für die Verwendung SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md). 1. Um die Konfiguration von Slurm mit Amazon FSx for Lustre abzuschließen, können Sie einen der folgenden Ansätze verwenden. Sie finden die FSx Amazon-Informationen entweder in der Amazon FSx for Lustre-Konsole in Ihrem Konto oder indem Sie den folgenden AWS CLI Befehl ausführen:. `aws fsx describe-file-systems` **Option A: API-gesteuerte Konfiguration (empfohlen)** Geben Sie die FSx Amazon-Konfiguration direkt in der CreateCluster API-Nutzlast an und verwenden Sie sie `InstanceStorageConfigs` innerhalb jeder Instanzgruppe. Dieser Ansatz unterstützt sowohl FSx Lustre als auch OpenZFS und FSx ermöglicht die Konfiguration. per-instance-group FSx ``` "InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx", "MountName": "1abcdefg" } } ] ``` Verwenden Sie FSx für OpenZFS stattdessen: `FsxOpenZfsConfig` ``` "InstanceStorageConfigs": [ { "FsxOpenZfsConfig": { "DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx-openzfs" } } ] ``` Weitere Informationen finden Sie unter [Erste Schritte mit der SageMaker HyperPod Verwendung der AWS CLI](sagemaker-hyperpod-quickstart.md). **Option B: Legacy-Konfiguration** Geben Sie den FSx Amazon-DNS-Namen und den FSx Amazon-Mount-Namen an, `provisioning_parameters.json` wie in der Abbildung im [Die grundlegenden Lebenszyklusskripte werden bereitgestellt von HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) Abschnitt gezeigt. ``` "fsx_dns_name": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com", "fsx_mountname": "1abcdefg" ``` # Validierung der JSON-Konfigurationsdateien vor der Erstellung eines Slurm-Clusters auf HyperPod Verwenden Sie das Konfigurationsvalidierungsskript [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py), um die JSON-Konfigurationsdateien zu validieren, bevor Sie ein Anforderung zur Clustererstellung übermitteln. Dieses Skript analysiert und vergleicht Ihre HyperPod Cluster-Konfigurations-JSON-Datei und die Slurm-Konfigurations-JSON-Datei und ermittelt, ob zwischen den beiden Dateien und auch zwischen Amazon EC2-, Amazon VPC- und Amazon-Ressourcen eine Fehlkonfiguration der Ressourcen vorliegt. FSx Um beispielsweise die Dateien `provisioning_parameters.json` und `create_cluster.json` aus dem [Die grundlegenden Lebenszyklusskripte werden bereitgestellt von HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md)-Abschnitt zu validieren, führen Sie das Validierungsskript wie folgt aus. ``` python3 validate-config.py --cluster-config create_cluster.json --provisioning-parameters provisioning_parameters.json ``` Im Folgenden finden Sie eine Beispielausgabe für eine erfolgreiche Validierung. ``` ✔️ Validated instance group name worker-group-1 is correct ... ✔️ Validated subnet subnet-012345abcdef67890 ... ✔️ Validated security group sg-012345abcdef67890 ingress rules ... ✔️ Validated security group sg-012345abcdef67890 egress rules ... ✔️ Validated FSx Lustre DNS name fs-012345abcdef67890.fsx.us-east-1.amazonaws.com ✔️ Validated FSx Lustre mount name abcdefgh ✅ Cluster Validation succeeded ``` # Validierung der Laufzeit vor der Ausführung von Produktionsworkloads auf einem Slurm-Cluster HyperPod Verwenden Sie das Runtime-Validierungsskript, um die Laufzeit zu überprüfen HyperPod, bevor Sie Produktions-Workloads auf einem Slurm-Cluster ausführen. [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/hyperpod-precheck.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/hyperpod-precheck.py) Dieses Skript prüft, ob auf dem Slurm-Cluster alle Pakete für die Ausführung von Docker installiert sind, ob der Cluster über ein ordnungsgemäß FSx für Lustre gemountetes Dateisystem und ein Benutzerverzeichnis verfügt, das das Dateisystem gemeinsam nutzt, und ob der Slurm-Daemon auf allen Rechenknoten läuft. Um das Skript auf mehreren Knoten gleichzeitig auszuführen, verwenden Sie `srun`, wie im folgenden Beispielbefehl zum Ausführen des Skripts auf einem Slurm-Cluster mit 8 Knoten gezeigt. ``` # The following command runs on 8 nodes srun -N 8 python3 hyperpod-precheck.py ``` **Anmerkung** Weitere Informationen zum Validierungsskript, z. B. zu den Funktionen zur Laufzeitvalidierung, die das Skript bietet, und Richtlinien zur Lösung von Problemen, die die Validierungen nicht bestehen, finden Sie unter [Laufzeitvalidierung vor dem Ausführen von Workloads](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#35-runtime-validation-before-running-workloads) im *Awsome Distributed GitHub Training-Repository*. # Interaktive Entwicklung von Lebenszyklus-Skripten auf einem Clusterknoten HyperPod In diesem Abschnitt wird erklärt, wie Sie interaktiv Lebenszyklusskripts entwickeln können, ohne wiederholt einen HyperPod Cluster erstellen und löschen zu müssen. 1. Erstellen Sie einen HyperPod Cluster mit den grundlegenden Lebenszyklusskripten. 1. Melden Sie sich bei einem Clusterknoten an. 1. Entwickeln Sie ein Skript (`configure_xyz.sh`), indem Sie es auf dem Knoten bearbeiten und wiederholt ausführen. 1. HyperPod führt die Lebenszyklusskripts als Root-Benutzer aus. Wir empfehlen daher, dass Sie das während der Entwicklung `configure_xyz.sh` als Root-Benutzer ausführen, um sicherzustellen, dass das Skript unter derselben Bedingung getestet wird, während es von ausgeführt wird HyperPod. 1. Integrieren Sie das Skript in `lifecycle_script.py`, indem Sie eine Codezeile ähnlich der folgenden hinzufügen. ``` ExecuteBashScript("./utils/configure_xyz.sh").run() ``` 1. Laden Sie die aktualisierten Lebenszyklusskripte in den S3-Bucket hoch, den Sie ursprünglich für das Hochladen der grundlegenden Lebenszyklusskripte verwendet haben. 1. Testen Sie die integrierte Version von, `lifecycle_script.py` indem Sie einen neuen HyperPod Cluster erstellen. Sie können auch den manuellen Instanzersatz verwenden, um die aktualisierten Lebenszyklusskripts zu testen, indem Sie neue Instanzen erstellen. Eine ausführliche Anleitung finden Sie unter [Manuelles Ersetzen eines Knotens](https://docs.aws.amazon.com//sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.html#sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance-replace). Beachten Sie, dass nur Worker-Knoten austauschbar sind.