Nouvelles de Bordeaux Description de topologie et - COOP

Nouvelles de Bordeaux
Description de topologie et
configuration automatique
Alexandre DENIS
Équipe-projet Runtime
INRIA Bordeaux - Sud-Ouest
Réunion COOP
11/04/2011 - 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
WAN
SAN
SAN
Communication schemes

Example 1 :

An MPI code on each cluster (over a SAN)

code coupling through CORBA over the WAN
CORBA
MPI
Firewall
MPI
NAT
Communication schemes

Example 3:

Computation on a cluster

Cluster protected by a firewall

Visualization on a dedicated node
CORBA
Visualization
MPI
Laptop with
dynamic IP
address
Firewall
Communication schemes

Example 2:

One MPI communicator spanning accross two clusters
Infiniband
MPI
Myrinet
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

•
•
Chaque API a son propre format (JSON pour Grid'5000)
Chaque format conçu pour un but différent
•
•
Incomplet pour les topologies complexes
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'5000...
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 (nonportable) 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)

•
•
•
•
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...
•
•
Tout le monde a un 10.0.0.1 ou 192.168.0.1 dans son réseau :-)
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...