Académique Documents
Professionnel Documents
Culture Documents
Ce support de cours est soumis aux droits d'auteur et n'est donc pas dans le
IT 352
●
Systèmes parallèles et –
de citer l'auteur.
Si le document est reproduit dans le but d'être distribué à des tierces
distribués personnes, il devra être reproduit dans son intégralité sans aucune
modification. Cette notice de copyright devra donc être présente. De plus,
il ne devra pas être vendu.
– Cependant, dans le seul cas d'un enseignement gratuit, une participation
aux frais de reproduction pourra être demandée, mais elle ne pourra pas
être supérieure au prix du papier ou de l'encre composant le document.
– Toute reproduction sortant du cadre précisé ci-dessus est interdite sans
Brice Goglin 2011-2012
l'accord écrit préalable de l'auteur.
2011-2012 2
Programme du module
● 5 séances de cours
Ceci n'est PAS un polycopié de cours.
● 2h40 de TP, en salle machine
Ces « notes » guident simplement le cours.
– DSM en espace utilisateur
De nombreuses explications et illustrations ● Slides mis à jour en ligne au fur et à mesure
manquent. – http://runtime.bordeaux.inria.fr/goglin/teaching/SPD.html
Les détails seront données au tableau et à ● Examen écrit de 2h
l'oral pendant le cours magistral. – Tous documents autorisés
2011-2012 3 2011-2012 4
● http://runtime.bordeaux.inria.fr/goglin/
2011-2012 5 2011-2012 6
● Après la guerre
– Apparition des premiers ordinateurs
– Gros calculateurs centralisés, très coûteux
Introduction ● Début des années 80
– Micro-ordinateurs produits en grande
quantité, peu chers
– Faciles à interconnecter
● 1 ou 10Mb/s, Ethernet ou Token Ring
– Quels logiciels pour les utiliser ?
2011-2012 7 2011-2012 8
Intérêt des systèmes distribués Intérêt (2)
2011-2012 9 2011-2012 10
2011-2012 15 2011-2012 16
Super-calculateurs (3/4) Architecture de RoadRunner
2011-2012 17 2011-2012 18
● BlueGene (IBM)
– Enormément de Blades de calcul très simples
● Centaines de milliers de coeurs
● Processeurs et mémoire uniquement
● Matériel peu fiable (disque) ou inutile (USB)
supprimé
– Moins de consommation, moins de pannes
– 1 PFlop/s actuellement (BG/P)
● En attendant la génération suivante
2011-2012 19 2011-2012 20
Évolution des
Architecture BlueGene (2/2)
systèmes parallèles
2011-2012 21 2011-2012 22
Évolution des
Tendances actuelles
systèmes parallèles (2/2)
● Au début, des très gros calculateurs
– Massivement parallèles (MPP) ● Des systèmes de plus en plus complexes
– Matériel dédié – NUMA, Multicoeurs, accélérateurs
● Cher mais efficace ● Coeurs de calcul généralistes, GPU, Cell, ...
● Depuis 15 ans, grappes de calcul (Clusters) ● Parallélisme interne vs. externe
– Assemblage de machines – Mémoire partagée ou non
– Matériel plus standard ● Même à l'intérieur des noeuds
● Moins efficace mais beaucoup moins cher
2011-2012 23 2011-2012 24
Différents niveaux
Problèmes
de complexité
● Consommation d'énergie
● Complexité interne et cohérence matérielle
– Plusieurs megawatts pour les plus gros
– Machine mono-processeur, SMP, NUMA, ...
calculateurs – Concurrence, synchronisation, ...
● Green500.org vs. Top500.org – Accès non-uniforme aux données, affinité, ...
Le Cell et BlueGene sont très bons
Complexité externe
●
●
● Des systèmes de plus en plus distribués – LAN et grappes, WAN et grilles, ...
– De plus en plus de machines assemblées – Communications coûteuses, accès indirect aux
– Tolérance aux pannes de plus en plus critique données, migration, ...
● On ne sait pas comment atteindre l'ExaFlop/s ● Hétérogénéité
2011-2012 25 2011-2012 26
2011-2012 27 2011-2012 28
2011-2012 35 2011-2012 36
2011-2012 37 2011-2012 38
Systèmes d'exploitation
Système distribué collaboratif
pour machine multi-processeur
● OS faiblement couplé
● Une seule copie de l'OS sur la machine
– Machines indépendantes
– Synchronisation pour l'accès aux structures
– Exécution de tâches possible sans le réseau
partagées du noyau
– Réseau permet partage de ressources
● Exécution simultanée de plusieurs tâches
● Un OS sur chaque machine
– Chaque tâche se croit isolée
– OS standard + services distribués
● Support immédiat de
– Modèle client-serveur
– Mémoire partagée
– Hétérogénéité
– Migration des tâches
● NOW, grilles, Internet, ...
2011-2012 39 2011-2012 40
Distribution matérielle Distribution matérielle
ou logicielle ? ou logicielle ? (2/2)
● Matériel distribué
– Mémoire et processeurs pas directement
● Compensation possible par le logiciel
accessibles – Donner l'illusion d'un seul système au dessus
● Réseau de communication sans accès direct à la de matériel distribué
mémoire ● Communications bas-niveau explicites effectuées
– Mémoire et processeurs rendus accessibles de manière transparente
par matériel spécialisé – Par OS ou bibliothèque
● Sans intervention du logiciel
2011-2012 41 2011-2012 42
2011-2012 49 2011-2012 50
Beaucoup de niveaux de
Coprocesseurs de calcul (2/2)
complexité
● Mémoire embarquée ● Mono-processeur
– Indépendante de la mémoire principale ● SMP
● Inaccessible directement (généralement pas ● CC-NUMA
déréférençable)
● NCC-NUMA
● Nécessité de déplacer les données entre
la machine et le coprocesseur (DMA ?) ● Coprocesseur avec mémoire embarquée
– Migration explicite de données
– Cohérence, synchronisation ● Distribué masqué par le matériel
● Comme un système distribué ! ● Distribué masqué par le logiciel
– Mais à l'intérieur d'une même machine ● Distribué
2011-2012 51 2011-2012 52
Facteur NUMA
Impact sur l'ordonnancement
et migration de pages
● Accès direct aux pages distantes
– Gros facteur NUMA
● Plus l'accès distant est lent, plus il faut
l'éviter
● Au moins 1us sur NUMAlink au lieu de 100ns en
local – Migrer les processus près des données
● Migrer les pages là où elles sont utilisées – Migrer les données près des processus
– Affinité mémoire ● Contraintes sur l'ordonnancement
● Comme pour les caches proportionnelles au coût réseau
● Nécessité de bloquer les accès pendant la – Critique si latence élevée et/ou débit faible
migration
2011-2012 69 2011-2012 70
● Machines non-CC-NUMA
● Les caches d'une machine sont similaires
aux mémoires des machines d'une DSM
– Très difficile à programmer
● Disparaît peu à peu
● Cache mémoire critique pour performance – Mais pourrait bien revenir...
● Intel SCC, ...
– Efficacité maintien cohérence est critique pour
performance – Soit pas de cache local
● Protocole complexe dans le matériel – Soit pas de cache sur données partagées
● Machines Cache Coherent-NUMA ● Accès lents
● Similaire à SCI
2011-2012 73 2011-2012 74
2011-2012 75 2011-2012 76
Consistence Granularité
● Octet
● Consistence séquentielle – Accès transparent
● Très simple à utiliser
– Toute modification est immédiatement – Très complexe à mettre en place
visible sur les autres nœuds
● Page
● Consistence relâchée ou faible – Plus simple à mettre en place
– Pas immédiatement visible – Faux partage
● Exemples de garanties ● Objets partagés
– Délai de propagation
– Dépendances sur certaines opérations spéciales
– Faux partage en interne, éventuellement
● Prise/relâchement verrou propage les modifications ● Ligne de cache
– Utilisé dans le matériel au lieu de l'octet
2011-2012 77 2011-2012 78
2011-2012 83 2011-2012 84
2011-2012 85 2011-2012 86
2011-2012 89 2011-2012 90
Gestionnaire distribué
Stockage des attributs globaux
dynamique
● Gestionnaire = propriétaire ● 1 octet pour le statut global
● Maintien d'un propriétaire probable ● Quelques octets pour liste des copies
– Propagation des requêtes sur une chaîne de – Si trop de copies, ne pas garder la liste
propriétaires probables jusqu'à trouver le bon précise ?
● Mise à jour du propriétaire probable sur le ● Occupation mémoire proportionnelle à
demandeur et l'ancien propriétaire
nombre total de pages de tous les noeuds
– Quel est le cas le pire ?
– Répartie sur tous les noeuds si gestionnaire
● Traitement des pages une par une par le distribué dynamique
gestionnaire local sur le propriétaire ● En moyenne, proportionnelle à mémoire d'un
correspondant noeud
2011-2012 91 2011-2012 92
2011-2012 93 2011-2012 94
Défaut de page
DSM dans un Middleware
en espace utilisateur
● Assez générique, moins adapté à
l'application
● Impose garanties bien définies ● Appel système mprotect() pour rendre
– Modèle de consistence zone Shared, Exclusive ou Invalid
● Plus complexe à mettre en œuvre ● Rattrapper le signal SEGV
– Doit détecter et réagir aux accès concurrents – Migrer ou recopier les données
● Comme dans l'OS, avec moins de support logiciel – Remettre la protection normale
● Peut proposer différentes consistences à
l'application
2011-2012 95 2011-2012 96
Implémentation des
DSM dans l'OS
défauts de page dans l'OS
● Transparent pour l'utilisateur
● Page invalide
– Déréférencement habituel des pointeurs
– L'OS alloue une page libre
● Générique
– Si page locale non partageable
– Difficile à adapter à application quelconque
● Lire sur le disque
● Heuristiques pour deviner ce que l'application fait
● Assistance de l'application
● Ajuster la protection
● Utiliser les protections mémoire – Sinon
● Contacter le gestionnaire
– Détecter un accès en lecture
● Rapatrier la page depuis le réseau
● Rapatrier une copie de la page
● Ajuster la protection
– Détecter un accès en écriture
– Lecture seule si accès en lecture
● Récupérer un droit sur la page
2011-2012 97 2011-2012 98
– Sinon
● Contacter le gestionnaire
● ... et aux algorithmes
– Segmentation fault si page en lecture seule
● Rapatrier page si nécessaire
● Autoriser l'écriture
2011-2012 99 2011-2012 100
● Flexibilité
– Nombre de processeurs adapté
● Accès aux ressources logiques depuis
– Utilisation identique quelle que soit la taille
n'importe quel nœud
de l'application – Fichiers locaux ou distants
● Permet programmation entièrement par ● Migration de ressources logiques sans
threads et mémoire partagée sur changer la méthode d'accès ni perturber
multiples machines physiques l'exécution
– Pas besoin de MPI – Espaces de nommage
● Si c'est performant...
● Décentralisation
● Augmentation performances globales
avec augmentation des ressources mises – Pas de goulet d'étranglement
en commun – Tolérance aux pannes et disponibilité
● Reconfiguration dynamique
● Réplication
– Ajout/suppression de nœuds – Différentes copies d'une même donnée
réparties et gérées par le système
Optimiser le
Reprise après migration
temps de migration (2)
● Copier les pages de manière paresseuse ● Si la machine destination n'a pas les
– Ne migrer que quand c'est nécessaire
ressources nécessaires
● En profitant de la DSM – La machine source reprend l'exécution
– Charge la machine source plus tard ● Sinon, acquittement
– Réduit le temps de migration apparent – La machine source oublie le processus migré
Mise en œuvre
Dépendances résiduelles
en espace utilisateur
● Multiples structures localement inutiles ● Développement assez facile
– Pages non-migrées (migration paresseuse) – Mais peu de possibilités
– Périphériques physiques exportés par un – Transparence limitée
gestionnaire local
– DSM limitée
– Connexions réseau forwardées
● Suffisant pour les problèmes non-critiques
● En tenir compte lors du choix de la
destination d'une migration – Politiques de migration
– Services de gestion du SSI
● Processus peut être affecté par
Découverte des machines
défaillance d'une autre machine
●
Conclusion Virtualisation ?
Généralités Objectifs
● Ensemble de données qui doit être ● Accès transparent depuis tous les nœuds
accessible depuis tous les nœuds du ● Illusion d'un seul système de stockage
système
● Utiliser tous les disques disponibles
– Pas uniquement les disques locaux pour les
processus locaux ● Supporter la charge imposée par les
● Accès aux fichiers non transparent clients
– FTP (File Transfer Protocol) – Stockage = Facteur limitant la performance
● Peu intuitif ● Exploiter la mémoire des nœuds comme
● Pas transparent un cache de fichiers global
2011-2012 159 2011-2012 160
Différentes réponses
Différents besoins
aux besoins
● Applications régulières
● Stockage distant distribué à différents
– Même application sur différents nœuds et clients
volumes de données
● Schéma d'accès aux données connus à l'avance
– Espace de nommage global
● Applications irrégulières – Accès transparent depuis n'importe quel
client
– Concurrence ● Stockage caché dans le client
– Schéma d'accès aux données inconnu
– Réduire la charge de travail du serveur
● Applications Out-of-core
– Réduire les aller-retours sur le réseau
– Données ne tenant pas en mémoire – Améliorer les performances locales
● Va-et-vient entre stockage et mémoire
2011-2012 161 2011-2012 162
Différents niveaux
Transparence
de mise en œuvre (2)
Mise en œuvre
Conservation de l'état
de la transparence
● Couche logicielle de virtualisation ● Dans le serveur
– Plus facile à mettre en œuvre dans l'OS – Lien étroit entre client et serveur
● Chaque type de fichier a ses méthodes – Difficulté de passage à l'échelle
d'accès – Pas de tolérance aux pannes du serveur
– Fichiers locaux ● Dans le client
● Accès aux disques locaux
– Mode « déconnecté »
– Fichiers distants
● Client pas informé des modifications concurrentes
● Requêtes aux serveurs distants à travers le
réseau
● Problème de cohérence
Adapter la cohérence
Relâcher la cohérence Unix
aux besoins
● Modifications visibles immédiatement
● Maintien cohérence réduit performance pour les applications locales
– Adapter la cohérence aux besoins des – Sémantique Unix respectée dans cache local
applications ● Même problème que dans une DSM
● NFS pour les homes
– Pas d'accès concurrents
– Mais plus de possibilités
– Performance du cache suffisante ● Structure et granularité des données
● PVFS pour les applications parallèles
– Pas d'accès concurrents au même segment de fichiers
– Faux accès concurrents
– Performances importantes ● Fichiers différents
● Segments de fichiers différents
2011-2012 181 2011-2012 182
Chargement adapté
Accès non-cachés
aux besoins
● Heuristiques pour deviner comment
précharger
– Accès séquentiel ou aléatoire ? ● Flag O_DIRECT à l'ouverture du fichier
– Indications de l'utilisateur ● Lecture et écriture sans passer par le
fadvise()
cache
●
Exemple des
serveurs parallèles
● Réplication données
● Équilibrage de charge
● Facile en lecture seule
– Pas de cohérence
Divers – Serveur WWW
● Difficile en écriture
– Sauf si cohérence peu importante
● Mise à jour d'un serveur WWW
● Ne pas centraliser
– Distribuer et synchroniser
● Toujours être près des clients
– Géographiquement
● Ou centraliser le minimum
● Réduction des temps d'accès
– Serveur de metadonnées qui distribue la
charge de travail à de multiples serveurs
● Et s'adapter à leur spécificité
● Serveurs de fichiers – Langue, besoins, nombre, ...
– Lustre, PVFS, NFSp, ...
IP Spoofing
2011-2012 211