Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# SageMaker HyperPod FAQs
Consultez les questions fréquemment posées ci-dessous pour résoudre les problèmes liés à l'utilisation SageMaker HyperPod.
**Topics**
+ [Pourquoi ne puis-je pas trouver les groupes de journaux de mon SageMaker HyperPod cluster sur Amazon CloudWatch ?](#hyperpod-faqs-q1)
+ [Quelles configurations particulières sont HyperPod gérées dans les fichiers de configuration de Slurm tels `slurm.conf` que et ? `gres.conf`](#hyperpod-faqs-q2)
+ [Comment exécuter Docker sur les nœuds Slurm ? HyperPod](#hyperpod-faqs-q3)
+ [Pourquoi ma tâche de formation parallèle échoue-t-elle lorsque j'utilise la bibliothèque de communications collectives NVIDIA (NCCL) avec Slurm sur plateforme ? SageMaker HyperPod](#hyperpod-faqs-q4)
+ [Comment utiliser le NVMe magasin local d'instances P pour lancer des conteneurs Docker ou Enroot avec Slurm ?](#hyperpod-faqs-q5)
+ [Comment configurer des groupes de sécurité EFA ?](#hyperpod-faqs-q6)
+ [Comment surveiller les nœuds de mon HyperPod cluster ? Des CloudWatch métriques sont-elles exportées depuis HyperPod ?](#hyperpod-faqs-q7)
+ [Puis-je ajouter un espace de stockage supplémentaire aux nœuds du HyperPod cluster ? Les instances de cluster disposent d’un espace de stockage d’instances local limité.](#hyperpod-faqs-q8)
+ [Pourquoi mes nœuds de calcul affichent-ils la mention « DOWN » ou « DRAINED » après un redémarrage ?](#hyperpod-faqs-q9)
+ [Pourquoi mes nœuds continuent-ils à être vidés en raison de problèmes de mémoire insuffisante (OOM) ?](#hyperpod-faqs-q10)
+ [Comment puis-je m’assurer que les ressources sont correctement nettoyées une fois les tâches terminées ?](#hyperpod-faqs-q11)
## Pourquoi ne puis-je pas trouver les groupes de journaux de mon SageMaker HyperPod cluster sur Amazon CloudWatch ?
Par défaut, les journaux des agents et les journaux de démarrage des instances sont envoyés au compte de la HyperPod plateforme CloudWatch. Dans le cas de scripts de cycle de vie utilisateur, les journaux de configuration du cycle de vie sont envoyés à celui de votre compte CloudWatch.
Si vous utilisez les [exemples de scripts de cycle](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) de vie fournis par l'équipe de HyperPod service, vous pouvez vous attendre à trouver les journaux de configuration du cycle de vie écrits`/var/log/provision/provisioning.log`, et vous ne rencontrerez pas ce problème.
Toutefois, si vous utilisez des chemins personnalisés pour collecter les journaux issus du provisionnement du cycle de vie et que vous ne trouvez pas les groupes de journaux figurant dans ceux de votre compte CloudWatch, cela peut être dû à des incohérences entre les chemins des fichiers journaux spécifiés dans vos scripts de cycle de vie et ceux recherchés par l' CloudWatch agent exécuté sur les instances de HyperPod cluster. Dans ce cas, cela signifie que vous devez configurer correctement vos scripts de cycle de vie pour envoyer les journaux à l' CloudWatch agent, ainsi que configurer la configuration de l' CloudWatch agent en conséquence. Pour résoudre le problème, choisissez l’une des options suivantes.
+ **Option 1 :** mettez à jour vos scripts de cycle de vie pour écrire les journaux dans `/var/log/provision/provisioning.log`.
+ **Option 2 :** mettez à jour l' CloudWatch agent pour qu'il recherche vos chemins personnalisés pour la journalisation du provisionnement du cycle de vie.
1. Chaque instance de HyperPod cluster contient un fichier de configuration d' CloudWatch agent au format JSON à l'adresse`/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json`. Dans le fichier de configuration, recherchez le nom du champ `logs.logs_collected.files.collect_list.file_path`. Avec la configuration par défaut par HyperPod, la paire clé-valeur doit être `"file_path": "/var/log/provision/provisioning.log"` telle que documentée sur. [Journalisation SageMaker HyperPod au niveau de l'instance](sagemaker-hyperpod-cluster-management-slurm.md#sagemaker-hyperpod-cluster-management-slurm-logging-at-instance-level) L'extrait de code suivant montre à quoi ressemble le fichier JSON avec la configuration HyperPod par défaut.
```
"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
}
```
1. Remplacez la valeur du nom du champ `"file_path"` par le chemin personnalisé que vous utilisez dans vos scripts de cycle de vie. Par exemple, si vous avez configuré vos scripts de cycle de vie pour écrire dans `/var/log/custom-provision/custom-provisioning.log`, mettez à jour la valeur pour qu’elle corresponde à ce qui suit.
```
"file_path": "/var/log/custom-provision/custom-provisioning.log"
```
1. Redémarrez l' CloudWatch agent avec le fichier de configuration pour terminer l'application du chemin personnalisé. Par exemple, la CloudWatch commande suivante montre comment redémarrer l' CloudWatch agent avec le fichier de configuration de l' CloudWatch agent de l'étape 1. Pour plus d'informations, voir également [Résolution des problèmes liés à l' CloudWatch agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html).
```
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
```
## Quelles configurations particulières sont HyperPod gérées dans les fichiers de configuration de Slurm tels `slurm.conf` que et ? `gres.conf`
Lorsque vous créez un cluster Slurm sur HyperPod, l' HyperPod agent configure les [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html)fichiers [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html)et `/opt/slurm/etc/` pour gérer le cluster Slurm en fonction de votre demande de création de cluster et de vos scripts de HyperPod cycle de vie. La liste suivante indique les paramètres spécifiques que l' HyperPod agent gère et remplace.
**Important**
Nous vous recommandons vivement de NE PAS modifier ces paramètres gérés par HyperPod.
+ Dans [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html), HyperPod définit les paramètres de base suivants : `ClusterName``SlurmctldHost`,`PartitionName`, et`NodeName`.
En outre, pour activer la [Restauration automatique des nœuds et reprise automatique](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) fonctionnalité, HyperPod les `SchedulerParameters` paramètres `TaskPlugin` et doivent être définis comme suit. L' HyperPod agent définit ces deux paramètres avec les valeurs requises par défaut.
```
TaskPlugin=task/none
SchedulerParameters=permit_job_expansion
```
+ Dans [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html), HyperPod gère `NodeName` les nœuds GPU.
## Comment exécuter Docker sur les nœuds Slurm ? HyperPod
Pour vous aider à exécuter Docker sur vos nœuds Slurm HyperPod, l'équipe de HyperPod service fournit des scripts de configuration que vous pouvez inclure dans le cadre de la configuration du cycle de vie pour la création de clusters. Pour en savoir plus, consultez [Scripts de cycle de vie de base fournis par HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) et [Exécution de conteneurs Docker sur un nœud de calcul Slurm sur HyperPod](sagemaker-hyperpod-run-jobs-slurm-docker.md).
## Pourquoi ma tâche de formation parallèle échoue-t-elle lorsque j'utilise la bibliothèque de communications collectives NVIDIA (NCCL) avec Slurm sur plateforme ? SageMaker HyperPod
Par défaut, le système d’exploitation Linux définit l’indicateur `#RemoveIPC=yes`. Les tâches Slurm et mpirun qui utilisent NCCL génèrent des ressources de communication inter-processus (IPC) dans le cadre de sessions d’utilisateur non racine. Ces sessions utilisateur peuvent se déconnecter pendant le processus de tâche.
Lorsque vous exécutez des tâches avec Slurm ou mpirun, si `systemd` détecte que l’utilisateur n’est pas connecté, il nettoie les ressources IPC. Les tâches Slurm et mpirun peuvent être exécutées sans que l’utilisateur soit connecté, mais cela nécessite que vous désactiviez le nettoyage au niveau de systemd et que vous le configuriez au niveau Slurm. Pour plus d’informations, consultez [Systemd dans la documentation NCCL](https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/troubleshooting.html#systemd).
Pour désactiver le nettoyage au niveau de systemd, effectuez les opérations suivantes.
1. Définissez l’indicateur `#RemoveIPC=no` dans le fichier `/etc/systemd/logind.conf` si vous exécutez des tâches d’entraînement utilisant Slurm et NCCL.
1. Par défaut, Slurm ne nettoie pas les ressources partagées. Nous vous recommandons de configurer un script d’épilogue Slurm afin de nettoyer les ressources partagées. Ce nettoyage est utile lorsque vous avez de nombreuses ressources partagées et que vous souhaitez les nettoyer après des tâches d’entraînement. Voici un exemple de 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="//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
```
Pour plus d’informations sur le paramètre Epilog, consultez la [documentation Slurm](https://slurm.schedmd.com/slurm.conf.html#OPT_Epilog).
1. Dans le fichier `slurm.conf` provenant du nœud du contrôleur, ajoutez une ligne pour pointer vers le script d’épilogue que vous avez créé.
```
Epilog="/path/to/epilog.sh" #For example: /fsx/epilogue/epilog.sh
```
1. Exécutez les commandes suivantes pour modifier les autorisations du script et le rendre exécutable.
```
chown slurm:slurm /path/to/epilog.sh
chmod +x /path/to/epilog.sh
```
1. Pour appliquer toutes vos modifications, exécutez `scontrol reconfigure`.
## Comment utiliser le NVMe magasin local d'instances P pour lancer des conteneurs Docker ou Enroot avec Slurm ?
Le volume racine par défaut de votre nœud principal étant généralement limité à 100 Go de volume EBS, vous devez configurer Docker et Enroot pour utiliser le stockage d'instance local. NVMe Pour savoir comment configurer le NVMe magasin et l'utiliser pour lancer des conteneurs Docker, consultez[Exécution de conteneurs Docker sur un nœud de calcul Slurm sur HyperPod](sagemaker-hyperpod-run-jobs-slurm-docker.md).
## Comment configurer des groupes de sécurité EFA ?
Si vous souhaitez créer un HyperPod cluster avec des instances compatibles EFA, assurez-vous de configurer un groupe de sécurité pour autoriser tout le trafic entrant et sortant à destination et en provenance du groupe de sécurité lui-même. Pour en savoir plus, consultez [Étape 1 : Préparation d’un groupe de sécurité compatible EFA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-security) dans le *Guide de l’utilisateur Amazon EC2*.
## Comment surveiller les nœuds de mon HyperPod cluster ? Des CloudWatch métriques sont-elles exportées depuis HyperPod ?
Pour améliorer l'observabilité de l'utilisation des ressources de votre HyperPod cluster, nous vous recommandons d'intégrer le HyperPod cluster à Amazon Managed Grafana et à Amazon Managed Service for Prometheus. Grâce à divers tableaux de bord Grafana et packages d'exportation open source, vous pouvez exporter et visualiser les métriques liées aux HyperPod ressources du cluster. Pour en savoir plus sur la configuration SageMaker HyperPod avec Amazon Managed Grafana et Amazon Managed Service for Prometheus, consultez. [SageMaker HyperPod surveillance des ressources du cluster](sagemaker-hyperpod-cluster-observability-slurm.md) Notez que l'exportation des métriques du système vers Amazon n'est SageMaker HyperPod actuellement pas prise en charge CloudWatch.
## Puis-je ajouter un espace de stockage supplémentaire aux nœuds du HyperPod cluster ? Les instances de cluster disposent d’un espace de stockage d’instances local limité.
Si le stockage d’instances par défaut est insuffisant pour votre charge de travail, vous pouvez configurer un stockage supplémentaire par instance. À compter de la [sortie du 20 juin 2024,](sagemaker-hyperpod-release-notes.md#sagemaker-hyperpod-release-notes-20240620) vous pouvez ajouter un volume Amazon Elastic Block Store (EBS) supplémentaire à chaque instance de votre cluster. SageMaker HyperPod Notez que cette fonctionnalité ne peut pas être appliquée aux groupes d'instances de SageMaker HyperPod clusters existants créés avant le 20 juin 2024. Vous pouvez utiliser cette fonctionnalité en appliquant des correctifs aux SageMaker HyperPod clusters existants créés avant le 20 juin 2024 et en y ajoutant de nouveaux groupes d'instances. Cette fonctionnalité est pleinement efficace pour tous les SageMaker HyperPod clusters créés après le 20 juin 2024.
## Pourquoi mes nœuds de calcul affichent-ils la mention « DOWN » ou « DRAINED » après un redémarrage ?
Cela se produit généralement lorsque les nœuds sont redémarrés en utilisant `sudo reboot` plutôt que l’interface de contrôle de Slurm. Pour redémarrer correctement les nœuds, utilisez la commande Slurm `scontrol reboot nextstate=resume `. Cela garantit que Slurm conservera un contrôle correct de l’état des nœuds et reprendra son fonctionnement normal après le redémarrage.
Pour les instances GPU (comme NVIDIA P5), cela peut également se produire si le nœud ne parvient pas à terminer son processus de démarrage dans le délai par défaut de Slurm (60 secondes). Pour résoudre ce problème, augmentez le paramètre `TimeToResume` dans `slurm.conf` à 300 secondes. Cela donne aux instances du GPU suffisamment de temps pour démarrer et initialiser les pilotes.
## Pourquoi mes nœuds continuent-ils à être vidés en raison de problèmes de mémoire insuffisante (OOM) ?
Des problèmes OOM se produisent lorsque les tâches dépassent la capacité de mémoire du nœud. Pour éviter cela, implémentez `cgroups` pour appliquer des limites de mémoire par tâche. Cela empêche qu’une seule tâche n’affecte l’ensemble du nœud, et cela améliore l’isolation et la stabilité.
Exemple de configuration dans `slurm.conf` :
```
TaskPlugin=task/cgroup
```
Exemple de configuration dans `cgroup.conf` :
```
CgroupAutomount=yes
ConstrainCores=yes
CgroupPlugin=autodetect
ConstrainDevices=yes
ConstrainRAMSpace=yes
ConstrainSwapSpace=yes
SignalChildrenProcesses=yes
MaxRAMPercent=99
MaxSwapPercent=80
MinRAMSpace=100
```
Pour plus d’informations, consultez [Control Group in Slurm](https://slurm.schedmd.com/cgroups.html), [Cgroup and PAM-based login control for Slurm compute nodes](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils/pam_adopt_cgroup_wheel.sh#L197) et [Configure Cgroups for Slurm](https://catalog.workshops.aws/sagemaker-hyperpod/en-US/07-tips-and-tricks/16-enable-cgroups).
## Comment puis-je m’assurer que les ressources sont correctement nettoyées une fois les tâches terminées ?
Implémentez des scripts d’épilogue pour nettoyer automatiquement les ressources une fois les tâches terminées. Les ressources peuvent ne pas être correctement effacées lorsque les tâches se bloquent de manière inattendue, contiennent des bogues empêchant le nettoyage normal ou lorsque des tampons de mémoire partagés (y compris ceux partagés entre les processus et les pilotes GPU) restent alloués.
Les scripts d’épilogue peuvent effectuer des tâches telles que l’effacement de la mémoire GPU, la suppression des fichiers temporaires et le démontage des systèmes de fichiers. Ces scripts présentent des limites lorsque les ressources ne sont pas allouées exclusivement à une tâche unique. Pour des instructions détaillées et des exemples de scripts, reportez-vous au deuxième point de la question [Pourquoi ma tâche de formation parallèle échoue-t-elle lorsque j'utilise la bibliothèque de communications collectives NVIDIA (NCCL) avec Slurm sur plateforme ? SageMaker HyperPod](#hyperpod-faqs-q4). Pour plus d’informations, consultez [Activation d’un script d’épilogue Slurm](https://catalog.workshops.aws/sagemaker-hyperpod/en-US/07-tips-and-tricks/18-slurm-epilogue).