Bonnes pratiques - AWS ParallelCluster
Bonnes pratiques : sélection du type d'instance du nœud principalBonnes pratiques : performances du réseauBonnes pratiques : alertes budgétairesBonnes pratiques : déplacement d'un cluster vers une nouvelle version AWS ParallelCluster mineure ou un correctif

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.

Bonnes pratiques

Les sections suivantes présentent les meilleures pratiques d'utilisation AWS ParallelCluster, notamment les alertes relatives aux performances du réseau et au budget.

Bonnes pratiques : sélection du type d'instance du nœud principal

Même si le nœud principal n'exécute aucune tâche, ses fonctions et son dimensionnement sont essentiels aux performances globales du cluster. Lorsque vous choisissez le type d'instance à utiliser pour votre nœud principal, tenez compte des caractéristiques suivantes :

Taille du cluster : le nœud principal orchestre la logique de dimensionnement du cluster et est chargé d'associer les nouveaux nœuds au planificateur. Pour augmenter ou diminuer un cluster comportant un grand nombre de nœuds, fournissez au nœud principal une capacité de calcul supplémentaire.

Systèmes de fichiers partagés : lorsque vous utilisez des systèmes de fichiers partagés, choisissez un type d'instance doté d'une bande passante réseau suffisante et d'une EBS bande passante Amazon suffisante pour gérer vos flux de travail. Assurez-vous que le nœud principal est capable à la fois d'exposer suffisamment de répertoires de NFS serveurs pour le cluster et de gérer les artefacts qui doivent être partagés entre les nœuds de calcul et le nœud principal.

Bonnes pratiques : performances du réseau

Les performances du réseau sont essentielles pour les applications de calcul haute performance (HPC). Sans performances réseau fiables, ces applications ne peuvent pas fonctionner comme prévu. Pour optimiser les performances du réseau, prenez en compte les meilleures pratiques suivantes.

  • Groupe de placement : si vous utilisez Slurm, pensez à configurer chacun Slurm file d'attente pour utiliser un groupe de placement de clusters. 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 Groupes de placement dans le guide de EC2 l'utilisateur Amazon. Vous pouvez spécifier un PlacementGroupdans la Networkingsection de la file d'attente, chaque ressource de calcul est affectée au groupe de placement de la file d'attente. Lorsque vous spécifiez un PlacementGroupdans la Networkingsection 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, consultez SlurmQueues/Networking/PlacementGroupet SlurmQueues/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 liées à une 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.

  • Mise en réseau améliorée : 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 EC2 l'utilisateur Amazon.

  • Adaptateur Elastic Fabric : pour prendre en charge des niveaux élevés de communication évolutive entre instances, pensez à choisir des interfaces EFA réseau pour votre réseau. Le matériel EFA de contournement du système d'exploitation (OS) personnalisé améliore les communications entre instances 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 EFA avec AWS ParallelCluster, consultezElastic Fabric Adapter.

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

    Pour plus d'informationsEFA, consultez Elastic Fabric Adapter dans le guide de EC2 l'utilisateur Amazon 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 les sections EBS Instances optimisées pour Amazon et Types de EBS volumes Amazon dans le Guide de l'EC2utilisateur Amazon.

Bonnes pratiques : alertes budgétaires

Pour gérer les coûts des ressources dans AWS ParallelCluster, nous vous recommandons d'utiliser AWS Budgets des actions pour créer un budget. Vous pouvez également créer des alertes de seuils budgétaires définis pour AWS des ressources sélectionnées. Pour plus d'informations, consultez la section Configuration d'une action budgétaire dans le Guide de AWS Budgets l'utilisateur. De même, vous pouvez également utiliser Amazon CloudWatch pour créer une alarme de facturation. Pour plus d'informations, consultez Création d'une alarme de facturation pour surveiller vos frais AWS estimés.

Bonnes pratiques : déplacement d'un cluster vers une nouvelle version AWS ParallelCluster mineure ou un correctif

Actuellement, chaque version AWS ParallelCluster mineure est autonome avec ses pclusterCLI. Pour déplacer un cluster vers une nouvelle version mineure ou corrective, vous devez recréer le cluster en utilisant les nouvelles versions. CLI

Pour optimiser le processus de déplacement d'un cluster vers une nouvelle version mineure ou un correctif, nous vous recommandons de procéder comme suit :

  • Enregistrez les données personnelles dans des volumes externes créés en dehors du cluster, tels que Amazon EFS et FSx pour Lustre. De cette manière, vous pourrez facilement déplacer les données d'un cluster à un autre dans le futur.

  • 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 ou AWS Management Console.

    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. Ils sont ainsi préservés lorsque vous supprimez le cluster et peuvent être attachés à un nouveau cluster.

    Nous vous recommandons d'utiliser les systèmes de fichiers Amazon EFS ou FSx for Lustre. Ces deux systèmes peuvent être connecté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 le cluster existant.

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

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

    1. Mettez à jour la configuration de cluster existante pour utiliser les définitions de système de fichiers existantes.

    2. Vérifiez la pcluster version et mettez-la à jour si nécessaire.

    3. Créez et testez le nouveau cluster. Lorsque vous testez le nouveau cluster, vérifiez les points suivants :

      • Assurez-vous que vos données sont disponibles dans le nouveau cluster.

      • Assurez-vous que votre application fonctionne dans le nouveau cluster.

    4. Une fois que votre nouveau cluster est entièrement testé et opérationnel et que vous n'avez plus besoin du cluster existant, supprimez-le.