Nouvelles de Bordeaux Description de topologie et configuration automatique Alexandre DENIS Équipe-projet Runtime INRIA Bordeaux - Sud-Ouest Réunion COOP 11/04/ Rennes

Utilisation de PMF sur topologies réseau complexes  Salomé/PadicoTM  Stage en démarrage (sur accord-cadre EDF-INRIA)  Cible : multi-cluster, IP privées, firewalls  DIET/PadicoTM  Déjà tenté dans LEGO Ok sur topologies simples, bugué sur topologie complexes  Devrait bénéficier de développements/stabilisation récents et de ce qui sera fait autour de Salomé (scénario similaire)  Grid-TLSE/PadicoTM  Pourquoi pas, si on a DIET/PadicoTM

Communication schemes  Example 1 :  Two clusters connected through a WAN  MPI code coupled with CORBA SAN WAN

Communication schemes  Example 1 :  An MPI code on each cluster (over a SAN)  code coupling through CORBA over the WAN MPI CORBA Firewall NAT

Communication schemes  Example 3:  Computation on a cluster  Cluster protected by a firewall  Visualization on a dedicated node MPI CORBA Visualization Firewall Laptop with dynamic IP address

Communication schemes  Example 2:  One MPI communicator spanning accross two clusters MPI MyrinetInfiniband

Applications dynamiques  PadicoTM et NewMadeleine sont dynamiques  Connexion/déconnexion dynamiques  API spécifiques  Que veut l'application ? MPI_Spawn/Comm_connect/Comm_accept ? Connexion CORBA ? Spécifique ?  Travaux connexes en cours  Passage à l'échelle > 500 noeuds Graphe NewMad non-complet Connexions en arbre Connexions paresseuses

Topologie et configuration  PadicoTM nécessite une configuration des méthodes de communication  Heuristique besteffort pour gérer les cas “simples”  Configuration manuelle pour le reste...  Automatisable à partir de la connaissance de la topologie  Sources d'informations  Auto-détection  API (Grid'5000)  Configuration manuelle (fichiers Adage)  XtreemOS ?

Description de la topologie  Pas de standard universel de format de description  Adage semble pas mal, mais : Incomplet pour la topologie réseau Incomplet pour la description des machines (p/r hwloc) Beaucoup de superflu quand on veut seulement la topologie  PadicoTM a déjà un format interne pour les annonces de routage Incomplet pour les topologies complexes  Chaque API a son propre format (JSON pour Grid'5000)  Chaque format conçu pour un but différent  Grande unification illusoire  Besoin de savoir convertir d'un format à un autre et gérer des descriptions incomplètes

Description de la topologie  Pas de source complète d'information  Auto-détection Tout n'est pas auto-détectable Il faut etre connecté sur les noeuds  API (Grid'5000) Incomplet : uniquement les noeuds de calcul Ne contient que Grid'5000  Configuration manuelle 3000 lignes de XML rien que pour décrire Grid' On veut réserver la configuration manuelle aux exceptions  Besoin de fusionner des informations de diverses sources

Identification, dédoublonnage  Jonction entre plusieurs formats/modèles  Identifier de façon unique chaque ressource  Interface réseau → MAC (ou GUID) Négocié avec hwloc À négocier avec Adage :-)  Sous-réseau Myrinet → MAC du mapper  Auto-détectable par API MX (non-portable, mais utilisé par OpenMPI) Infiniband → subnet GID (GUID du SM)  Auto-détectable par API ibverbs IP → préfixe+netmask+gw  Auto-détectable par netstat -nr (portable) ou /proc/net/route (non- portable) puis parsing  Machines Pas d'identifiant unique

Identification des machines  Adresse IP, hostname : pas forcément unique  Plusieurs machines avec la meme IP (privée) Tout le monde a un ou dans son réseau :-)  Plusieurs noms ou IP pour une machine  Correspondance IP ↔ hostname pas toujours évidente  Hostname non-résolvable, pas de DNS, /etc/hosts pas cohérent  DNS privé (e.g. Grid'5000)  Adresse MAC  Liste d'adresse MAC pour l'unicité  Pas réaliste en configuration manuelle  Heuristique pour recouper IP, hostname, FQDN, MAC...  Des fois, ça ne marche pas...  Proposition : auto-détecter un identifiant unique + description  Au moins pour les machines “sensibles” : passerelles

Unifier les modèles  Avoir les memes notions pour convertir et fusionner  Adage : node / group / network_properties associées au group  PadicoTM : node+host / network / bindings: node-network  Vraie vie : bien pire que ça :-)  Modèle unifié  Host / network (=group) / network_properties / bindings / binding_property  Binding (interface réseau, adresse) nécessaire La simple appartenance au réseau ne suffit pas  binding_property nécessaire Restrictions, filtrage, etc. sont des propriétés locales

Description manuelle  Description de topologie en format Adage ou PadicoTM (XML)  Interface graphique pour éditer la topologie  Projet de Programmation de M1  [ démo ? ]

De la topologie à la configuration  Générer une configuration complète à partir de la topologie  Stage de Florence  Complexe, pas scalable  Étendre le besteffort pour gérer tous les cas  Prendre les décisions à la volée  Actuellement : voisins direct (meme réseau)  Extension : Gérer les cas sans connexion directe Routage via une gw (noeud appartenant à plusieurs réseaux) Algo à la OSPF (Dijkstra) à étudier

Conclusion et roadmap  Mettre ça au propre dans le D2.3 :-)  Finaliser le modèle de topologie  Formaliser proprement les network_properties nécessaires  Implémenter en format PadicoTM  En format Adage + conversion  Auto-détection + fusion des différentes sources  Configuration automatique à partir de la topologie  Algo à finaliser  Voir ce que l'on veut pour la dynamicité  Tout mettre ensemble, avec Salomé ou DIET...