Dans de nombreuses charges de travail HPC, l’obtention des meilleures performances d’une application ou d’un flux de travail dépend de la technologie choisie pour héberger vos fichiers pendant leur traitement ou de la configuration de votre pile réseau pour fonctionner de manière optimale pour MPI ou d’autres protocoles de communication. Ce module couvre les options offertes par AWS dans ces domaines et vous guide sur les considérations en matière de prix/performances qui peuvent vous aider à choisir les solutions adaptées à chaque charge de travail.
Rubriques abordées :
- Stockage sur AWS pour le HPC
- Évolutivité du réseau pour les charges de travail HPC
Présentation des options de stockage sur AWS : AWS fournit de nombreuses options de stockage, allant du stockage d’objets à haute performance à de nombreux types de systèmes de fichiers pouvant être associés à une instance EC2. Outre les performances, plusieurs aspects différencient ces types de stockage, notamment le coût et l’évolutivité. Le tableau suivant peut vous donner des orientations pour trouver le stockage adapté à chacune de vos données HPC :
Systèmes de fichiers partagés pour HPC : il existe de nombreuses manières de mettre en place le stockage partagé, par exemple, à l’aide du simple montage NFS d’un volume EBS, avec Intel Lustre assemblé à partir de volumes EBS et avec le service AWS géré appelé « EFS ». Comme pour le type d’instances, il est facile de tester des options de stockage pour trouver le type de système de fichiers le plus performant.
Instance de stockage : les volumes EBS sont disponibles dans une variété d’options telles qu’un volume IOPS élevé, des options à usage général et des options magnétiques. De nombreuses applications HPC s’exécutent très bien sur des volumes à usage général moins coûteux et des types de stockage de volumes magnétiques EBS. Comme pour la sélection d’instance, il est facile de tester une sélection de volume EBS, ce qui permet d’obtenir une solution optimisée.
Configuration du stockage en laboratoire : la configuration de stockage par défaut utilisée dans l’automatisation EnginFrame par défaut est la suivante :
- Les scripts d’intégration montent un volume EFS sous /efs sur le nœud maître et les nœuds de calcul – ces systèmes de fichiers contiennent un répertoire pour les applications et un répertoire spouleur qui héberge par défaut un répertoire de soumission distinct pour chacune de vos tâches.
- AWS ParallelCluster fournit également un volume EBS gp2 qui est associé à la table principale et monté via NFS sur les nœuds de calcul sous /shared.
- Le répertoire /home de l’instance principale est également monté via NFS sur les nœuds de calcul. Comme ils sont installés sur le même système de fichiers que le système d’exploitation, il n’est pas recommandé de les utiliser pour le stockage permanent.
La performance de ces systèmes de fichiers partagés peut varier considérablement d’une charge de travail à une autre. Afin d’identifier celui qui vous convient le mieux, la meilleure approche consiste à tester les mêmes cas à la fois sur /efs (configuré en tant qu’emplacement par défaut dans EnginFrame) et /shared.
Mise en réseau AWS actuelle : AWS prend actuellement en charge des fonctionnalités de mise en réseau améliorée utilisant la virtualisation des E/S à racine unique (SR-IOV : Single Root I/O Virtualization). La méthode de virtualisation des dispositifs SR-IOV fournit de meilleures performances des E/S et une utilisation de la CPU réduite par rapport aux implémentations traditionnelles. Pour les instances Amazon EC2 prises en charge, cette fonctionnalité garantit de meilleures performances de paquet par seconde (PPS), une réduction des latences inter-instance et une très faible instabilité du réseau. Elle a été testée pour donner de bons résultats aussi bien pour le High Throughput Computing (HTC), les applications « incroyablement parallèles », ainsi que les applications HPC « étroitement couplées » ou basées sur MPI et OpenMP.
La vitesse du réseau dépend de la taille et du type d’instance, par exemple r4.16xlarge garantit une connectivité de 20 gigabits entre les instances, en utilisant le même groupe de placement (un regroupement logique d’instances) et la mise en réseau améliorée.
Configuration réseau en laboratoire : par défaut, le laboratoire crée un nouveau groupe de placement et exige que tous les nœuds de calcul du cluster soient lancés à l’intérieur de celui-ci. Ceci se traduit par la plus faible latence et la bande passante la plus élevée entre vos nœuds, ce qui est particulièrement important si vous exécutez des applications MPI. Si vous rencontrez un problème HTC qui s’ajuste horizontalement à des dizaines de milliers de cœurs ou plus (ce qui dépasse le cadre de cet exercice), vous devriez envisager de les exécuter sur plusieurs groupes de placement pour donner à EC2 plus de flexibilité quant à l’emplacement possible de ce grand nombre de nœuds. Vous pouvez désactiver l’utilisation d’un groupe de placement fixe en définissant le paramètre suivant dans la configuration d’AWS ParallelCluster :
placement_group = NONE
Astuce : si vous avez besoin de redimensionner votre cluster à un très grand nombre de nœuds, ou si vous avez besoin d’un stockage haute performance, il est conseillé de contacter votre gestionnaire de compte technique ou un architecte de solutions HPC, qui peut vérifier votre architecture cible, vous aider à identifier les goulots d’étranglement potentiels et choisir les technologies adaptées à vos objectifs spécifiques.