Évaluation des routages pour les réseaux haute-performance. 26 Novembre 2013 Matthieu Pérotin

Transcription

1 Évaluation des routages pour les réseaux haute-performance 26 Novembre 2013 Matthieu Pérotin

2 Plan Introduction Fabriques haute-performance Routage Évaluation hors-ligne Évaluation en-ligne Perspectives C Bull, / 36

3 Plan Introduction Fabriques haute-performance Routage Évaluation hors-ligne Évaluation en-ligne Perspectives C Bull, / 36

4 Présentation rapide Diplômé de Polytech Tours (Informatique) Doctorat d informatique (LI Tours, ordonnancement, HPC) Bull R&D développeur Cluster Management Tera-100 (CEA) Curie (TGCC) Architecte logiciel Projets futurs Notamment problématiques réseaux C Bull, / 36

5 Le Calcul Haute Performance Un domaine fascinant aux prolématiques multiples matériel (problématiques très basses jusqu à très hautes) topologies réseau logiciel (OS, parallélisation, management,... ) ordonnancement... Se résume assez bien: Presser la moindre goutte de performance... étant données des contraintes client! le sacro-saint linpack n est pas le but ultime C Bull, / 36

6 Impact du réseau Les applications parallèles communiquent énormément: Entre threads et processus pour les calculs Avec les espaces de stockage Réduire ces temps de communication est capital Une fois de plus, il ne suffit pas d améliorer le matériel C est ici qu entrent en jeu les aspects: Topologies Routage C Bull, / 36

7 La recherche opérationnelle dans tout ça? Une problématique RO est présente à presque chaque niveau Packaging : que mettre dans un rack? (densité, consommation électrique) Conception: quel architecture répond aux besoins du client? Plan de salle: où placer les racks? (les câbles coutent cher!) Ordonnancement: où placer les tâches? Routage: comment choisir les meilleures routes? Management: collecte et corrélation d événements... Peu familiarisés au (ou traumatisés par le) domaine les ingénieurs ne considèrent pas cette dimension du problème ou refusent de la voir! C est dommage (et dommageable) C Bull, / 36

8 Plan Introduction Fabriques haute-performance Routage Évaluation hors-ligne Évaluation en-ligne Perspectives C Bull, / 36

9 Fabriques haute-performance Deux axes: La topologie Le routage Impossible à dissocier Des problématiques liées au matériel Tout n est pas possible avec tous les HW Dragonfly avec Infiniband difficile: radix, pas de routage adaptatif Pire: le Dragonfly demande un routage adaptatif non-minimal! C Bull, / 36

10 Topologies actuelles et futures Le roi actuel est le PGFT (immanquablement appelé fat-tree ) Historiquement premier petaflopique Technologie Infiniband Big-Switches Les Tores-nD survivent, voir reviennent (n 5) Le DragonFly (et donc le Flattened-Butterfly) fait une percée timide C Bull, / 36

11 Succès du PGFT Une topologie dite Non bloquante Quelque soit l ensemble de paires de nœuds distinctes voulant communiquer, il existe toujours un routage sans congestion (Big-Switches) Bisection BandWidth: 1 Bisection: nombre de liens minimum à enlever pour couper le réseau en deux parties égales Bisection BandWidth: débit max pouvant passer par ces liens Rapport à la bande passante totale Notez: il existe : un PGFT est ré-arrangeable, non-bloquant (!) On évite les deadlocks sans avoir besoin de réseaux virtuels (Virtual Lanes, Virtual Channels): utilisables pour la QoS Pas de livelocks par essence C Bull, / 36

12 Réarrangeabilité du PGFT C Bull, / 36

13 Réarrangeabilité du PGFT (3,5,6) (4,7,8) C Bull, / 36

14 Réarrangeabilité du PGFT (3,5,6) (4,7,8) C Bull, / 36

15 Réarrangeabilité du PGFT (3,5,7) (4,6,8) C Bull, / 36

16 Le problème Chaque switch a une table de routage Une table de routage est une fonction: f (dest) port Il s agit d un tableau de dimension 1 Routage adaptatif f (dest) [ports] Il s agit d un tableau de dimension n Choix du port: charge, random... classique Comment affecter les routes? De nombreux alogrithmes existent... Topo-specific Topo-agnostic C Bull, / 36

17 Le problème se précise (1/2) Entendu entre administrateurs... Nos performances sont pitoyables! Arg! il a basculé sur Min-Hop Et... zut! Min-Hop est un algorithm topo-agnostic: trouver les plus courts chemins (Dijkstra), équilibrage de charge local FT est l algorithme optimisé pour les fat-tree d OpenSM De nombreuses propriétés de la topologie sont exploitables Notamment: sa structure en arbres, la différence chemins montant et descendant Il serait dommage de s en priver Ce type de basculement arrive lorsque le PGFT est trop dégradé (pannes), et que les préconditions requises pour FT ne sont plus vérifiées Petaflopique: au moins toujours 1 câble absent Les câbles tombent en panne... C Bull, / 36

18 Le problème se précise (2/2) Pourquoi Min-Hop est-il moins efficace que FT? Peut-on trouver un algorithme topo-agnostic meilleur? Ou un algorithme pour PGFT moins sensible? Le problème est un problème de recherche opérationnelle Comment ce formalisme peut-il nous aider? C Bull, / 36

19 Fonctions objectif Quelle fonction objectif cherche-t-on à optimiser? Le plus court chemin: classique, et très discutable Min-Hop... Latence dans les switchs modernes? Négligeable (Virtual-Cutthrough ou Wormhole) Routage adaptatif non-minimal? Équilibrage de charge Contention (Max Flow Min Cut, niveau switch ou niveau port) Nombre de liens non utilisés (bidirectionnel) Minimiser le nombre de VC... Les idées ne manquent pas Utilité? C Bull, / 36

20 Fonctions objectif Quelles contraintes? Routabilité Pas de deadlocks Pas de livelocks... C Bull, / 36

21 La situation aujourd hui Presque tous les algorithmes de routage présentés ne donnent aucune formulation de leur objectif (ou contraintes... mis à part deadlocks) (!) PGFT: d-mod-k, routabilité (+ contrainte sur Shift-Permutation) Flattened-Butterfly/HyperX: DAL,? (Résultats expérimentaux sur #Hops) DragonFly: UGAL,? (Résultats expérimentaux sur latence) Étonnant... (quoique... ) Difficile à reproduire et frustrant! C Bull, / 36

22 Plan Introduction Fabriques haute-performance Routage Évaluation hors-ligne Évaluation en-ligne Perspectives C Bull, / 36

23 Le routage omniscient, ou le problème hors-ligne Un fonctionnement simple 1. La topologie est connue 2. On applique un algorithme de routage (on obtient des tables) 3. On calcule des métriques (fonctions objectif) sur ces tables Qu espérer? Mieux comprendre les métriques Évaluer la pertinence d une métrique Limites Les dimensions en-ligne sont ignorées (peut coûter cher) Topologie: pannes Applications Un problème multi-critère C Bull, / 36

24 Le routage omniscient, ou le problème hors-ligne Dimension multi-critère Se prête assez-bien à l ɛ-contrainte PGFT: max #Hops = diamètre du sous-arbre couvrant minimal Certains algorithmes sont dominés Ordre sur les critères 1. nombre de liens inutilisés 2. load balancing 3. contention Résulte de discussions avec admins/clients Expérience souvent excellente Mais pas nécessairement intuitive C Bull, / 36

25 Résultats expérimentaux Projet avec Polytech Tours (A. Soukhal) Réalisé par Antoine Sax 2012/2013 (PFE + Stage) Rouge: MH, Vert: random -FT C Bull, / 36

26 Stage d Antoine Sax Support générique de topologies Algorithmes canoniques Algorithmes adaptatifs Comparateur une première percée salvatrice C Bull, / 36

27 Plan Introduction Fabriques haute-performance Routage Évaluation hors-ligne Évaluation en-ligne Perspectives C Bull, / 36

28 La réalité L évaluation hors-ligne a ses limites Deux applications ne vont pas nécessairement se comporter de la même façon Ajout des pannes (problématique de résilience) Pertinence des fonctions objectif face à la réalité? Une évaluation complexe Accès à un petaflopique pour tests est impossible Cluster pour benchmarking (petite taille) Simulation C Bull, / 36

29 Simulation Une topologie Un algorithme de routage Applications réelles: exclues Des traces d application (simulation hors-ligne) Difficiles à obtenir Dépendent d un environnement donné Donc parfois du routage (!) Un simulateur ayant un modèle d ASIC concordant C Bull, / 36

30 Plan Introduction Fabriques haute-performance Routage Évaluation hors-ligne Évaluation en-ligne Perspectives C Bull, / 36

31 Une problématique de RO Tout part de Pourquoi FT est-il plus efficace que MH? Aucune réponse théorique claire dans la bibliographie Peu d articles formalisent convenablement leur problème Et apportent une réponse claire sur ce que fait leur algo, en terme d optimisation il nous semble nécessaire de changer cela C Bull, / 36

32 Modèle hors-ligne Calcul jusqu à 4096 nœuds (Un petaflopique classique ) Explosion combinatoire intenable ensuite En temps (10560s pour un routage adaptatif) En mémoire (20Go+ pour 8192 nœuds) C Bull, / 36

33 Modèle hors-ligne (performances) C Bull, / 36

34 Modèle hors-ligne Un outil extrêmement flexible et utile Étude de nouvelles topologies Étude de nouvelles fonctions objectif Certaines études de résilience (scénario et si? ) Effet sur le routage Mais qui a de nombreuses limites Le routage adaptatif est intrinséquement en-ligne Comportement des applications? C Bull, / 36

35 Modèle en-ligne Beaucoup à faire dans ce domaine Peu exploité jusqu à présent Un outil avec modèle IB (Mellanox): OmNet++ Peu étudié encore chez nous Dépendances à des traces... Simulation d applications MPI en-ligne? Difficile de ne pas citer SMPI (SimGrid) Sur benchmarks uniquement Modèle Infiniband? C Bull, / 36

36 Futur Améliorer les performances du modèle hors-ligne De multiples pistes Catégoriser les algorithmes de routage classiques de la littérature Étudier la composante en-ligne, sans utiliser de simulateur Impact des pannes Impact des patterns de communication Impact de l ordonnancement Il s agit de rester hors-ligne mais f (topo, routage) devient f (topo, routage, pattern, placement) Impossible d être exhaustif, bien sûr Pousser l analyse expérimentale hors-ligne le plus possible C Bull, / 36

37