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 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 (VPC, quote, FSx) e AWS Identity and Access Management per SageMaker HyperPod (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 e fare riferimento qui, se necessario.

Quando si crea un Slurm-orchestrated cluster, si effettuano due scelte di configurazione indipendenti:

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

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 utilizzandoSlurmConfig, 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"]
}

Orchestrator.Slurm(livello di cluster):

"Orchestrator": {
    "Slurm": {
        "SlurmConfigStrategy": "Managed | Overwrite | Merge"
    }
}

SlurmConfigStrategydetermina 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. ConManaged, HyperPod considera l'API come l'unica fonte di verità e rileverà e bloccherà gli aggiornamenti in caso di slurm.conf errore su disco. ConOverwrite, HyperPod impone la API-defined configurazione al controller, eliminando qualsiasi modifica manuale. slurm.conf Ciò è utile per il ripristino da una modifica involontaria. ConMerge, 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

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.

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 orOnInitComplete, HyperPod gestisce automaticamente il montaggio di FSx. Durante l'utilizzoOnCreate, 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"
        }
    }
]

FSx per OpenZFS:

"InstanceStorageConfigs": [
    {
        "FsxOpenZfsConfig": {
            "DnsName": "fs-0xyz789abc123456.fsx.us-west-2.amazonaws.com",
            "MountPath": "/shared"
        }
    }
]

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, consultaPrerequisiti per l'utilizzo SageMaker HyperPod. Per ulteriori informazioni sulla configurazione di FSx, vedere. Prerequisiti per l'utilizzo SageMaker HyperPod

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

ExecutionRoleIn tutti gli esempi, fornisci l'ARN del ruolo IAM che hai creato con il managed in. AmazonSageMakerClusterInstanceRolePolicy Prerequisiti per l'utilizzo SageMaker HyperPod

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:

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.

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. ConOnCreate, SageMaker HyperPod non esegue la AMI-based configurazione e non avvia Slurm automaticamente.

Errori di convalida comuni

Connettiti al tuo cluster

Una volta impostato lo stato del cluster InService (in genere da 10 a 15 minuti), connettiti e verifica.

Per ulteriori informazioni sull'esecuzione dei carichi di lavoro ML, consulta. Lavori sui SageMaker HyperPod cluster

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