SageMaker HyperPod FAQs - Amazon SageMaker AI

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

SageMaker HyperPod FAQs

Utilizza le seguenti domande frequenti per risolvere i problemi relativi all'utilizzo. SageMaker HyperPod

Perché non riesco a trovare i gruppi di log del mio SageMaker HyperPod cluster in Amazon CloudWatch?

Per impostazione predefinita, i log degli agenti e i registri di avvio delle istanze vengono inviati all'account della HyperPod piattaforma. CloudWatch Nel caso degli script del ciclo di vita degli utenti, i log di configurazione del ciclo di vita vengono inviati all'account dell'utente. CloudWatch

Se utilizzi gli script del ciclo di vita di esempio forniti dal team di HyperPod assistenza, puoi aspettarti di trovare i log di configurazione del ciclo di vita scritti su e non incontrerai questo problema. /var/log/provision/provisioning.log

Tuttavia, se utilizzi percorsi personalizzati per raccogliere i log dal provisioning del ciclo di vita e non riesci a trovare i gruppi di log che appaiono nel tuo account CloudWatch, ciò potrebbe essere dovuto a una mancata corrispondenza tra i percorsi dei file di registro specificati negli script del ciclo di vita e ciò che cerca l' CloudWatch agente in esecuzione sulle istanze del HyperPod cluster. In questo caso, significa che è necessario configurare correttamente gli script del ciclo di vita per inviare i log all' CloudWatch agente e configurare di conseguenza la configurazione dell' CloudWatch agente. Per risolvere il problema, scegli una delle seguenti opzioni.

  • Opzione 1: aggiorna gli script del ciclo di vita per scrivere i log su /var/log/provision/provisioning.log.

  • Opzione 2: aggiorna l' CloudWatch agente per cercare percorsi personalizzati per la registrazione del provisioning del ciclo di vita.

    1. Ogni istanza HyperPod del cluster contiene un file di configurazione CloudWatch dell'agente in formato JSON all'indirizzo. /opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json Nel file di configurazione, trova il nome del campo logs.logs_collected.files.collect_list.file_path. Con l'impostazione predefinita di HyperPod, la coppia chiave-valore dovrebbe essere "file_path": "/var/log/provision/provisioning.log" quella documentata in. Registrazione a SageMaker HyperPod livello di istanza Il seguente frammento di codice mostra l'aspetto del file JSON con la configurazione predefinita. HyperPod

      "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/var/log/provision/provisioning.log", "log_group_name": "/aws/sagemaker/Clusters/[ClusterName]/[ClusterID]", "log_stream_name": "LifecycleConfig/[InstanceGroupName]/{instance_id}", "retention_in_days": -1 } ] } }, "force_flush_interval": 3 }
    2. Sostituisci il valore del nome del campo "file_path" con il percorso personalizzato che utilizzi negli script del ciclo di vita. Ad esempio, se hai configurato gli script del ciclo di vita per la scrittura su /var/log/custom-provision/custom-provisioning.log, aggiorna il valore in modo che abbia la seguente corrispondenza.

      "file_path": "/var/log/custom-provision/custom-provisioning.log"
    3. Riavviare l' CloudWatch agente con il file di configurazione per completare l'applicazione del percorso personalizzato. Ad esempio, il CloudWatch comando seguente mostra come riavviare l' CloudWatch agente con il file di configurazione dell' CloudWatch agente del passaggio 1. Per ulteriori informazioni, vedere anche Risoluzione dei problemi dell' CloudWatch agente.

      sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \ -a fetch-config -m ec2 -s -c \ file:/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json

Quali configurazioni particolari HyperPod gestisce nei file di configurazione di Slurm come e? slurm.confgres.conf

Quando si crea un cluster Slurm su HyperPod, l' HyperPod agente configura gres.confi file slurm.confand /opt/slurm/etc/ per gestire il cluster Slurm in base alla richiesta di creazione del cluster e agli script del ciclo di vita HyperPod . L'elenco seguente mostra quali parametri specifici l'agente gestisce e sovrascrive. HyperPod

Importante

Ti consigliamo vivamente di NON modificare questi parametri gestiti da HyperPod.

  • In slurm.conf, HyperPod imposta i seguenti parametri di base: ClusterNameSlurmctldHost,PartitionName, eNodeName.

    Inoltre, per abilitare la Ripristino automatico dei nodi e ripristino automatico 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 gres.conf, HyperPod gestisce NodeName i nodi GPU.

Come posso eseguire Docker sui nodi Slurm? HyperPod

Per aiutarti a eseguire Docker sui nodi Slurm in esecuzione HyperPod, il team di HyperPod assistenza fornisce script di configurazione che puoi includere come parte della configurazione del ciclo di vita per la creazione di cluster. Per ulteriori informazioni, consultare Script del ciclo di vita di base forniti da HyperPod e Esecuzione di contenitori Docker su un nodo di calcolo Slurm su HyperPod.

Perché il mio lavoro di training parallelo fallisce quando utilizzo NVIDIA Collective Communications Library (NCCL) con Slurm on platform? SageMaker HyperPod

Per impostazione predefinita, il sistema operativo Linux imposta il flag #RemoveIPC=yes. I processi Slurm e mpirun che utilizzano NCCL generano risorse di comunicazione tra processi (IPC) nelle sessioni utente non root. Queste sessioni utente potrebbero disconnettersi durante il processo.

Quando esegui processi con Slurm o mpirun, se systemd rileva che l’utente non è connesso, pulisce le risorse IPC. I processi Slurm e mpirun possono essere eseguiti senza che l’utente sia connesso, ma è necessario disabilitare la pulizia a livello di systemd e riconfigurarla a livello Slurm. Per ulteriori informazioni, consulta Systemd nella documentazione NCCL.

Completa la procedura seguente per disabilitare la pulizia a livello di systemd.

  1. Imposta il flag #RemoveIPC=no nel file /etc/systemd/logind.conf se stai eseguendo job di addestramento che utilizzano Slurm e NCCL.

  2. Per impostazione predefinita, Slurm non pulisce le risorse condivise. Consigliamo di configurare uno script Epilog di Slurm per pulire le risorse condivise. Questa pulizia è utile se hai molte risorse condivise che vuoi eliminare dopo i job di addestramento. Di seguito è riportato un esempio di script.

    #!/bin/bash : <<'SUMMARY' Script: epilog.sh Use this script with caution, as it can potentially delete unnecessary resources and cause issues if you don't use it correctly. Note: You must save this script in a shared in a shared location that is accessible to all nodes in the cluster, such as /fsx volume. Workers must be able to access the script to run the script after jobs. SUMMARY # Define the log directory and create it if it doesn't exist LOG_DIR="/<PLACEHOLDER>/epilogue" #NOTE: Update PLACEHOLDER to be a shared value path, such as /fsx/epilogue. mkdir -p "$LOG_DIR" # Name the log file using the Slurm job name and job ID log_file="$LOG_DIR/epilogue-${SLURM_JOB_NAME}_${SLURM_JOB_ID}.log" logging() { echo "[$(date)] $1" | tee -a "$log_file" } # Slurm epilogue script to clean up IPC resources logging "Starting IPC cleanup for Job $SLURM_JOB_ID" # Clean up shared memory segments by username for seg in $(ipcs -m | awk -v owner="$SLURM_JOB_USER" '$3 == owner {print $2}'); do if ipcrm -m "$seg"; then logging "Removed shared memory segment $seg" else logging "Failed to remove shared memory segment $seg" fi done # Clean up semaphores by username for sem in $(ipcs -s | awk -v user="$SLURM_JOB_USER" '$3 == user {print $2}'); do if ipcrm -s "$sem"; then logging "Removed semaphore $sem" else logging "Failed to remove semaphore $sem" fi done # Clean up NCCL IPC NCCL_IPC_PATH="/dev/shm/nccl-*" for file in $NCCL_IPC_PATH; do if [ -e "$file" ]; then if rm "$file"; then logging "Removed NCCL IPC file $file" else logging "Failed to remove NCCL IPC file $file" fi fi done logging "IPC cleanup completed for Job $SLURM_JOB_ID" exit 0

    Per ulteriori informazioni sul parametro Epilog, consulta la documentazione di Slurm.

  3. Nel file slurm.conf del nodo controller, aggiungi una riga che punti allo script Epilog che hai creato.

    Epilog="/path/to/epilog.sh" #For example: /fsx/epilogue/epilog.sh
  4. Utilizza i comandi seguenti per modificare le autorizzazioni dello script e renderlo eseguibile.

    chown slurm:slurm /path/to/epilog.sh chmod +x /path/to/epilog.sh
  5. Per applicare tutte le modifiche, esegui scontrol reconfigure.

Come posso utilizzare l' NVMe archivio locale di istanze P per avviare contenitori Docker o Enroot con Slurm?

Poiché il volume root predefinito del nodo principale di solito è limitato a un volume EBS da 100 GB, è necessario configurare Docker ed Enroot per utilizzare l'instance store locale. NVMe Per informazioni su come configurare NVMe store e utilizzarlo per l'avvio di contenitori Docker, consulta. Esecuzione di contenitori Docker su un nodo di calcolo Slurm su HyperPod

Come si configurano i gruppi di sicurezza EFA?

Se desideri creare un HyperPod cluster con istanze abilitate per EFA, assicurati di configurare un gruppo di sicurezza per consentire tutto il traffico in entrata e in uscita da e verso il gruppo di sicurezza stesso. Per ulteriori informazioni, consulta la Fase 1: Preparare un gruppo di sicurezza compatibile con EFA nella Amazon EC2 User Guide.

Come posso monitorare i miei HyperPod nodi del cluster? Sono state esportate CloudWatch delle metriche da? HyperPod

Per ottenere una maggiore visibilità sull'utilizzo delle risorse del HyperPod cluster, consigliamo di integrare il HyperPod cluster con Amazon Managed Grafana e Amazon Managed Service for Prometheus. Con varie dashboard Grafana open source e pacchetti di esportazione, puoi esportare e visualizzare le metriche relative alle risorse del cluster. HyperPod Per ulteriori informazioni sulla configurazione SageMaker HyperPod con Amazon Managed Grafana e Amazon Managed Service for Prometheus, consulta. SageMaker HyperPod monitoraggio delle risorse del cluster Tieni presente che SageMaker HyperPod attualmente non supporta l'esportazione di metriche di sistema su Amazon. CloudWatch

Posso aggiungere uno storage aggiuntivo ai HyperPod nodi del cluster? Le istanze del cluster hanno un archivio dell’istanza locale limitato.

Se l’archiviazione delle istanze predefinita è insufficiente per il tuo carico di lavoro, puoi configurare spazio aggiuntivo per ogni istanza. A partire dal rilascio del 20 giugno 2024, puoi aggiungere un volume Amazon Elastic Block Store (EBS) aggiuntivo a ciascuna istanza del cluster. SageMaker HyperPod Tieni presente che questa funzionalità non può essere applicata a gruppi di istanze di SageMaker HyperPod cluster esistenti creati prima del 20 giugno 2024. Puoi utilizzare questa funzionalità applicando patch SageMaker HyperPod ai cluster esistenti creati prima del 20 giugno 2024 e aggiungendovi nuovi gruppi di istanze. Questa funzionalità è pienamente efficace per tutti i SageMaker HyperPod cluster creati dopo il 20 giugno 2024.

Perché i miei nodi di calcolo mostrano lo stato “DOWN” o “DRAINED” dopo un riavvio?

Questo caso si verifica in genere quando i nodi vengono riavviati con sudo reboot invece che con l’interfaccia di controllo di Slurm. Per riavviare correttamente i nodi, utilizza il comando Slurm scontrol reboot nextstate=resume <list_of_nodes>. Questo garantisce che Slurm mantenga un controllo adeguato sullo stato del nodo e riprenda il normale funzionamento dopo il riavvio.

Per le istanze GPU (come NVIDIA P5), questo può accadere anche se il nodo non riesce a completare il processo di avvio entro il limite di tempo predefinito di Slurm (60 secondi). Per risolvere questo problema, aumenta il parametro TimeToResume in slurm.conf fino a 300 secondi. In questo modo, le istanze GPU hanno abbastanza tempo per avviare e inizializzare i driver.

Perché i miei nodi vengono continuamente svuotati a causa di problemi di memoria insufficiente (OOM)?

I problemi di OOM si verificano quando i processi superano la capacità di memoria del nodo. Per evitare il problema, implementa cgroups per imporre limiti di memoria per ogni processo. Così facendo, eviti che un singolo processo influisca sull’intero nodo e migliori l’isolamento e la stabilità.

Configurazione di esempio in slurm.conf:

TaskPlugin=task/cgroup

Configurazione di esempio in cgroup.conf:

CgroupAutomount=yes ConstrainCores=yes CgroupPlugin=autodetect ConstrainDevices=yes ConstrainRAMSpace=yes ConstrainSwapSpace=yes SignalChildrenProcesses=yes MaxRAMPercent=99 MaxSwapPercent=80 MinRAMSpace=100

Per ulteriori informazioni, consulta Control Group in Slurm, Cgroup and PAM-based login control for Slurm compute nodes e Configure Cgroups for Slurm.

Come posso avere la certezza che le risorse siano pulite correttamente dopo il completamento dei processi?

Implementa script Epilog per pulire automaticamente le risorse al completamento dei processi. Le risorse potrebbero non essere cancellate correttamente quando i processi si bloccano inaspettatamente, quando contengono bug che impediscono la normale pulizia o quando i buffer di memoria condivisa (inclusi quelli condivisi tra processi e driver GPU) rimangono allocati.

Gli script Epilog possono eseguire attività, ad esempio la cancellazione della memoria della GPU, la rimozione dei file temporanei e lo smontaggio dei file system. Questi script presentano delle limitazioni quando le risorse non sono allocate esclusivamente a un singolo processo. Per istruzioni dettagliate e script di esempio, consulta il secondo punto della domanda Perché il mio lavoro di training parallelo fallisce quando utilizzo NVIDIA Collective Communications Library (NCCL) con Slurm on platform? SageMaker HyperPod . Per ulteriori informazioni, consulta Enable Slurm epilog script.