View a markdown version of this page

Guida introduttiva all'utilizzo di SageMaker HyperPod AWS CLI - Amazon SageMaker AI
Concetti chiaveCreazione di un clusterConnect al clusterEliminazione del cluster e pulizia delle risorseArgomenti correlati

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 elaborazione, 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 descrive i concetti di configurazione di base per la creazione di un SageMaker HyperPod cluster Slurm. La comprensione di questi concetti vi aiuterà a fare scelte consapevoli durante la configurazione del cluster, ma se volete iniziare subito, potete passare direttamente a questa pagina Creazione di un cluster e farvi riferimento 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)?

  2. 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 SlurmConfig su ciascun gruppo di istanze e a livello di cluster. Orchestrator.Slurm Questo è l'approccio consigliato per i nuovi cluster. Fornisce un'unica fonte di verità, convalida integrata e rilevamento delle deviazioni nella configurazione delle partizioni senza file aggiuntivi da gestire. In alternativa, puoi utilizzare un provisioning_parameters.json file legacy archiviato in Amazon S3 per la retrocompatibilità con i cluster esistenti. Per i 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, ometti LifeCycleConfig completamente e HyperPod automaticamente configura i nodi 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 filesystem condiviso ad alte prestazioni per i dati di addestramento, 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 processi) e uno o più nodi di elaborazione (che eseguono i lavori). Facoltativamente, puoi 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, assegni a ciascun gruppo di istanze il ruolo Slurm utilizzandoSlurmConfig, specificando se il gruppo funge da controller, login o nodo di elaborazione. I gruppi di calcolo sono inoltre mappati su una o più partizioni Slurm, che fungono da code logiche che organizzano la pianificazione dei lavori su diversi set di nodi.

A livello di cluster, Orchestrator.Slurm controlla come HyperPod gestisce la configurazione delle partizioni in. slurm.conf Scegliete una strategia che determini se HyperPod è l'unica fonte di riferimento per la topologia delle partizioni, se sovrascrive le modifiche manuali o se unisce la API-defined configurazione alle 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 essere esattamente un gruppo di istanze. Controller
PartitionNames Condizionale. Nomi delle partizioni Slurm. Obbligatorio per il tipo di Compute nodo; non consentito per o. Controller Login

Orchestrator.Slurm(livello di cluster):

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

SlurmConfigStrategydetermina come HyperPod gestisce le mappature da partizione a nodo nel nodo controller. slurm.conf Quando crei o aggiorni un cluster, HyperPod scrive la configurazione della partizione in slurm.conf base a quella definita in ciascun gruppo di istanze, mappando i SlurmConfig gruppi di istanze di calcolo alle partizioni loro assegnate e registrando i controller e i nodi di accesso con i ruoli Slurm appropriati.

La strategia scelta controlla cosa succede quando la configurazione della partizione viene modificata al di fuori dell'API, ad esempio da un amministratore che modifica il file direttamente sul nodo del controller. slurm.conf WithManaged, HyperPod considera l'API come l'unica fonte di informazioni e rileva e blocca gli aggiornamenti in caso di slurm.conf anomalie sul disco. ConOverwrite, HyperPod impone la API-defined configurazione al controller, eliminando qualsiasi modifica manuale apportata. slurm.conf Ciò è utile per il ripristino dopo una modifica involontaria. WithMerge, HyperPod conserva le modifiche manuali slurm.conf e le unisce alla configurazione dell'API, offrendo agli utenti esperti la flessibilità necessaria per mantenere impostazioni personalizzate insieme alle partizioni. slurm.conf API-managed

Strategia Rilevamento della deriva delle partizioni Modifiche manuali Caso d’uso
Managed (predefinito) Attivato; blocca gli aggiornamenti se viene rilevata una deriva Non supportata Unica fonte di verità
Overwrite Disabilitato Sovrascritto durante l'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 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 del nodo. Per informazioni dettagliate, vedi SageMaker HyperPod Configurazione Slurm.

Opzioni di configurazione del ciclo di vita del nodo

Quando crei un cluster SageMaker HyperPod Slurm, scegli come fornire i 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.

Solo con la AMI-based configurazione, si omette completamente. LifeCycleConfig HyperPod configura automaticamente i nodi utilizzando la AMI-based configurazione, impostando 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 Extension, 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 storage aggiuntivi, senza gestire il provisioning di base.

Con l'opzione Personalizzato, lo specifichi LifeCycleConfig insieme OnCreate a un SourceS3Uri riferimento allo script del ciclo di vita completo impostato 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 su quando si avvia Slurm.

Opzione del ciclo di vita del nodo È necessario un bucket Amazon S3? Script da caricare? LifeCycleConfig nell'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 e i cluster Slurm che utilizzano Continuous NodeProvisioningMode continuano a richiedere LifeCycleConfig con e su ogni gruppo di istanze. OnCreate SourceS3Uri

Nota

OnCreatee OnInitComplete si 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 dati di addestramento, checkpoint dei modelli e 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 filesystem FSx risiedono nel VPC, quindi è necessaria una configurazione VPC personalizzata () quando si utilizza FSx. VpcConfig

La configurazione FSx funziona con tutte e tre le opzioni di configurazione del ciclo di vita dei nodi. Quando si utilizza AMI-based la configurazione oOnInitComplete, HyperPod gestisce automaticamente il montaggio 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"
        }
    }
]
Campo Description
DnsName Obbligatorio. Il nome DNS del filesystem 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 filesystem FSx for 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 for 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 Per ulteriori informazioni sulla configurazione di FSx, vedere. Prerequisiti per l'utilizzo SageMaker HyperPod

Creazione di un cluster

Questa sezione illustra la creazione di un cluster utilizzando ciascuna delle opzioni di configurazione del ciclo di vita dei tre 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 AMI-based configurazione. Non richiede script o bucket Amazon S3 e offre un cluster completamente funzionale 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 AmazonSageMakerClusterInstanceRolePolicy in. 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 Amazon S3. SageMaker HyperPod configura automaticamente i nodi 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 incorporati nell'AMI, quindi non è richiesto l'accesso a Internet durante il provisioning.

La tabella seguente elenca le funzionalità incluse nella AMI-based configurazione:

Funzionalità Description
demoni SlurmController e daemon di calcolo sono stati avviati automaticamente
DockerContainer runtime per la creazione e l'esecuzione di contenitori ML
EnrootEsecuzione di container senza root per carichi di lavoro Slurm
PyxisPlugin Slurm per l'integrazione dei container
Contabilità SlurmConfigura la contabilità dei lavori di Slurm per tenere traccia della cronologia dei lavori e del consumo di risorse
MariaDBImplementa MariadB sul nodo controller come database di supporto per la contabilità Slurm
Generazione di chiavi SSHCoppia di chiavi generata per l'utente predefinito di Ubuntu
Propagazione SSHCredenziali utente propagate tra i nodi di elaborazione per lavori multinodo
Rotazione dei log di SlurmPreviene il sovraccarico dei log e i problemi di riempimento del disco
Configurazione della home directoryLa home directory degli utenti 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 no LifeCycleConfig è specificato in ogni gruppo di istanze.

    La topologia Slurm è definita tramite SlurmConfig ogni gruppo di istanze: my-controller-group viene assegnato il Controller ruolo (viene eseguitoslurmctld), 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" ensure HyperPod è l'unica fonte di verità per la configurazione delle partizioni. Il gruppo di lavoro include un file system FSx for Lustre /fsx montato per lo storage VpcConfig condiviso ed è specificato a livello di cluster come richiesto per FSx.

    Suggerimento

    Se esegui il test senza FSx, puoi omettere InstanceStorageConfigs e rimuovere FsxLustreConfig VpcConfig dalla richiesta. FSx non è necessario per la creazione di cluster, ma è consigliato per carichi di lavoro ML di produzione.

  2. Crea il cluster:

    aws sagemaker create-cluster \
    --cli-input-json file://create_cluster.json

  3. 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 diventaInService, procedi a. Connect al cluster

Opzione B: estendere la AMI-based configurazione con OnInitComplete

Utilizza questa opzione quando hai bisogno di personalizzazioni oltre alla AMI-based configurazione, come agenti di monitoraggio, LDAP/SSSD integrazione o supporti di storage 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 degli script di estensione dal repository Awsome Distributed Training

    La cartella 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 funzionalità multiple, 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 ogni funzionalità. Per utilizzarlo, carica l'intera cartella Extensions nel tuo bucket Amazon S3 e specifica run_extensions.sh come script: OnInitComplete

    s3://<bucket>/<prefix>/
|-- run_extensions.sh          (OnInitComplete target)
|-- detect-node/               (node type detection utility)
|-- add-users/                 (user management scripts + config)
|-- observability/             (observability scripts + config)

    All'internorun_extensions.sh, abilita o disabilita ogni funzionalità impostando il flag corrispondente:

    ENABLE_ADD_USERS="true"
ENABLE_OBSERVABILITY="true"

    Il file di configurazione di ogni 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.

  2. Caricamento 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/

  3. 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. OnCreatee OnInitComplete non possono essere utilizzati insieme sullo stesso gruppo di istanze.

    Suggerimento

    È possibile combinare diverse opzioni all'interno di un cluster. Ad esempio, utilizzate la AMI-based configurazione solo sul controller e OnInitComplete sui worker.

    La topologia Slurm è la stessa dell'Opzione A. Ogni gruppo di istanze SlurmConfig definisce il ruolo del nodo e l'assegnazione della partizione ed SlurmConfigStrategy: "Managed" è impostato a livello di cluster. L'unica differenza è l'aggiunta di LifeCycleConfig withOnInitComplete, che indica di eseguire lo script di estensione dopo il HyperPod completamento della AMI-based configurazione su ciascun nodo. Per aggiungere FSx, includi FsxLustreConfig o FsxOpenZfsConfig includi i gruppi di istanze pertinenti e aggiungilo VpcConfig a livello di cluster, come descritto in. InstanceStorageConfigs Configurazione FSx e VPC

  4. Crea il cluster:

    aws sagemaker create-cluster \
    --cli-input-json file://create_cluster.json

  5. Controlla lo stato:

    aws sagemaker describe-cluster --cluster-name my-hyperpod-cluster

    ConOnInitComplete, la risposta viene visualizzata OnInitComplete inLifeCycleConfig. 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 diventaInService, procedi a. Connect al cluster

Opzione C: controllo completamente personalizzato con OnCreate (avanzato)

Utilizzate questa opzione quando avete bisogno del controllo completo sul provisioning, inclusa l'installazione del software, la modifica dell'infrastruttura e la decisione su quando avviare Slurm. ConOnCreate, 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 migrare alla modalità personalizzata in un secondo momento.

  1. Prepara e carica gli script del ciclo di vita su Amazon S3. Se parti da zero, usa gli script di esempio dal repository Awsome Distributed Training: GitHub 

    git clone https://github.com/aws-samples/awsome-distributed-training/
cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config

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

  2. 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 AMI-based la configurazione ed eseguire invece on_create.sh lo script. Gli script sono responsabili dell'intera sequenza di provisioning, inclusa l'installazione del software, la configurazione di Slurm e l'avvio dei demoni Slurm. Per aggiungere FSx, includi FsxLustreConfig o FsxOpenZfsConfig includi i gruppi di istanze pertinenti e aggiungilo VpcConfig a livello di cluster, come descritto in. InstanceStorageConfigs Configurazione FSx e VPC

  3. Crea il cluster:

    aws sagemaker create-cluster \
    --cli-input-json file://create_cluster.json

  4. Controlla lo stato:

    aws sagemaker describe-cluster --cluster-name my-hyperpod-cluster

    ConOnCreate, la risposta viene visualizzata OnCreate inLifeCycleConfig. 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 diventaInService, procedi a. Connect al cluster

Errori di convalida comuni

Errore Risoluzione
«Il cluster deve averne esattamente uno InstanceGroup con 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 o Slurm Continuous. NodeProvisioningMode La configurazione opzionale del ciclo di vita dei nodi non è supportata.
«OnCreate e OnInitComplete in si LifeCycleConfig escludono a vicenda...» Rimuovi uno dei due o. OnCreate OnInitComplete Non è possibile specificare entrambi.
«ad LifeCycleConfig esempio il gruppo è incompleto...» Quando 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 il gruppo viene fornito ma non contiene alcuna configurazione...» Specificare SourceS3Uri con OnCreate o OnInitComplete o omettere LifeCycleConfig completamente.

Connect al cluster

Dopo che lo stato del cluster diventa 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

  2. Connect tramite AWS Systems Manager Session Manager:

    aws ssm start-session \
    --target sagemaker-cluster:my-hyperpod-cluster_my-login-group-i-0abc123def456789b \
    --region us-west-2

  3. 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 di carichi di lavoro ML, consulta. Lavori su 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 formazione, 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.