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 FAQ
Consultez les questions fréquemment posées ci-dessous pour résoudre les problèmes liés à l'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.
-
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 } -
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" -
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.confslurm.conf/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
SchedulerParametersparamètresTaskPluginet 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 NodeNameles 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 : Comment utiliser le magasin NVMe 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 NVMe local. Pour savoir comment configurer le magasin NVMe et l'utiliser pour lancer des conteneurs Docker, consultez. Exé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 Étape 1 : Préparation d'un groupe de sécurité compatible 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.
