Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Personalizzazione dei SageMaker HyperPod cluster utilizzando script del ciclo di vita SageMaker HyperPod offre sempre cluster di up-and-running calcolo, che sono altamente personalizzabili in quanto è possibile scrivere script del ciclo di vita per indicare come configurare le risorse del cluster. SageMaker HyperPod Gli argomenti seguenti sono le best practice per preparare gli script del ciclo di vita per configurare SageMaker HyperPod i cluster con strumenti open source per la gestione del carico di lavoro. Negli argomenti seguenti vengono illustrate le best practice approfondite per la preparazione degli script del ciclo di vita su cui configurare le configurazioni Slurm. SageMaker HyperPod ## Panoramica generale La procedura seguente è il flusso principale per il provisioning di un HyperPod cluster e la sua configurazione con Slurm. Le fasi sono in ordine, in base a un approccio dal ***basso verso l’alto***. 1. Pianifica come vuoi creare i nodi Slurm su un cluster. HyperPod Ad esempio, se desideri configurare due nodi Slurm, dovrai configurare due gruppi di istanze in un cluster. HyperPod 1. Prepara la configurazione di Slurm. Scegliete uno dei seguenti approcci: + **Opzione A: configurazione basata su API (consigliata)**: definisci i tipi di nodi e le partizioni Slurm direttamente nel payload dell'`CreateCluster`API utilizzando all'interno di ciascun gruppo di istanze. `SlurmConfig` Con questo approccio: + Non è necessario alcun `provisioning_parameters.json` file + La topologia Slurm è definita nel payload dell'API insieme alle definizioni dei gruppi di istanze + FSx i filesystem sono configurati tramite per-instance-group `InstanceStorageConfigs` + La strategia di configurazione è controllata tramite `Orchestrator.Slurm.SlurmConfigStrategy` Esempio `SlurmConfig` in un gruppo di istanze: ``` { "InstanceGroupName": "gpu-compute", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 8, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["gpu-training"] } } ``` + **Opzione B: configurazione precedente:** prepara un `provisioning_parameters.json` file, che è un[Modulo di configurazione per provisioning\$1parameters.json](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm). `provisioning_parameters.json`deve contenere informazioni sulla configurazione del nodo Slurm da fornire sul cluster. HyperPod Questo file dovrebbe riflettere la progettazione dei nodi Slurm della Fase 1. 1. Prepara un set di script del ciclo di vita su cui configurare Slurm per installare pacchetti software e configurare un ambiente nel cluster adatto HyperPod al tuo caso d'uso. È necessario strutturare gli script del ciclo di vita in modo che vengano eseguiti collettivamente in ordine in uno script Python centrale (`lifecycle_script.py`), oltre a scrivere uno script shell del punto di ingresso (`on_create.sh`) per eseguire lo script Python. Lo script di shell entrypoint è ciò che devi fornire a una richiesta di creazione di HyperPod cluster più avanti nel Passaggio 5. Inoltre, si noti che è necessario scrivere gli script in modo da aspettarsi `resource_config.json` che vengano generati HyperPod durante la creazione del cluster. `resource_config.json`contiene informazioni sulle risorse del HyperPod cluster come indirizzi IP, tipi di istanze e ARNs, ed è ciò che è necessario utilizzare per configurare Slurm. 1. Raccogli tutti i file delle fasi precedenti in una cartella. La struttura delle cartelle dipende dall'approccio di configurazione selezionato nel passaggio 2. Se hai selezionato l'opzione A (configurazione basata su API): La cartella necessita solo di script del ciclo di vita per attività di configurazione personalizzate. La configurazione e il FSx montaggio di Slurm vengono gestiti HyperPod automaticamente in base al payload dell'API. ``` └── lifecycle_files // your local folder ├── on_create.sh ├── lifecycle_script.py └── ... // more setup scripts to be fed into lifecycle_script.py ``` **Nota** Il `provisioning_parameters.json` file non è necessario quando si utilizza la configurazione basata su API. Se hai selezionato l'opzione B (configurazione precedente): La cartella deve includere `provisioning_parameters.json` e il set completo di script del ciclo di vita. ``` └── 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. Carica tutti i file in un bucket S3. Copia e annota il percorso del bucket S3. Ricorda di creare un percorso del bucket S3 che inizi con `sagemaker-`, perché dovrai scegliere un percorso del [Ruolo IAM per SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) collegato a [`AmazonSageMakerClusterInstanceRolePolicy`](security-iam-awsmanpol-AmazonSageMakerClusterInstanceRolePolicy.md), che consente solo i percorsi dei bucket S3 che iniziano con il prefisso `sagemaker-`. Di seguito è riportato un comando di esempio per caricare tutti i file in un bucket S3. ``` aws s3 cp --recursive ./lifecycle_files s3://sagemaker-hyperpod-lifecycle/src ``` 1. Prepara una richiesta di creazione HyperPod del cluster. + Opzione 1: se utilizzi il AWS CLI, scrivi una richiesta di creazione del cluster in formato JSON (`create_cluster.json`) seguendo le istruzioni all'indirizzo[Creazione di un nuovo cluster](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-create-cluster). + Opzione 2: se utilizzi l'interfaccia utente della console SageMaker AI, compila il modulo di richiesta **Crea un cluster** nell'interfaccia utente della HyperPod console seguendo le istruzioni riportate all'indirizzo[Crea un SageMaker HyperPod cluster](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-create-cluster). In questa fase, assicurati di creare gruppi di istanze nella stessa struttura pianificata nelle Fasi 1 e 2. Inoltre, assicurati di specificare il bucket S3 della Fase 5 nei moduli di richiesta. 1. Invia la richiesta di creazione del cluster. HyperPod esegue il provisioning di un cluster in base alla richiesta, quindi crea un `resource_config.json` file nelle istanze del HyperPod cluster e configura Slurm sul cluster che esegue gli script del ciclo di vita. I seguenti argomenti illustrano e approfondiscono i dettagli su come organizzare i file di configurazione e gli script del ciclo di vita in modo che funzionino correttamente durante la creazione del cluster. HyperPod **Topics** + [Panoramica generale](#sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-highlevel-overview) + [Script del ciclo di vita di base forniti da HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) + [Quali configurazioni particolari gestisce nei file di configurazione Slurm HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-what-hyperpod-overrides-in-slurm-conf.md) + [Slurm registra le rotazioni](sagemaker-hyperpod-slurm-log-rotation.md) + [Montaggio di Amazon FSx for Lustre e Amazon FSx for OpenZFS su un cluster HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-setup-with-fsx.md) + [Convalida dei file di configurazione JSON prima di creare un cluster Slurm su HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md) + [Convalida del runtime prima di eseguire carichi di lavoro di produzione su un cluster Slurm HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-runtime.md) + [Sviluppo interattivo di script del ciclo di vita su un nodo del cluster HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-develop-lifecycle-scripts.md) # Script del ciclo di vita di base forniti da HyperPod Questa sezione illustra ogni componente del flusso di base di configurazione di Slurm on HyperPod con un approccio ***dall'alto*** verso il basso. Inizia dalla preparazione di una richiesta di creazione HyperPod del cluster per eseguire l'`CreateCluster`API e approfondisce la struttura gerarchica fino agli script del ciclo di vita. [Utilizza gli script di esempio relativi al ciclo di vita forniti nell'archivio Awsome Distributed Training. GitHub ](https://github.com/aws-samples/awsome-distributed-training/) Clona il repository con il comando seguente. ``` git clone https://github.com/aws-samples/awsome-distributed-training/ ``` Gli script del ciclo di vita di base per la configurazione di un cluster Slurm sono disponibili all'indirizzo. SageMaker HyperPod [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 ``` Il diagramma di flusso seguente mostra una panoramica dettagliata di come progettare gli script del ciclo di vita di base. Le descrizioni sotto il diagramma e la guida procedurale spiegano come funzionano durante la chiamata API. HyperPod `CreateCluster` ![\[Un diagramma di flusso dettagliato della creazione dei HyperPod cluster e della struttura degli script del ciclo di vita.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod-lifecycle-structure.png) ***Figura:** Un diagramma di flusso dettagliato della creazione dei HyperPod cluster e della struttura degli script del ciclo di vita. (1) Le frecce tratteggiate indicano il punto in cui vengono “richiamate” le caselle e mostrano il flusso dei file di configurazione e la preparazione degli script del ciclo di vita. Il processo inizia dalla preparazione del file `provisioning_parameters.json` e degli script del ciclo di vita. Questi vengono quindi codificati in `lifecycle_script.py` per essere eseguiti in ordine collettivamente. E l'esecuzione dello `lifecycle_script.py` script viene eseguita dallo script di `on_create.sh` shell, che deve essere eseguito nel terminale dell' HyperPodistanza. (2) Le frecce piene mostrano il flusso principale di creazione del HyperPod cluster e il modo in cui le caselle vengono «richiamate» o «inviate a». `on_create.sh`è necessario per la richiesta di creazione del cluster, nel modulo Crea una richiesta di cluster `create_cluster.json` o nel modulo **Crea una richiesta di cluster** nell'interfaccia utente della console. Dopo aver inviato la richiesta, HyperPod esegue l'`CreateCluster`API in base alle informazioni di configurazione fornite dalla richiesta e dagli script del ciclo di vita. (3) La freccia punteggiata indica che la HyperPod piattaforma crea istanze `resource_config.json` nel cluster durante il provisioning delle risorse del cluster. `resource_config.json`contiene informazioni sulle risorse del HyperPod cluster come l'ARN del cluster, i tipi di istanza e gli indirizzi IP. È importante notare che gli script del ciclo di vita vanno preparati in modo che prevedano il file `resource_config.json` durante la creazione del cluster. Per ulteriori informazioni, consulta la guida con le procedure di seguito.* La seguente guida procedurale spiega cosa succede durante la creazione del HyperPod cluster e come sono progettati gli script del ciclo di vita di base. 1. `create_cluster.json`— Per inviare una richiesta di creazione di un HyperPod cluster, si prepara un file di `CreateCluster` richiesta in formato JSON. In questo esempio di best practice, supponiamo che il file di richiesta si chiami `create_cluster.json`. Scrivi `create_cluster.json` per fornire gruppi di istanze a un HyperPod cluster. La best practice consiste nell'aggiungere lo stesso numero di gruppi di istanze del numero di nodi Slurm che intendi configurare sul HyperPod cluster. Assicurati di assegnare nomi distintivi ai gruppi di istanze che assegnerai ai nodi Slurm che intendi configurare. Inoltre, devi specificare un percorso al bucket S3 per archiviare l’intero set di file di configurazione e script del ciclo di vita nel campo `InstanceGroups.LifeCycleConfig.SourceS3Uri` del modulo di richiesta `CreateCluster`. Inoltre, devi specificare il nome del file di uno script shell del punto di ingresso (chiamato, supponiamo, `on_create.sh`) in `InstanceGroups.LifeCycleConfig.OnCreate`. **Nota** Se utilizzi il modulo di invio **Crea un cluster** nell'interfaccia utente della console, la HyperPod console gestisce la compilazione e l'invio della `CreateCluster` richiesta per tuo conto ed esegue l'`CreateCluster`API nel backend. In questo caso, non è necessario creare`create_cluster.json`, ma assicurati di specificare le informazioni corrette sulla configurazione del cluster nel modulo di invio **Crea un cluster**. 1. `on_create.sh`— Per ogni gruppo di istanze, è necessario fornire uno script di shell entrypoint per eseguire comandi`on_create.sh`, eseguire script per installare pacchetti software e configurare l'ambiente cluster con Slurm. HyperPod Le due cose da preparare sono una `provisioning_parameters.json` necessaria per configurare Slurm e un set di script del ciclo di vita HyperPod per l'installazione dei pacchetti software. Questo script deve essere scritto per trovare ed eseguire i file seguenti, come mostrato nello script di esempio in [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). **Nota** Assicurati di caricare l’intero set di script del ciclo di vita nella posizione S3 specificata in `create_cluster.json`. Anche il file `provisioning_parameters.json` deve trovarsi nella stessa posizione. 1. `provisioning_parameters.json`: questo è un [Modulo di configurazione per provisioning\$1parameters.json](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm). Lo script `on_create.sh` trova questo file JSON e definisce la variabile di ambiente per identificarne il percorso. Tramite questo file JSON, puoi configurare nodi Slurm e opzioni di storage come Amazon FSx for Lustre for Slurm con cui comunicare. Inoltre`provisioning_parameters.json`, assicurati di assegnare i gruppi di istanze del HyperPod cluster utilizzando i nomi specificati ai nodi Slurm in modo appropriato in base `create_cluster.json` a come intendi configurarli. Il diagramma seguente mostra un esempio di come i due file di configurazione JSON `provisioning_parameters.json` devono essere scritti per HyperPod assegnare i gruppi di `create_cluster.json` istanze ai nodi Slurm. In questo esempio, supponiamo di dover configurare tre nodi Slurm: il nodo controller (gestione), il nodo login (facoltativo) e il nodo di calcolo (worker). **Suggerimento** Per aiutarti a convalidare questi due file JSON, il team di HyperPod assistenza fornisce uno script di convalida,. [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) Per ulteriori informazioni, consulta [Convalida dei file di configurazione JSON prima di creare un cluster Slurm su HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md). ![\[Confronto diretto tra file .json.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod-lifecycle-slurm-config.png) ***Figura:** Confronto diretto tra la configurazione per la creazione di HyperPod cluster e quella `create_cluster.json` per `provisiong_params.json` Slurm. Il numero di gruppi di istanze in `create_cluster.json` deve corrispondere al numero di nodi che intendi configurare come nodi Slurm. Nel caso dell'esempio in figura, tre nodi Slurm verranno configurati su un HyperPod cluster di tre gruppi di istanze. È necessario assegnare i gruppi di istanze del HyperPod cluster ai nodi Slurm specificando di conseguenza i nomi dei gruppi di istanze.* 1. `resource_config.json`— Durante la creazione del cluster, lo `lifecycle_script.py` script viene scritto in modo da aspettarsi un file da. `resource_config.json` HyperPod Questo file contiene informazioni sul cluster, ad esempio i tipi di istanze e gli indirizzi IP. Quando esegui l'`CreateCluster`API, HyperPod crea un file di configurazione delle risorse in `/opt/ml/config/resource_config.json` base al `create_cluster.json` file. Il percorso del file viene salvato nella variabile di ambiente denominata `SAGEMAKER_RESOURCE_CONFIG_PATH`. **Importante** Il `resource_config.json` file viene generato automaticamente dalla HyperPod piattaforma e NON è necessario crearlo. Il codice seguente, che mostra un esempio del file `resource_config.json` generato dalla creazione del cluster in base al file `create_cluster.json` della fase precedente, ti aiuta a capire cosa succede nel backend e come è fatto un file `resource_config.json` generato automaticamente. ``` { "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`— Questo è lo script Python principale che esegue collettivamente gli script del ciclo di vita configurando Slurm sul cluster durante il provisioning. HyperPod Questo script legge `provisioning_parameters.json` e `resource_config.json` nei percorsi specificati o identificati in `on_create.sh`, passa le informazioni pertinenti a ogni script del ciclo di vita e quindi esegue in ordine gli script del ciclo di vita. Gli script del ciclo di vita sono un set di script che offre la massima flessibilità di personalizzazione e consente di installare pacchetti software e impostare le configurazioni necessarie o personalizzate durante la creazione di cluster, ad esempio la configurazione di Slurm, la creazione di utenti e l’installazione di Conda o Docker. [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)Lo script di esempio è pronto per eseguire altri script del ciclo di vita di base nel repository, come l'avvio di 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), il montaggio di Amazon FSx for Lustre () e la configurazione di MariaDB accounting () [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)e RDS accounting (). [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) Puoi anche aggiungere altri script, impacchettarli nella stessa directory e aggiungere righe di codice per consentire l'esecuzione degli script. `lifecycle_script.py` HyperPod *Per ulteriori informazioni sugli script del ciclo di vita di base, consulta anche gli script del ciclo di [vita 3.1 nell'archivio Awsome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#31-lifecycle-scripts). GitHub * **Nota** HyperPod viene eseguito [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) su ogni istanza di un cluster e l'AMI dispone di pacchetti software preinstallati che rispettano le compatibilità tra essi e le funzionalità. HyperPod Tieni presente che se reinstalli uno qualsiasi dei pacchetti preinstallati, sei responsabile dell'installazione dei pacchetti compatibili e tieni presente che alcune HyperPod funzionalità potrebbero non funzionare come previsto. Oltre alle configurazioni predefinite, nella cartella [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) sono disponibili altri script per l’installazione dei software seguenti. Il file `lifecycle_script.py` è già pronto per includere righe di codice per l’esecuzione degli script di installazione, quindi consulta le indicazioni seguenti per cercare tali righe e rimuovi i commenti per attivarle. 1. Le righe di codice seguenti servono per l’installazione di [Docker](https://www.docker.com/), [Enroot](https://github.com/NVIDIA/enroot) e [Pyxis](https://github.com/NVIDIA/pyxis). Questi pacchetti sono necessari per eseguire i container Docker su un cluster Slurm. Per abilitare questa fase di installazione, imposta il parametro `enable_docker_enroot_pyxis` su `True` nel file [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). ``` # 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. Puoi integrare il tuo HyperPod cluster con [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) e [Amazon Managed](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) Grafana per esportare i parametri relativi al cluster e ai nodi HyperPod del cluster nelle dashboard di Amazon Managed Grafana. Per esportare le metriche e utilizzare la [dashboard Slurm](https://grafana.com/grafana/dashboards/4323-slurm-dashboard/), la [dashboard NVIDIA DCGM Exporter](https://grafana.com/grafana/dashboards/12239-nvidia-dcgm-exporter-dashboard/) e la [dashboard delle metriche EFA](https://grafana.com/grafana/dashboards/20579-efa-metrics-dev/) su Grafana gestito da Amazon, devi installare lo [strumento di esportazione Slurm per Prometheus](https://github.com/vpenso/prometheus-slurm-exporter), lo [strumento di esportazione NVIDIA DCGM](https://github.com/NVIDIA/dcgm-exporter) e lo [strumento di esportazione di nodi EFA](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/3.efa-node-exporter/README.md). Per ulteriori informazioni sull’installazione dei pacchetti di esportazione e sull’utilizzo delle dashboard Grafana in uno spazio di lavoro Grafana gestito da Amazon, consulta [SageMaker HyperPod monitoraggio delle risorse del cluster](sagemaker-hyperpod-cluster-observability-slurm.md). Per abilitare questa fase di installazione, imposta il parametro `enable_observability` su `True` nel file [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). ``` # 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. Assicurati di caricare tutti i file e gli script di configurazione della **Fase 2** nel bucket S3 fornito nella richiesta `CreateCluster` della **Fase 1**. Ad esempio, presupponi che `create_cluster.json` contenga quanto segue: ``` "LifeCycleConfig": { "SourceS3URI": "s3://sagemaker-hyperpod-lifecycle/src", "OnCreate": "on_create.sh" } ``` Di conseguenza, `"s3://sagemaker-hyperpod-lifecycle/src"` dovrebbe contenere `on_create.sh`, `lifecycle_script.py`, `provisioning_parameters.json` e tutti gli altri script di configurazione. Supponi di aver preparato i file in una cartella locale come segue. ``` └── lifecycle_files // your local folder ├── provisioning_parameters.json ├── on_create.sh ├── lifecycle_script.py └── ... // more setup scrips to be fed into lifecycle_script.py ``` Per caricare i file, utilizza il comando S3 come segue. ``` aws s3 cp --recursive ./lifecycle_scripts s3://sagemaker-hyperpod-lifecycle/src ``` # Quali configurazioni particolari gestisce nei file di configurazione Slurm HyperPod Quando crei un cluster Slurm su HyperPod, l' HyperPod agente configura [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html)i file [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html)and `/opt/slurm/etc/` per gestire il cluster Slurm in base alla richiesta di creazione del cluster e agli script HyperPod del ciclo di vita. L'elenco seguente mostra quali parametri specifici l'agente gestisce e sovrascrive. HyperPod **Importante** Si consiglia vivamente di **non** modificare questi parametri gestiti da HyperPod. + In [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html), HyperPod imposta i seguenti parametri di base: `ClusterName``SlurmctldHost`,`PartitionName`, e`NodeName`. Inoltre, per abilitare la [Ripristino automatico dei nodi e ripristino automatico](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) funzionalità, HyperPod richiede i `SchedulerParameters` parametri `TaskPlugin` e impostati come segue. Per impostazione predefinita, l' HyperPod agente imposta questi due parametri con i valori richiesti. ``` TaskPlugin=task/none SchedulerParameters=permit_job_expansion ``` + In [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html), HyperPod gestisce `NodeName` i nodi GPU. # Slurm registra le rotazioni SageMaker HyperPod fornisce la rotazione automatica dei log dei daemon Slurm per aiutare a gestire l'utilizzo dello spazio su disco e mantenere le prestazioni del sistema. La rotazione dei log è fondamentale per evitare che i log consumino uno spazio eccessivo su disco e garantire un funzionamento ottimale del sistema archiviando e rimuovendo automaticamente i vecchi file di registro mantenendo al contempo le informazioni di registrazione recenti. Le rotazioni dei log di Slurm sono abilitate per impostazione predefinita quando si crea un cluster. ## Come funziona la rotazione dei log Se abilitata, la configurazione di rotazione dei log: + Monitora tutti i file di registro Slurm con l'estensione `.log` situata nella `/var/log/slurm/` cartella sui nodi controller, login e calcolo. + Ruota i log quando raggiungono una dimensione di 50 MB. + Mantiene fino a due file di registro ruotati prima di eliminarli. + Invia SIGUSR2 il segnale ai demoni Slurm (`slurmctld`, `slurmd` e) dopo la rotazione. `slurmdbd` ## Elenco dei file di registro ruotati I log di Slurm si trovano nella directory. `/var/log/slurm/` La rotazione dei log è abilitata per tutti i file corrispondenti. `/var/log/slurm/*.log` Quando si verifica una rotazione, i file ruotati hanno suffissi numerici (ad esempio). `slurmd.log.1` L'elenco seguente non è esaustivo ma mostra alcuni dei file di registro critici che ruotano automaticamente: + `/var/log/slurm/slurmctld.log` + `/var/log/slurm/slurmd.log` + `/var/log/slurm/slurmdb.log` + `/var/log/slurm/slurmrestd.log` ## Abilita o disabilita la rotazione dei log È possibile controllare la funzionalità di rotazione dei log utilizzando il `enable_slurm_log_rotation` parametro nello `config.py` script degli script del ciclo di vita del cluster, come illustrato nell'esempio seguente: ``` class Config: # Set false if you want to disable log rotation of Slurm daemon logs enable_slurm_log_rotation = True # Default value ``` Per disabilitare la rotazione dei log, imposta il parametro su`False`, come mostrato nell'esempio seguente: ``` enable_slurm_log_rotation = False ``` **Nota** Gli script del ciclo di vita vengono eseguiti su tutti i nodi Slurm (controller, login e nodi di calcolo) durante la creazione del cluster. Vengono eseguiti anche su nuovi nodi quando vengono aggiunti al cluster. L'aggiornamento delle configurazioni di rotazione dei log deve essere eseguito manualmente dopo la creazione del cluster. La configurazione della rotazione dei log è memorizzata in`/etc/logrotate.d/sagemaker-hyperpod-slurm`. Si consiglia di mantenere abilitata la rotazione dei log per evitare che i file di registro consumino troppo spazio su disco. Per disabilitare la rotazione dei log, elimina il `sagemaker-hyperpod-slurm` file o commentane il contenuto aggiungendolo `#` all'inizio di ogni riga del `sagemaker-hyperpod-slurm` file. ## Impostazioni predefinite di rotazione dei registri Le seguenti impostazioni vengono configurate automaticamente per ogni file di registro ruotato: | Impostazione | Valore | Description | | --- | --- | --- | | rotate | 2 | Numero di file di registro ruotati da conservare | | size | 50 MB | Dimensione massima prima della rotazione | | copytruncate | abilitato | Copia e tronca il file di registro originale | | compress | disabled | I log ruotati non vengono compressi | | missingok | abilitato | Nessun errore se manca il file di registro | | notifempty | abilitato | Non ruota i file vuoti | | noolddir | abilitato | I file ruotati rimangono nella stessa directory | # Montaggio di Amazon FSx for Lustre e Amazon FSx for OpenZFS su un cluster HyperPod Per montare un file system condiviso Amazon FSx for Lustre sul tuo HyperPod cluster, configura quanto segue. 1. Utilizza il tuo Amazon VPC. 1. Affinché le istanze del HyperPod cluster comunichino all'interno del tuo VPC, assicurati di associarle [Configurazione SageMaker HyperPod con un Amazon VPC personalizzato](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc) al ruolo IAM per. SageMaker HyperPod 1. In `create_cluster.json`, includi le informazioni sul VPC seguenti. ``` "VpcConfig": { "SecurityGroupIds": [ "string" ], "Subnets": [ "string" ] } ``` Per ulteriori suggerimenti sulla configurazione di Amazon VPC, consulta [Prerequisiti per l'utilizzo SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md). 1. Per completare la configurazione di Slurm con Amazon FSx for Lustre, puoi utilizzare uno dei seguenti approcci. Puoi trovare le FSx informazioni di Amazon dalla console Amazon FSx for Lustre nel tuo account o eseguendo il seguente AWS CLI comando,`aws fsx describe-file-systems`. **Opzione A: configurazione basata su API (consigliata)** Specificate la FSx configurazione Amazon direttamente nel payload dell' CreateCluster API utilizzando `InstanceStorageConfigs` all'interno di ogni gruppo di istanze. Questo approccio supporta sia FSx Lustre che OpenZFS e consente FSx la configurazione. per-instance-group FSx ``` "InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx", "MountName": "1abcdefg" } } ] ``` FSx Per OpenZFS, usa invece: `FsxOpenZfsConfig` ``` "InstanceStorageConfigs": [ { "FsxOpenZfsConfig": { "DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx-openzfs" } } ] ``` Per ulteriori dettagli, consulta [Guida introduttiva all' SageMaker HyperPod uso della AWS CLI](sagemaker-hyperpod-quickstart.md). **Opzione B: configurazione precedente** Specificare il nome Amazon FSx DNS e il nome di FSx montaggio Amazon `provisioning_parameters.json` come mostrato nella figura nella [Script del ciclo di vita di base forniti da HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) sezione. ``` "fsx_dns_name": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com", "fsx_mountname": "1abcdefg" ``` # Convalida dei file di configurazione JSON prima di creare un cluster Slurm su HyperPod Per convalidare i file di configurazione JSON prima di inviare una richiesta di creazione del cluster, utilizza lo script di convalida della configurazione [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). Questo script analizza e confronta il file JSON di configurazione del HyperPod cluster e il file JSON di configurazione Slurm e identifica eventuali errori di configurazione delle risorse tra i due file e anche tra le risorse Amazon EC2, Amazon VPC e Amazon. FSx Ad esempio, per convalidare i file `create_cluster.json` e `provisioning_parameters.json` della sezione [Script del ciclo di vita di base forniti da HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md), esegui lo script di convalida come segue. ``` python3 validate-config.py --cluster-config create_cluster.json --provisioning-parameters provisioning_parameters.json ``` Di seguito è riportato un esempio di output di una convalida eseguita correttamente. ``` ✔️ 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 ``` # Convalida del runtime prima di eseguire carichi di lavoro di produzione su un cluster Slurm HyperPod Per controllare il runtime prima di eseguire qualsiasi carico di lavoro di produzione su un cluster Slurm HyperPod, usa lo script di convalida del runtime. [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) Questo script verifica se il cluster Slurm ha tutti i pacchetti installati per l'esecuzione di Docker, se il cluster ha un file system montato correttamente FSx per Lustre e una directory utente che condivide il file system e se il demone Slurm è in esecuzione su tutti i nodi di calcolo. Per eseguire lo script su più nodi contemporaneamente, utilizza `srun` come mostrato nel comando di esempio seguente per eseguire lo script su un cluster Slurm di 8 nodi. ``` # The following command runs on 8 nodes srun -N 8 python3 hyperpod-precheck.py ``` **Nota** Per ulteriori informazioni sullo script di convalida, ad esempio sulle funzioni di convalida del runtime fornite dallo script e sulle linee guida per risolvere i problemi che non superano le convalide, consulta [Convalida del runtime prima di eseguire carichi](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#35-runtime-validation-before-running-workloads) di lavoro nell'* GitHub archivio Awsome Distributed Training*. # Sviluppo interattivo di script del ciclo di vita su un nodo del cluster HyperPod Questa sezione spiega come sviluppare in modo interattivo script del ciclo di vita senza creare ed eliminare ripetutamente un cluster. HyperPod 1. Crea un HyperPod cluster con gli script del ciclo di vita di base. 1. Accedi a un nodo del cluster. 1. Sviluppa uno script (`configure_xyz.sh`) modificandolo ed eseguendolo ripetutamente sul nodo. 1. HyperPod esegue gli script del ciclo di vita come utente root, quindi si consiglia di eseguirli `configure_xyz.sh` come utente root durante lo sviluppo per assicurarsi che lo script venga testato nelle stesse condizioni durante l'esecuzione da. HyperPod 1. Integra lo script in `lifecycle_script.py` aggiungendo una riga di codice simile alla seguente. ``` ExecuteBashScript("./utils/configure_xyz.sh").run() ``` 1. Carica gli script del ciclo di vita aggiornati nel bucket S3 utilizzato all’inizio per caricare gli script del ciclo di vita di base. 1. Prova la versione integrata di `lifecycle_script.py` creando un nuovo cluster. HyperPod Puoi anche utilizzare la sostituzione manuale delle istanze per testare gli script del ciclo di vita aggiornati creando nuove istanze. Per istruzioni dettagliate, consulta Sostituire [manualmente](https://docs.aws.amazon.com//sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.html#sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance-replace) un nodo. Nota che solo i nodi di lavoro sono sostituibili.