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à.
# Guida introduttiva all'utilizzo di SageMaker HyperPod AWS CLI
Il seguente tutorial mostra come creare un nuovo SageMaker HyperPod cluster con Slurm tramite i [AWS CLI comandi per. SageMaker HyperPod ](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-cli) Alla fine di questo tutorial, avrai un cluster Slurm funzionante con un nodo controller, un nodo di accesso e un gruppo di lavoro di calcolo, pronto per pianificare ed eseguire carichi di lavoro ML. Il tutorial illustra la configurazione della topologia Slurm, le opzioni di configurazione del ciclo di vita dei nodi, lo storage condiviso FSx opzionale e come connettersi al cluster.
Prima di iniziare, assicurati di aver completato [Prerequisiti per l'utilizzo SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md) (VPC, quote, FSx) e [AWS Identity and Access Management per SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md) (ruoli IAM, ruolo di esecuzione con). `AmazonSageMakerClusterInstanceRolePolicy`
## Concetti chiave
Questa sezione illustra i concetti di configurazione principali per la creazione di un SageMaker HyperPod cluster Slurm. La comprensione di questi concetti ti aiuterà a fare scelte informate durante la configurazione del cluster, ma se desideri iniziare subito puoi passare direttamente a questa pagina [Creazione di un cluster](#smcluster-getting-started-slurm-cli-create-cluster) e fare riferimento qui, se necessario.
Quando si crea un Slurm-orchestrated cluster, si effettuano due scelte di configurazione indipendenti:
1. **Configurazione della topologia Slurm**: come viene definita la topologia del cluster Slurm (ruoli dei nodi, partizioni)?
1. **Configurazione del ciclo di vita dei nodi: come vengono forniti e personalizzati i nodi? **
Per la topologia Slurm, questo tutorial utilizza l'approccio di API-driven configurazione, in cui si definiscono i ruoli e le partizioni dei nodi direttamente nella `CreateCluster` richiesta utilizzando ogni gruppo di istanze e a `SlurmConfig` livello di cluster. `Orchestrator.Slurm` Questo è l'approccio consigliato per i nuovi cluster. Fornisce un'unica fonte di verità, convalida integrata e rilevamento della deriva della configurazione delle partizioni senza file aggiuntivi da gestire. In alternativa, puoi utilizzare un `provisioning_parameters.json` file legacy archiviato in Amazon S3 per la compatibilità con le versioni precedenti con i cluster esistenti. Per dettagli sull'approccio legacy, consulta. [SageMaker HyperPod Configurazione Slurm](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration)
Per la configurazione del ciclo di vita dei nodi, SageMaker HyperPod supporta tre opzioni. Nel caso più semplice, si omettono `LifeCycleConfig` completamente i nodi e si configurano HyperPod automaticamente utilizzando la AMI-based configurazione, configurando Slurm e pacchetti essenziali come Docker, Enroot e Pyxis per l'esecuzione di carichi di lavoro ML, senza bisogno di script o bucket Amazon S3. Se hai bisogno di personalizzazioni oltre alla configurazione, puoi fornire uno script di estensione che viene eseguito AMI-based dopo il completamento della configurazione. `OnInitComplete` Per il pieno controllo dell'intera sequenza di provisioning, il `OnCreate` percorso consente agli script di gestire tutto, incluso l'avvio di Slurm.
Per i carichi di lavoro ML, in genere è necessario anche un file system condiviso ad alte prestazioni per l'addestramento dei dati, i checkpoint e le librerie condivise. SageMaker HyperPod supporta Amazon FSx for Lustre e FSx for OpenZFS, configurati per gruppo di istanze tramite. `InstanceStorageConfigs` La configurazione FSx è facoltativa per la creazione di cluster ma consigliata per i carichi di lavoro di produzione.
### Configurazione della topologia Slurm tramite l'API
Tutti gli esempi di questo tutorial utilizzano la configurazione della topologia API-driven Slurm, in cui si definisce la struttura del cluster Slurm direttamente nella richiesta `CreateCluster` API anziché tramite un file di configurazione separato.
Un cluster Slurm richiede almeno un nodo controller (che esegue il `slurmctld` demone e coordina la pianificazione dei lavori) e uno o più nodi di calcolo (che eseguono i lavori). Facoltativamente, è possibile aggiungere un nodo di accesso per fornire agli utenti un punto di accesso dedicato per l'invio e la gestione dei lavori senza accedere direttamente al controller. Nella richiesta API, si assegna a ciascun gruppo di istanze il ruolo Slurm utilizzando`SlurmConfig`, specificando se il gruppo funge da controller, login o nodo di calcolo. I gruppi di calcolo sono inoltre mappati su una o più partizioni Slurm, che fungono da code logiche che organizzano il modo in cui i job vengono pianificati su diversi set di nodi.
A livello di cluster, `Orchestrator.Slurm` controlla come gestisce la configurazione delle partizioni in. HyperPod `slurm.conf` Scegliete una strategia che determini se HyperPod è l'unica fonte di verità per la topologia delle partizioni, se sovrascrive le modifiche manuali o se unisce la API-defined configurazione con le modifiche manuali apportate. Ecco un riferimento per i campi utilizzati.
**SlurmConfig**(per gruppo di istanze):
```
"SlurmConfig": {
"NodeType": "Controller | Login | Compute",
"PartitionNames": ["partition-name"]
}
```
| Campo | Description |
| --- | --- |
| NodeType | Obbligatorio. Il ruolo Slurm per questo gruppo di istanze. Valori validi: Controller, Login, Compute. Deve esserlo esattamente un gruppo di istanze. Controller |
| PartitionNames | Condizionale. Nomi delle partizioni Slurm. Richiesto per il tipo di Compute nodo; non consentito per o. Controller Login |
**Orchestrator.Slurm**(livello di cluster):
```
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed | Overwrite | Merge"
}
}
```
`SlurmConfigStrategy`determina in che modo HyperPod gestisce le mappature tra partizioni e nodi nel nodo del controller. `slurm.conf` Quando si crea o si aggiorna un cluster, HyperPod scrive la configurazione della partizione in `slurm.conf` base a quella definita su ciascun gruppo di istanze, mappando i `SlurmConfig` gruppi di istanze di calcolo alle partizioni assegnate e registrando il controller e i nodi di accesso con i ruoli Slurm appropriati.
La strategia scelta controlla cosa succede quando la configurazione della partizione `slurm.conf` è stata modificata al di fuori dell'API, ad esempio, da un amministratore che modifica il file direttamente sul nodo del controller. Con`Managed`, HyperPod considera l'API come l'unica fonte di verità e rileverà e bloccherà gli aggiornamenti in caso di `slurm.conf` errore su disco. Con`Overwrite`, HyperPod impone la API-defined configurazione al controller, eliminando qualsiasi modifica manuale. `slurm.conf` Ciò è utile per il ripristino da una modifica involontaria. Con`Merge`, HyperPod conserva le modifiche manuali `slurm.conf` e le unisce alla configurazione dell'API, offrendo agli utenti avanzati la flessibilità di mantenere impostazioni personalizzate insieme alle partizioni. `slurm.conf` API-managed
| Strategia | Rilevamento della deriva delle partizioni | Modifiche manuali | Caso d’uso |
| --- | --- | --- | --- |
| Managed (predefinito) | Abilitato; blocca gli aggiornamenti se viene rilevata una deviazione | Non supportata | Unica fonte di verità |
| Overwrite | Disabilitato | Sovrascritto all'aggiornamento | Recupero dalla deriva |
| Merge | Disabilitato | Conservato e unito | Esigenze personalizzate slurm.conf |
**Importante**
Il rilevamento della deriva si applica solo alla configurazione della partizione Slurm in `slurm.conf` (mappature da partizione a nodo definite tramite l'API). Le modifiche ad altre `slurm.conf` impostazioni, come i parametri di pianificazione, i limiti delle risorse o la configurazione contabile, non vengono monitorate e non verranno rilevate o segnalate da. HyperPod
**Nota**
Se preferisci definire la topologia di Slurm utilizzando un `provisioning_parameters.json` file anziché l'API, esci dai gruppi di istanze e `SlurmConfig` dalla richiesta del cluster e `Orchestrator.Slurm` carica il file su Amazon S3 insieme agli script del ciclo di vita dei nodi. Per informazioni dettagliate, vedi [SageMaker HyperPod Configurazione Slurm](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration).
### Opzioni di configurazione del ciclo di vita del nodo
Quando si crea un cluster SageMaker HyperPod Slurm, si sceglie la modalità di provisioning dei nodi di ciascun gruppo di istanze configurando il blocco nella richiesta. `LifeCycleConfig` `CreateCluster` SageMaker HyperPod supporta tre opzioni di configurazione del ciclo di vita dei nodi, ognuna delle quali offre un diverso livello di controllo sul processo di provisioning.
Con la ** sola ** AMI-based configurazione, si omette completamente. `LifeCycleConfig` HyperPod configura automaticamente i nodi utilizzando la AMI-based configurazione, configurando Slurm, installando i pacchetti essenziali e avviando tutti i servizi richiesti. Questo è il percorso più semplice e non richiede bucket o script Amazon S3.
Con l'**opzione ** Estensione, lo specifichi `LifeCycleConfig` insieme `OnInitComplete` a un `SourceS3Uri` riferimento allo script di estensione in Amazon S3. HyperPod esegue prima la AMI-based configurazione completa, quindi esegue lo script. Ciò consente di aggiungere personalizzazioni, come agenti di monitoraggio, integrazione LDAP o supporti di archiviazione aggiuntivi, senza gestire il provisioning di base.
Con l'**opzione ** Personalizzata, lo specifichi `LifeCycleConfig` insieme `OnCreate` a un riferimento al tuo set di script per l'intero `SourceS3Uri` ciclo di vita in Amazon S3. HyperPod non esegue la AMI-based configurazione e non avvia Slurm. I tuoi script possiedono l'intera sequenza di provisioning. Questo ti dà il controllo completo sul software installato, su come è configurato e quando Slurm si avvia.
| Opzione relativa al ciclo di vita del nodo | È necessario un bucket Amazon S3? | Script da caricare? | LifeCycleConfig in API? |
| --- | --- | --- | --- |
| AMI-based solo configurazione (la più semplice) | No | No | Ometti completamente |
| Estensione () OnInitComplete | Sì | Solo il tuo script di estensione | OnInitComplete \+ SourceS3Uri |
| Personalizzato (OnCreate) | Sì | Set di script per l'intero ciclo di vita | OnCreate \+ SourceS3Uri |
**Nota**
La configurazione opzionale del ciclo di vita dei nodi è supportata solo per i cluster. Slurm-orchestrated EKS-orchestrated I cluster Amazon continuano a richiedere informazioni `LifeCycleConfig` con `OnCreate` e `SourceS3Uri` su ogni gruppo di istanze.
**Nota**
`OnCreate`e si `OnInitComplete` escludono a vicenda. La specificazione di entrambi sullo stesso gruppo di istanze genera un errore di convalida.
### Configurazione FSx e VPC
Per i carichi di lavoro ML, un file system condiviso ad alte prestazioni è essenziale per archiviare i dati di addestramento, i checkpoint dei modelli e le librerie condivise tra i nodi del cluster. SageMaker HyperPod supporta Amazon FSx for Lustre e FSx for OpenZFS, configurati per gruppo di istanze tramite. `InstanceStorageConfigs` I file system FSx risiedono nel tuo VPC, quindi è necessaria una configurazione VPC personalizzata () quando usi FSx. `VpcConfig`
La configurazione FSx funziona con tutte e tre le opzioni di configurazione del ciclo di vita dei nodi. Quando si utilizza la AMI-based configurazione or`OnInitComplete`, HyperPod gestisce automaticamente il montaggio di FSx. Durante l'utilizzo`OnCreate`, gli script del ciclo di vita sono responsabili del montaggio.
**FSx per Lustre: **
```
"InstanceStorageConfigs": [
{
"FsxLustreConfig": {
"DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com",
"MountPath": "/fsx",
"MountName": "abcdefgh"
}
}
]
```
| Campo | Description |
| --- | --- |
| DnsName | Obbligatorio. Il nome DNS del file system FSx for Lustre. |
| MountPath | Opzionale. Il percorso di montaggio locale sull'istanza. Impostazione predefinita: /fsx |
| MountName | Obbligatorio. Il nome di montaggio del filesystem FSx for Lustre. Trovalo nella console FSx for Lustre o tramite. aws fsx describe-file-systems |
**FSx per OpenZFS: **
```
"InstanceStorageConfigs": [
{
"FsxOpenZfsConfig": {
"DnsName": "fs-0xyz789abc123456.fsx.us-west-2.amazonaws.com",
"MountPath": "/shared"
}
}
]
```
| Campo | Description |
| --- | --- |
| DnsName | Obbligatorio. Il nome DNS del file system FSx per OpenZFS. |
| MountPath | Opzionale. Il percorso di montaggio locale sull'istanza. Impostazione predefinita: /home |
**Nota**
Ogni gruppo di istanze può avere al massimo una configurazione FSx per Lustre e una FSx per OpenZFS. Gruppi di istanze diversi possono montare file system diversi.
**Configurazione VPC ** (richiesta per FSx):
Aggiungi `VpcConfig` a livello di cluster nella tua `CreateCluster` richiesta:
```
"VpcConfig": {
"SecurityGroupIds": ["sg-0abc123def456789a"],
"Subnets": ["subnet-0abc123def456789a"]
}
```
Per ulteriori informazioni sulla configurazione di un VPC, consulta[Prerequisiti per l'utilizzo SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md). Per ulteriori informazioni sulla configurazione di FSx, vedere. [Prerequisiti per l'utilizzo SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md)
## Creazione di un cluster
Questa sezione illustra come creare un cluster utilizzando ciascuna delle tre opzioni di configurazione del ciclo di vita dei nodi descritte in. [Opzioni di configurazione del ciclo di vita del nodo](#smcluster-getting-started-slurm-cli-lifecycle-options) Per la maggior parte degli utenti, consigliamo di iniziare con ** l'opzione A**, solo per la AMI-based configurazione. Non richiede script o bucket Amazon S3 e fornisce un cluster completamente funzionante pronto all'uso. Scegli l'opzione B se devi aggiungere personalizzazioni alla AMI-based configurazione o l'opzione C se hai bisogno del pieno controllo del processo di provisioning.
`ExecutionRole`In tutti gli esempi, fornisci l'ARN del ruolo IAM che hai creato con il managed in. `AmazonSageMakerClusterInstanceRolePolicy` [Prerequisiti per l'utilizzo SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md)
### Opzione A: solo AMI-based configurazione (senza configurazione del ciclo di vita)
Questo è il percorso più semplice. Non sono necessari bucket, script o file di configurazione di Amazon S3. SageMaker HyperPod configura i nodi automaticamente utilizzando la AMI-based configurazione, installando il software essenziale e applicando le configurazioni in modo che il cluster sia pronto per eseguire carichi di lavoro ML immediatamente. Tutti i pacchetti software sono integrati nell'AMI, quindi non è richiesto alcun accesso a Internet durante il provisioning.
La tabella seguente elenca le funzionalità incluse nella AMI-based configurazione:
| Funzionalità | Description |
| --- | --- |
| Demoni Slurm | I controller e i daemon di calcolo si sono avviati automaticamente |
| Docker | Runtime del contenitore per la creazione e l'esecuzione di contenitori ML |
| Enroot | Esecuzione di container senza root per carichi di lavoro Slurm |
| Pyxis | Plugin Slurm per l'integrazione dei container |
| Contabilità Slurm | Configura Slurm Job Accounting per tenere traccia della cronologia dei lavori e del consumo di risorse |
| MariaDB | Implementa MariaDB sul nodo controller come database di supporto per la contabilità di Slurm |
| Generazione di chiavi SSH | Coppia di chiavi generata per l'utente predefinito di ubuntu |
| Propagazione SSH | Credenziali utente propagate tra i nodi di calcolo per processi con più nodi |
| Rotazione dei log di Slurm | Evita il sovraccarico dei log e i problemi di esaurimento del disco |
| Configurazione della home directory | La home directory dell'utente di Ubuntu è montata su un filesystem condiviso |
1. Salva quanto segue come: `create_cluster.json`
```
{
"ClusterName": "my-hyperpod-cluster",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Controller"
},
"ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole",
"InstanceStorageConfigs": [
{
"EbsVolumeConfig": {
"VolumeSizeInGB": 500
}
}
]
},
{
"InstanceGroupName": "my-login-group",
"InstanceType": "ml.m5.4xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Login"
},
"ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole"
},
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.trn1.32xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["partition-1"]
},
"ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole",
"InstanceStorageConfigs": [
{
"FsxLustreConfig": {
"DnsName": "{{fs-0abc123def456789.fsx.us-west-2.amazonaws.com}}",
"MountPath": "/fsx",
"MountName": "{{abcdefgh}}"
}
}
]
}
],
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed"
}
},
"VpcConfig": {
"SecurityGroupIds": ["{{sg-0abc123def456789a}}"],
"Subnets": ["{{subnet-0abc123def456789a}}"]
}
}
```
Notate che su qualsiasi gruppo di istanze `LifeCycleConfig` è specificato no.
La topologia Slurm è definita tramite `SlurmConfig` ogni gruppo di istanze: `my-controller-group` viene assegnato il `Controller` ruolo (viene eseguito`slurmctld`), `my-login-group` funge da `Login` nodo per l'accesso degli utenti ed `worker-group-1` è un `Compute` nodo assegnato `partition-1` per la pianificazione dei processi. A livello di cluster, `SlurmConfigStrategy: "Managed"` assicura HyperPod è l'unica fonte di verità per la configurazione delle partizioni. Il gruppo di lavoro include un file system FSx for Lustre montato `/fsx` per lo storage condiviso ed `VpcConfig` è specificato a livello di cluster come richiesto per FSx.
**Suggerimento**
Se stai eseguendo il test senza FSx, puoi omettere `FsxLustreConfig` e rimuovere la richiesta. `InstanceStorageConfigs` `VpcConfig` FSx non è richiesto per la creazione di cluster, ma è consigliato per i carichi di lavoro ML di produzione.
1. Crea il cluster:
```
aws sagemaker create-cluster \
--cli-input-json {{file://create_cluster.json}}
```
1. Controlla lo stato:
```
aws sagemaker describe-cluster --cluster-name {{my-hyperpod-cluster}}
```
Solo con la AMI-based configurazione, i gruppi di istanze nella risposta non includono un `LifeCycleConfig` blocco. Di seguito è riportato un esempio troncato che mostra il gruppo di istanze del controller:
```
{
"ClusterName": "my-hyperpod-cluster",
"ClusterStatus": "InService",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"SlurmConfig": { "NodeType": "Controller" }
}
]
}
```
Dopo che lo stato è impostato**InService**, procedi a. [Connettiti al tuo cluster](#smcluster-getting-started-slurm-cli-connect)
### Opzione B: Estendi la AMI-based configurazione con OnInitComplete
Usa questa opzione quando hai bisogno di personalizzazioni oltre alla AMI-based configurazione, come agenti di monitoraggio, LDAP/SSSD integrazione o supporti di archiviazione aggiuntivi. SageMaker HyperPod esegue prima AMI-based la configurazione, quindi esegue lo script di estensione.
1. Scrivi il tuo script di estensione. Ad esempio`extend-defaults.sh`:
```
#!/bin/bash
set -e
echo "Running post-initialization customizations..."
# Example: Install a monitoring agent
# apt-get install -y my-monitoring-agent
# Example: Configure LDAP integration
# /opt/custom/setup-ldap.sh
# Example: Mount an additional S3 bucket
# mount-s3 my-data-bucket /mnt/s3-data
echo "Custom extensions complete."
```
**Utilizzo di script di estensione dal repository Awsome Distributed Training**
La cartella [ Extensions ](https://github.com/awslabs/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/Extensions) nel repository Awsome Distributed Training fornisce script di estensione pronti all'uso per attività comuni come aggiungere utenti e abilitare l'osservabilità. Ogni funzionalità è autonoma in una propria directory con il proprio script di punto di ingresso che può essere fornito direttamente come script. `OnInitComplete`
Per i cluster che richiedono più funzionalità, consigliamo di utilizzare lo `run_extensions.sh` script disponibile al livello superiore della cartella Extensions. Questo script orchestra tutti gli script di estensione disponibili e fornisce semplici interruttori booleani per abilitare o disabilitare ciascuna funzionalità. Per utilizzarlo, carica l'intera cartella Extensions nel tuo bucket Amazon S3 e specifica come script: `run_extensions.sh` `OnInitComplete`
```
s3:////
|-- run_extensions.sh (OnInitComplete target)
|-- detect-node/ (node type detection utility)
|-- add-users/ (user management scripts + config)
|-- observability/ (observability scripts + config)
```
All'interno`run_extensions.sh`, abilita o disabilita ciascuna funzionalità impostando il flag corrispondente:
```
ENABLE_ADD_USERS="true"
ENABLE_OBSERVABILITY="true"
```
Il file di configurazione di ciascuna funzionalità abilitata deve essere compilato prima del caricamento su Amazon S3. Fai riferimento al README nella directory di ciascuna funzionalità per i dettagli di configurazione.
1. Carica su Amazon S3 (il percorso del bucket deve iniziare con): `s3://sagemaker-`
```
aws s3 cp extend-defaults.sh \
s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/
```
1. Salva quanto segue come: `create_cluster.json`
```
{
"ClusterName": "my-hyperpod-cluster",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Controller"
},
"LifeCycleConfig": {
"OnInitComplete": "extend-defaults.sh",
"SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/"
},
"ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole",
"InstanceStorageConfigs": [
{
"EbsVolumeConfig": {
"VolumeSizeInGB": 500
}
}
]
},
{
"InstanceGroupName": "my-login-group",
"InstanceType": "ml.m5.4xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Login"
},
"LifeCycleConfig": {
"OnInitComplete": "extend-defaults.sh",
"SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/"
},
"ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole"
},
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.trn1.32xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["partition-1"]
},
"LifeCycleConfig": {
"OnInitComplete": "extend-defaults.sh",
"SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/"
},
"ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole"
}
],
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed"
}
}
}
```
**Importante**
Quando `OnInitComplete` è specificato, `SourceS3Uri` è obbligatorio. `OnCreate`e `OnInitComplete` non possono essere usati insieme sullo stesso gruppo di istanze.
**Suggerimento**
È possibile combinare le opzioni all'interno di un cluster. Ad esempio, utilizza la AMI-based configurazione solo sul controller e `OnInitComplete` sui lavoratori.
La topologia Slurm è la stessa dell'opzione A. Ogni gruppo di istanze ha una `SlurmConfig` definizione del ruolo del nodo e dell'assegnazione della partizione ed `SlurmConfigStrategy: "Managed"` è impostato a livello di cluster. L'unica differenza è l'aggiunta di `LifeCycleConfig` with`OnInitComplete`, che indica di HyperPod eseguire lo script di estensione dopo il completamento della AMI-based configurazione su ogni nodo. Per aggiungere FSx, includi `FsxLustreConfig` o `FsxOpenZfsConfig` aggiungi i gruppi di istanze pertinenti e aggiungili `VpcConfig` a livello di cluster, come descritto in. `InstanceStorageConfigs` [Configurazione FSx e VPC](#smcluster-getting-started-slurm-cli-fsx-vpc)
1. Crea il cluster:
```
aws sagemaker create-cluster \
--cli-input-json {{file://create_cluster.json}}
```
1. Controlla lo stato:
```
aws sagemaker describe-cluster --cluster-name {{my-hyperpod-cluster}}
```
Con`OnInitComplete`, la risposta viene visualizzata `OnInitComplete` in`LifeCycleConfig`. Di seguito è riportato un esempio troncato che mostra il gruppo di istanze del controller:
```
{
"ClusterName": "my-hyperpod-cluster",
"ClusterStatus": "InService",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"SlurmConfig": { "NodeType": "Controller" },
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/",
"OnInitComplete": "extend-defaults.sh"
}
}
]
}
```
Dopo che lo stato è impostato**InService**, procedi a. [Connettiti al tuo cluster](#smcluster-getting-started-slurm-cli-connect)
### Opzione C: controllo personalizzato completo con OnCreate (avanzato)
Usa questa opzione quando hai bisogno del controllo completo sul provisioning, inclusa l'installazione del software, le modifiche all'infrastruttura e la decisione di quando avviare Slurm. Con`OnCreate`, SageMaker HyperPod non esegue la AMI-based configurazione e ** ** non ** ** avvia Slurm automaticamente.
**Nota**
Se sei nuovo SageMaker HyperPod e non hai requisiti di personalizzazione specifici, ti consigliamo di iniziare con l'opzione A o l'opzione B. Puoi sempre passare alla modalità personalizzata in un secondo momento.
1. Prepara e carica gli script del ciclo di vita su Amazon S3. Se parti da zero, utilizza gli script di esempio dal repository Awsome Distributed Training: [ GitHub ](https://github.com/aws-samples/awsome-distributed-training/)
```
git clone https://github.com/aws-samples/awsome-distributed-training/
cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config
```
Carica su Amazon S3 (il percorso del bucket deve iniziare con): `s3://sagemaker-`
```
aws s3 sync . \
s3://sagemaker-{{amzn-s3-demo-bucket}}/lifecycle/src
```
Per ulteriori informazioni sugli script del ciclo di vita, consulta [Personalizzazione dei SageMaker HyperPod cluster utilizzando script del ciclo di vita](sagemaker-hyperpod-lifecycle-best-practices-slurm.md).
1. Salva quanto segue come: `create_cluster.json`
```
{
"ClusterName": "my-hyperpod-cluster",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Controller"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/lifecycle/src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole",
"InstanceStorageConfigs": [
{
"EbsVolumeConfig": {
"VolumeSizeInGB": 500
}
}
]
},
{
"InstanceGroupName": "my-login-group",
"InstanceType": "ml.m5.4xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Login"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/lifecycle/src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole"
},
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.trn1.32xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["partition-1"]
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/lifecycle/src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole"
}
],
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed"
}
}
}
```
La topologia Slurm segue lo stesso `SlurmConfig` schema delle altre opzioni. La differenza fondamentale è con. `LifeCycleConfig` `OnCreate` Questo indica HyperPod di saltare completamente la AMI-based configurazione ed eseguire invece lo `on_create.sh` script. Gli script sono responsabili dell'intera sequenza di provisioning, inclusa l'installazione del software, la configurazione di Slurm e l'avvio dei daemon Slurm. Per aggiungere FSx, includete `FsxLustreConfig` o aggiungete i gruppi di istanze pertinenti e aggiungeteli `FsxOpenZfsConfig` a `InstanceStorageConfigs` livello di cluster, come descritto in. `VpcConfig` [Configurazione FSx e VPC](#smcluster-getting-started-slurm-cli-fsx-vpc)
1. Crea il cluster:
```
aws sagemaker create-cluster \
--cli-input-json {{file://create_cluster.json}}
```
1. Controlla lo stato:
```
aws sagemaker describe-cluster --cluster-name {{my-hyperpod-cluster}}
```
Con`OnCreate`, la risposta viene visualizzata `OnCreate` in`LifeCycleConfig`. Di seguito è riportato un esempio troncato che mostra il gruppo di istanze del controller:
```
{
"ClusterName": "my-hyperpod-cluster",
"ClusterStatus": "InService",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"SlurmConfig": { "NodeType": "Controller" },
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/lifecycle/src",
"OnCreate": "on_create.sh"
}
}
]
}
```
Dopo che lo stato è impostato**InService**, procedi a. [Connettiti al tuo cluster](#smcluster-getting-started-slurm-cli-connect)
### Errori di convalida comuni
| Errore | Risoluzione |
| --- | --- |
| «Il cluster deve averne esattamente uno InstanceGroup con il tipo di nodo Controller» | Assicurati che esattamente un gruppo di istanze abbiaSlurmConfig.NodeType: "Controller" |
| «Le partizioni possono essere assegnate solo ai tipi di nodi di calcolo» | Rimuovi PartitionNames dai nostri gruppi di Controller istanze Login |
| «Le configurazioni FSx sono supportate solo per VPC personalizzati» | Aggiungi VpcConfig alla tua richiesta quando usi FSx |
| «LifeCycleConfig è richiesto per esempio il gruppo...» | Cluster EKS. La configurazione opzionale del ciclo di vita dei nodi non è supportata. |
| «OnCreate e OnInitComplete in si LifeCycleConfig escludono a vicenda...» | Rimuovi uno o. OnCreate OnInitComplete Non è possibile specificare entrambi. |
| «ad LifeCycleConfig esempio il gruppo è incompleto...» | Se OnCreate o OnInitComplete è specificato, SourceS3Uri deve essere fornito anche. |
| «LifeCycleConfig è opzionale ma richiede un'AMI compatibile...» | Esegui UpdateClusterSoftware l'aggiornamento a un'AMI che supporti la configurazione opzionale del ciclo di vita dei nodi. |
| «ad LifeCycleConfig esempio, viene fornito un gruppo ma non contiene alcuna configurazione...» | Specifica SourceS3Uri con OnCreate o OnInitComplete o ometti LifeCycleConfig completamente. |
## Connettiti al tuo cluster
Una volta impostato lo stato del cluster **InService** (in genere da 10 a 15 minuti), connettiti e verifica.
1. Elenca i nodi del cluster per ottenere gli ID delle istanze:
```
aws sagemaker list-cluster-nodes --cluster-name {{my-hyperpod-cluster}}
```
1. Connettiti utilizzando AWS Systems Manager Session Manager:
```
aws ssm start-session \
--target sagemaker-cluster:{{my-hyperpod-cluster}}_{{my-login-group}}-{{i-0abc123def456789b}} \
--region {{us-west-2}}
```
1. Verifica che Slurm sia configurato correttamente:
```
# Check Slurm nodes
sinfo
# Check Slurm partitions
sinfo -p partition-1
# Submit a test job
srun -p partition-1 --nodes=1 hostname
```
Per ulteriori informazioni sull'esecuzione dei carichi di lavoro ML, consulta. [Lavori sui SageMaker HyperPod cluster](sagemaker-hyperpod-run-jobs-slurm.md)
## Eliminazione del cluster e pulizia delle risorse
Dopo il test, elimina il cluster per evitare addebiti continui:
```
aws sagemaker delete-cluster --cluster-name {{my-hyperpod-cluster}}
```
Se hai utilizzato script del ciclo di vita dei nodi (opzione B o opzione C), pulisci il bucket Amazon S3:
```
aws s3 rm s3://sagemaker-{{amzn-s3-demo-bucket}}/{{lifecycle/src}} --recursive
```
Se hai utilizzato solo la AMI-based configurazione (opzione A), non è necessaria alcuna pulizia di Amazon S3 per gli script del ciclo di vita dei nodi.
Se hai eseguito carichi di lavoro di training, verifica anche la presenza di dati o artefatti in Amazon S3, Amazon FSx for Lustre o Amazon Elastic File System ed eliminali per evitare addebiti.
## Argomenti correlati
+ [SageMaker HyperPod Configurazione Slurm](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration)
+ [Personalizzazione dei SageMaker HyperPod cluster utilizzando script del ciclo di vita](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)
+ [Configurazione FSx tramite InstanceStorageConfigs](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-fsx-config)
+ [SageMaker HyperPod Operazioni del cluster Slurm](sagemaker-hyperpod-operate-slurm.md)
+ [Script di estensione per SageMaker HyperPod ](https://github.com/awslabs/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/Extensions)
+ [Personalizzazione dei SageMaker HyperPod cluster utilizzando script del ciclo di vita](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)