Bonnes pratiques

Groupe de placement : si vous utilisezSlurm, pensez à configurer chaque Slurm file d'attente pour utiliser un groupe de placement de cluster. Le groupe de placement d'un cluster est un regroupement logique d'instances au sein d'une seule zone de disponibilité. Pour plus d'informations, consultez la section sur les groupes de placement dans le guide de l'utilisateur Amazon EC2. Vous pouvez spécifier un PlacementGroup dans la Networking section de la file d'attente, chaque ressource de calcul étant affectée au groupe de placement de la file d'attente. Lorsque vous spécifiez un PlacementGroup dans la Networking section de la ressource de calcul, cette ressource de calcul spécifique est affectée à ce groupe de placement. La spécification du groupe de placement des ressources de calcul remplace la spécification de file d'attente pour la ressource de calcul. Pour plus d'informations, voir SlurmQueues Networking/SlurmQueues/PlacementGroupet ComputeResources/Networking/PlacementGroup.

Networking:
  PlacementGroup:
    Enabled: true
    Id: your-placement-group-name

Vous pouvez également AWS ParallelCluster créer un groupe de placement pour vous.

Networking:
  PlacementGroup:
    Enabled: true

À partir de AWS ParallelCluster la version 3.3.0, la création et la gestion des groupes de placement sont modifiées. Lorsque vous spécifiez le groupe de placement à activer, sans name ou, dans la file d'attenteId, chaque ressource de calcul se voit attribuer son propre groupe de placement géré, au lieu d'un groupe géré pour l'ensemble de la file d'attente. Cela permet de réduire les erreurs de capacité insuffisante. Si vous avez besoin d'un groupe de placement pour l'ensemble de la file d'attente, vous pouvez utiliser un groupe de placement nommé.

SlurmQueues/Networking/PlacementGroup/Namea été ajouté comme alternative préférée à SlurmQueues/Networking/PlacementGroup/Id.

Pour de plus amples informations, veuillez consulter Networking.

Réseau amélioré : pensez à choisir un type d'instance qui prend en charge la mise en réseau améliorée. Cette recommandation s'applique à toutes les instances de la génération actuelle. Pour plus d'informations, consultez la section Mise en réseau améliorée sous Linux dans le guide de l'utilisateur Amazon EC2.

Adaptateur Elastic Fabric : pour prendre en charge des niveaux élevés de communication évolutive d'instance à instance, pensez à choisir des interfaces réseau EFA pour votre réseau. Le matériel de contournement du système d'exploitation (OS) personnalisé de l'EFA améliore les communications d'instance à instance grâce à l'élasticité et à la flexibilité à la demande du AWS Cloud. Vous pouvez configurer chaque Slurm file d'attente ComputeResource à utiliser Efa. Pour plus d'informations sur l'utilisation d'EFA avec AWS ParallelCluster, consultezElastic Fabric Adapter.

ComputeResources:
  - Name: your-compute-resource-name
    Efa:
      Enabled: true

Pour plus d'informations sur EFA, consultez Elastic Fabric Adapter dans le Guide de l'utilisateur Amazon EC2 pour les instances Linux.

Bande passante de l'instance : la bande passante évolue en fonction de la taille de l'instance. Pour plus d'informations sur les différents types d'instances, consultez la section Instances optimisées pour Amazon EBS et types de volumes Amazon EBS dans le guide de l'utilisateur Amazon EC2.

Enregistrez les données personnelles dans des volumes externes créés en dehors du cluster, tels qu'Amazon EFS et FSx for Lustre. De cette manière, vous pouvez facilement déplacer les données d'un cluster à un autre à l'avenir.

Créez des systèmes de stockage partagés à l'aide des types suivants. Vous pouvez créer ces systèmes à l'aide du AWS CLI bouton ou Console de gestion AWS.

Définissez un système de fichiers ou un volume dans une configuration de cluster en tant que système de fichiers ou volume existant. De cette façon, ils sont préservés lorsque vous supprimez le cluster et peuvent être attachés à un nouveau cluster.

Nous vous recommandons d'utiliser Amazon EFS ou FSx pour les systèmes de fichiers Lustre. Ces deux systèmes peuvent être rattachés à plusieurs clusters en même temps. En outre, vous pouvez associer l'un ou l'autre de ces systèmes à un nouveau cluster avant de supprimer votre cluster existant.

Utilisez des actions de bootstrap personnalisées pour personnaliser vos instances plutôt que d'utiliser une AMI personnalisée. Si vous utilisez plutôt une AMI personnalisée, vous devez supprimer et recréer cette AMI pour chaque nouvelle version.

Nous vous recommandons d'appliquer les recommandations précédentes dans l'ordre suivant :

Vérifiez au démarrage du nœud. Utilisez-le pour valider un nœud une seule fois, lorsqu'il rejoint le cluster, avant qu'il n'accepte le travail. Comme aucune tâche n'est encore en cours d'exécution, elle peut être exécutée en profondeur dcgmi diag ; notez qu'elle ne détecte que les défauts présents au démarrage, et non les dégradations qui apparaissent plus tard. Installez et invoquez votre check à l'aide d'une action OnNodeConfigured personnalisée. Consultez Actions de bootstrap personnalisées.

Consultez le prologue. Utilisez-le pour une porte de préparation rapide avant chaque tâche. Étant donné que le prologue s'exécute sur chaque tâche et empêche le démarrage de la tâche jusqu'à sa fin, limitez la vérification à quelques secondes. Par exemple nvidia-smi (éventuellement avec une analyse du journal du noyau pour détecter les erreurs NVIDIA Xid), ou un niveau 1. dcgmi diag Consultez Slurm et prolog epilog.

Consultez l'épilogue. Utilisez-le pour valider un nœud une fois qu'une tâche est terminée. Par exemple, pour effectuer une vérification plus approfondie en cas d'échec d'une tâche ou pour détecter un GPU qui s'est dégradé pendant une exécution avant la planification de la tâche suivante. Cela peut aller plus loindcgmi diag. Pour éviter de vérifier après chaque tâche, vous souhaiterez peut-être exécuter un diagnostic de niveau 2 uniquement en cas d'échec de la tâche. Consultez Slurm et prolog epilog.