SageMaker HyperPod FAQ

Consultez les questions fréquemment posées ci-dessous pour résoudre les problèmes d'utilisation SageMaker HyperPod.

Q : 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 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 y écrire des journaux/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 champlogs.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 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
}
```
2. Remplacez la valeur du nom du "file_path" champ 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 y écrire/var/log/custom-provision/custom-provisioning.log, mettez à jour la valeur pour qu'elle corresponde à celle-ci comme suit.
```
"file_path": "/var/log/custom-provision/custom-provisioning.log"
```
3. 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.
```
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
```

Q. 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 gres.conffichiers slurm.confet /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 slurm.conf, HyperPod définit les paramètres de base suivants : ClusterNameSlurmctldHost,PartitionName, etNodeName.

En outre, pour activer la Reprise automatique 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 gres.conf, HyperPod gère NodeName les nœuds GPU.

Q : 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 Commencez par les scripts de cycle de vie de base fournis par HyperPod et Exécutez des conteneurs Docker sur un nœud de calcul Slurm sur HyperPod.

Q. Pourquoi ma tâche de formation parallèle échoue-t-elle lorsque j'utilise la bibliothèque de communications collectives NVIDIA (NCCL) sur la SageMaker HyperPod plateforme du framework Slurm ?

Par défaut, le système d'exploitation Linux définit le #RemoveIPC=yes drapeau. Les tâches Slurm et mpirun qui utilisent NCCL génèrent des ressources de communication inter-processus (IPC) dans le cadre de sessions utilisateur non root. Ces sessions utilisateur peuvent se déconnecter pendant le processus de travail.

Lorsque vous exécutez des jobs avec Slurm ou mpirun, s'il systemd détecte que l'utilisateur n'est pas connecté, les ressources IPC sont nettoyées. Les jobs Slurm et mpirun peuvent être exécutés sans que l'utilisateur soit connecté, mais cela nécessite que vous désactiviez le nettoyage au niveau systemd et que vous le configuriez au niveau Slurm à la place. Pour plus d'informations, consultez Systemd dans la documentation NCCL.

Pour désactiver le nettoyage au niveau du système, procédez comme suit.

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.

Par défaut, Slurm ne nettoie pas les ressources partagées. Nous vous recommandons de configurer un script d'épilation Slurm pour 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 de formation. 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="/<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

Pour plus d'informations sur le paramètre Epilog, consultez la documentation de Slurm.

Dans le slurm.conf fichier provenant du nœud du contrôleur, ajoutez une ligne pointant vers le script d'épilogue que vous avez créé.
```
Epilog="/path/to/epilog.sh"  #For example: /fsx/epilogue/epilog.sh
```
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
```
Pour appliquer toutes vos modifications, exécutezscontrol reconfigure.

Q : 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, consultezExécutez des conteneurs Docker sur un nœud de calcul Slurm sur HyperPod.

Q. Comment configurer les 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 l'étape 1 : préparer un groupe de sécurité compatible avec EFA dans le guide de l'utilisateur Amazon EC2 .

Q : Comment surveiller les nœuds de mon HyperPod cluster ? Existe-t-il des CloudWatch métriques 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 Notez que l'exportation des métriques du système vers Amazon n'est SageMaker HyperPod actuellement pas prise en charge CloudWatch.

Q : 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'instance 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, 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.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Gestion du cluster

Orchestration de HyperPod clusters avec Amazon EKS