Вы находитесь на странице: 1из 27

3ème année PRCD & RSR Copyright

● Copyright © 2007-2012 Brice Goglin

Ce support de cours est soumis aux droits d'auteur et n'est donc pas dans le
IT 352

domaine public. Sa reproduction est cependant autorisée sous réserve de


respecter les conditions suivantes :
– Si ce document est reproduit pour les besoins personnels du reproducteur,
toute forme de reproduction (totale ou partielle) est autorisée sous réserve

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

Plan du cours Pour me joindre


● Equipe-Projet INRIA Runtime
– A29bis, préfabriqués INRIA en face du LaBRI
● Généralités et concepts
● Mémoire partagée distribuée ● 05.24.57.40.91
● Systèmes d'exploitation à image unique
● Stockage distribué ● Brice.Goglin AT inria.fr

● http://runtime.bordeaux.inria.fr/goglin/
2011-2012 5 2011-2012 6

Systèmes parallèles et distribués Introduction historique

● 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)

● Mise en commun d'un grand nombre de ● Réponse à la distribution géographique


ressources à faible coûts de certains systèmes existants
– Bon rapport performance/prix – Réplication locale des ressources globales
– Puissance globale virtuellement illimitée ● Partage de ressources coûteuses entre
● Supérieure à celle des gros calculateurs plusieurs utilisateurs/machines
● Disponibilité et flexibilité – Accès à distance à une ressource indisponible
– Un élément peut tomber en panne sans en local
bloquer tout le système – Accès aux mêmes ressources depuis tous les
– Distribution de la charge endroits du système

2011-2012 9 2011-2012 10

Inconvénients Le plus grand système


des systèmes distribués distribué actuel
● Logiciels de gestion difficiles à concevoir
– Peu d'expérience ou succès dans ce domaine
– Complexité imposée par la transparence ● Internet
● Problèmes inhérents aux communications
– Communications explicites si pas de mémoire
partagée
● Contient de nombreux sous-systèmes
– Lenteur, saturation, perte de messages
selon le protocole considéré
● Partage et distribution de données impose – Web (http)
mécanismes complexes – Bittorrent (peer-to-peer)
– Synchronisation
– Sécurité
2011-2012 11 2011-2012 12

Différences entre systèmes


Super-calculateur ?
parallèles et distribués
● Architecture matérielle et/ou logicielle
● Seti@home ! – Un système parallèle peut être distribué
– Les machines de tout le monde ● Si assemblage de machines à mémoires
● Puissance virtuellement illimitée indépendantes
– N Gflop/s par machine, des millions des machines – ou non
– Limité à des problèmes très simple ● Si une seule grosse machine parallèle (virtuelle?)
● Calculs indépendants ● Application cible
● Pas de communication ou synchronisation
– Applications parallèles dans les systèmes
entre les instances parallèles
● Modèle plus distribué que parallèle
● Communication, synchronisation, … entre les
différentes instances
2011-2012 13 2011-2012 14

Super-calculateurs Super-calculateurs (2/4)

● Cray Jaguar à ORNL ● Tianhe en Chine


– 20 000 noeuds à 2 opterons six-core – 7000 nœuds à 2 processeurs et 2 GPUs
● Assemblés par réseau Cray spécifique – Un cluster avec des accélérateurs
– Presqu'un Cluster, mais réseau trop spécifique
– 2 Petaflop/s
– Plus d'1 PetaFlop/s

2011-2012 15 2011-2012 16
Super-calculateurs (3/4) Architecture de RoadRunner

● RoadRunner à Los Alamos


– Le premier supercalculateur > 1 PFlop/s
– 3000 noeuds bi-Opterons
– 12000 cartes d'extension avec des
processeurs Cell (8 coeurs spécialisés)
● Le cluster d'opteron est surtout un réseau
d'interconnexion et gestion des Cells

2011-2012 17 2011-2012 18

Super-calculateurs (4/4) Architecture BlueGene

● 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

Comment gérer cette


Systèmes parallèles et distribués
complexité ?
● Quelles responsabilités et charges de
travail pour l'OS et pour l'utilisateur ?
– Et pour le matériel ?
● La complexité doit-elle être
Généralités et concepts
complètement masquée ?
– Accès mémoire distant implicite ?
– Communication implicite ?
– Hétérogénéité masquée ?

2011-2012 27 2011-2012 28

Architecture Mémoire distribuée


● Ensemble de processeurs interconnectés
– Différents types d'interconnexion ● Mémoire privée à chaque machine
● Bus, hiérarchique, switché, … – Mémoire inaccessible directement à distance
– Bus = peu scalable
– Hiérarchique = solution onéreuse dépassée
– Nécessite migration/copie de pages
– Switché = AMD HT, Intel QPI = le futur ? ● Problème de cohérence et partage
– Effets NUMA partout – Utilisation de réseaux traditionnels ou rapides
● Interne ou externe à la machine
● Ethernet, Myri-10G, Infiniband, Quadrics, ...
● Géré en hardware ou en software
– Systèmes faiblement couplés
– Différentes façon de communiquer
● Mémoire partagée ou privée
2011-2012 29 2011-2012 30

Systèmes parallèles ou Systèmes distribués


systèmes distribués ? à grande échelle
● Système distribué
– Partage de ressources
● Machines quelconques
– Tâches indépendantes – Réseau local de stations de travail
● Réseau de stations de travail ● voire géographiquement distribué
– Modèle client-serveur – Grappes de calcul
● Système parallèle ● Reliées par réseau traditionnel
– Mise en commun de ressources pour exécuter – Longue distance, topologie complexe
application gourmande en calcul et/ou mémoire
– Performances faibles et variables
– Mémoire partagée et/ou réseau de machines
– Pare-feu, authentification, sécurité, ...
● Frontière ?
2011-2012 31 2011-2012 32
Communications dans les Communication entre instances
systèmes distribués d'un système distribué
● Systèmes à image unique
● Beaucoup de besoins différents
– Matériel ou logiciel
● Beaucoup d'architectures matérielles ● Mémoire partagée
différentes
– Mécanismes de synchronisation
● Beaucoup de fonctionnalités logicielles – Matériel ou logiciel
différentes ● Échange de messages
● Beaucoup de types de communication – Protocole prédéfini dans l'application
différents – Modèle client-serveur
– Protocoles de haut niveau ● Appel de procédure à distance
– Couches de bas niveau logiciel et/ou matériel ● Bloquant ou non, synchrone ou non
2011-2012 33 2011-2012 34

Communications explicites Communications explicites


Message Passing Interface Remote Direct Memory Access
● RDMA disponible dans matériel HPC (InfiniBand)
– Utilisé en dessous de MPI selon le matériel
● MPI règne dans les systèmes parallèles ● Cible ouvre des fenêtres RDMA et donne
– Passage de messages identifiant aux autres
– Rendez-vous – Les autres peuvent lire/écrire dedans
– Matching pour filtrer ● Modèle « One-sided »
– Primitives bloquantes ou non – Seul l'initiateur de la communication sait qu'elle
– Opérations point-à-point et collectives a lieu et quand elle se termine
● Aucune synchronisation
– Bien si synchronisation ad-hoc par autre moyen

2011-2012 35 2011-2012 36

Systèmes d'exploitation Systèmes d'exploitation


distribués distribués (2)
● Lien étroit avec la façon de programmer
● Interface entre matériel et utilisateur – Conception du système dépend des
● Lien étroit avec le matériel applications cibles
– La conception du système dépend de
● Application parallèles/couplées ou indépendantes
l'architecture – Threads, mémoire partagée, MPI, quelconque, ...

● Faiblement ou fortement couplé


– Applications programmées selon
fonctionnalités du système d'exploitation
– Le système d'exploitation définit la vue de
● Ressources partagées et accessibles de manière
l'architecture par l'utilisateur
transparente
● Ressources virtualisées accessibles de manière – Threads + mémoire partagée ont fortes contraintes
transparente – MPI a des contraintes faibles

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

Système à image unique SSI matériel


● Vision d'une unique machine virtuelle
– Regroupe toutes les ressources de machines
physiques ● Agrégation matérielle de machines
● Transparent pour l'utilisateur ● Partage transparent des processeurs et
● Nœuds anynomes de la mémoire
● Haute disponibilité – Illusion d'une grosse machine NUMA
● Pas forcément centralisé ● SGI NUMAlink
● Impose synchronisation forte entre les
différentes instances du système
2011-2012 43 2011-2012 44

SGI NUMAlink SSI matériel (2/2)


● Intégralement géré par le matériel
– Accès transparent à mémoire distante
● Déréférencement de pointeurs vers mémoire
physique distante
– Cohérence de cache
● Pas de migration des données
– Sauf pour le cache
Schéma SGI
Photo NASA

● Gros travail sur le maintien efficace de la


cohérence entre caches
– Eviter les broadcasts sur les très grandes machines
– « Directory » pour savoir quel cache contient quelle ligne
2011-2012 45 2011-2012 46

Support dans le matériel


Cohérence de cache
pour mémoire partagée
● Cartes réseau permettant le Mapping
d'adresses physiques distantes dans ● La mémoire peut être accessible
l'espace virtuel local directement (déréférençable)
– Dolphin SCI – Mais sans cohérence de cache
– Possibilité de déréférencer pointeur distant ● Même à l'intérieur d'une seule machine
● DSM transparente pour l'utilisateur – Heureusement, c'est rare !
● Mais ça pourrait revenir à la mode à moyen terme

● Nécessite de mettre en place le mapping ● Synchronisation des caches nécessaire


– Dans le pilote (dans l'OS) pendant accès concurrents
● Espace mappable limité
2011-2012 47 2011-2012 48
Cohérence dans SCI Coprocesseurs de calcul

● Peu d'opérations atomiques distantes ● GPGPU, Cell BE, Clearspeed, FPGA, …


– atomic_add_and_fetch ● Périphérique traditionnel (PCI-e)
● Ordre des transactions pas conservé ● Très grosse puissance de calcul
● Mémoire distante non-cachable – Jusqu'à 1Tflop/s par carte
– Lent ou non-cohérent ● Mais très basique aussi
– Incapable de faire des travaux complexes
● Travail nécessaire pour la mise en œuvre – Uniquement du calcul de base
d'une DSM cohérente ● Déjà très utile !

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

Systèmes parallèles et distribués Concepts


● DSM (Distributed Shared Memory)
● Partage de mémoire entre machines
– Au niveau du système ou des applications

Mémoire partagée ● Modèle de programmation simple


Surtout pour les applications parallèles
distribuée

● Bien pour threads, bof si communication explicite
● Exploitation de la mémoire distante
– Pagination à distance
– Cache collaboratif
2011-2012 53 2011-2012 54

Rappels sur la pagination Algorithmes de pagination


● Espace d'adressage virtuel des processus ● Si mémoire saturée, évincer des pages
divisé en pages de taille fixe sur le disque (Swap-out)
– Une table des pages par processus ● Choisir les bonnes pages
● Page virtuelle associée à – LRU
– Pages physiques dans la mémoire principale – FIFO
– Blocs disques dans un espace de Swap – ...
● Traduction virtuel→physique transparente ● Possibilité de pré-évincer pour améliorer
– MMU du processeur les performances (Pré-Swapping)
– Défauts de page – Regrouper les accès aux disques
2011-2012 55 2011-2012 56
Algorithmes de pagination (2) Pagination en mémoire distante
● Swap à distance
– Plus rapide que sur disque
● Si la page est sur le disque, la ramener en
Dépend beaucoup réseau
mémoire principale (Swap-in)

– réseau rapide (10us + 1Go/s) < disque (5ms + 100 Mo/s)


● Évincer une autre page sur le disque – Moins fiable
● Possibilité des précharger pour diminuer ● Utile pour applications irrégulières
le délai d'attente (Pre-faulting) – Peu pour MPI
– Regrouper les accès aux disques ● Utilise souvent toute la mémoire sans swapper
– de manière homogène dans le temps et l'espace
● Calcul out-of-core
2011-2012 57 2011-2012 58

Global Memory Service (GMS) Global Memory Service (2)


● Politique LRU globale
● Utiliser la mémoire des autres nœuds
comme cache entre la mémoire locale et ● Ajustement dynamique des quantités de
le disque mémoire globale et locale
● Gestion de l'ajout/retrait de nœuds ● Nœuds actifs
● Migration des pages non-critiques – Surtout de la mémoire locale
● Pages moins récentes évincées vers autres nœuds
– Pages privées du processus
● Nœuds inactifs
– Pages de fichiers partagés
– Surtout de la mémoire globale
– Les pages utilisées par l'OS ne migrent pas
● Pages anciennes évincées vers disque
● Pas de risque pour l'OS local
● Stockage des pages des autres nœuds
2011-2012 59 2011-2012 60

Global Memory Service (3) Global Memory Service (4)


● Identifier pages anciennes sans ● GMS mis en œuvre dans OSF-1
centraliser un état global ● Mémoire virtuelle des processus et cache
● Informations approximatives sur pages de fichiers unifiés
globales ● Noyau modifié pour tenir compte de GMS
– Informations précises à chaque début lors de l'ajout/retrait de pages
d'époque
● Gestionnaire de cache global
– Changement d'époque après un délai ou un
nombre de migration maximum – Localiser une page
● Le nœud actuellement le moins actif ● Gestionnaires de cache locaux
prend en charge la politique – Manipuler une page
2011-2012 61 2011-2012 62

Mémoire partagée distribuée Retour sur GMS


● Mémoire partagée mise en œuvre sur
mémoire distribuée matérielle ● Mémoire matériellement distribuée et
● Soit par le système d'exploitation ou les logiciellement partagée
middleware ● Uniquement visible pour les noyaux
– Utilisable par toutes les applications – L'application voit plus de mémoire physique
– Pas optimale mais ne peut pas facilement l'exploiter
● Nécessite indications sur besoins de l'application ● Pas conçu pour partage mémoire entre
● Soit par l'application elle-même applications
– Adapté aux besoins de cette application – Conçu pour pagination (Swap) à distance
– Pas réutilisable
2011-2012 63 2011-2012 64
Déréférencer de la mémoire
Objectifs des DSM
distante ?
● Impossible dans le cas général !
– Un processeur ne sait déréférencer que la
● Agréger mémoire matériellement mémoire locale
distribuée ● Et certains bouts de la mémoire des périphériques
● La rendre déréférençable par tout le ● Possible avec aide du matériel
monde – SGI Numalink
● Cohérence de cache ● Avec un SSI matériel, c'est de la triche
– Partage de données entre applications – Mapping distant SCI
– Opérations atomiques ● Mais très limité en espace
● Pas de cohérence de cache
– Travail logiciel pour assurer la cohérence
2011-2012 65 2011-2012 66

Contraintes des DSM logicielles Différents problèmes


● Matériel ne peut pas accéder directement ● DSM matérielle
à mémoire distante – Illusion matérielle d'une grosse NUMA
– Pas de déréférencement explicite – Mêmes problèmes que machines NUMA
– Nécessité de migrer les données localement ● Migration utile pour performance
avant l'accès par le processeur ● Pas indispensable
● Migrer ou répliquer ● DSM logicielle
● Pas de cohérence de cache matérielle – Illusion logicielle
– Empêcher accès concurrents distants – Migration indispensable avant accès distant
● Migrer sans répliquer
● Enorme coût en performance
– Sauf si accès uniquement en lecture – Maintien manuel de la cohérence
2011-2012 67 2011-2012 68

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

Réplication Accès concurrents


● Si aucune écriture
– Utiliser la mémoire locale comme un cache
● Tant qu'il y a de la mémoire disponible ● Si plusieurs processus accèdent aux
● Répliquer les données dans la mémoire mêmes données
locale de tous les nœuds au début du – Géré par la cohérence de cache en local
programme – Comment en faire en distribué ?
– Exploitation localité temporelle et spatiale ● Interdire les accès concurrents ?
– Exploitation parallélisme ● Réplication uniquement en lecture seule

– Application insensible au placement initial


des données
2011-2012 71 2011-2012 72
Cohérence de cache Cohérence de cache (2)

● 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

Consistence et cohérence Consistence et cohérence (2/2)

● Cohérence = ordre des accès à une


variable
– Lecture après écriture retourne la dernière ● Modèles de consistence mémoire
valeur
● Protocoles de cohérence (caches, ...)
● Consistence = ordre global de tous les
accès ● On parle souvent de cohérence par abus
de langage
– Dépendences entre accès à variables
différentes
– Un exemple où la cohérence ne suffit pas ?

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

Propagation des modifications


Propagation des modifications
(2/2)
● Write-Invalidate
● Write-Update
– Invalidation préalabre des copies distantes
– Propagation immédiate des modifications locales
– Propagation quand accès distant
– Nécessite beaucoup de messages et de
synchronisation – Permet plusieurs modifications locales avant
propagation
● Bien si beaucoup d'accès concurrents
● Bien si peu d'accès concurrents
– Beaucoup de gens vont avoir besoin des
modifications, autant leur envoyer tout de suite – Pas besoin de propager immédiatement si
personne n'en a besoin immédiatement
– Pas la peine de maintenir la liste précise des
copies, elle est trop longue – Nécessité d'invalider efficacement
● Broadcast des modifications
● Maintenir la liste exacte des copies distantes
– Elle est censée être petite
2011-2012 79 2011-2012 80
Modèle de Ivy Modèle de Ivy (2)
● Basé sur les pages
● Cohérence séquentielle ● État local possible d'une page ?
● État global d'une page – Invalide
– Lecture par plusieurs nœuds – Lecture seule partagée
– Lecture ou écriture par un seul nœud ● Invalide ou lecture seule sur les autres nœuds
● Garantie d'une cohérence séquentielle – Lecture/écriture exclusive
● Invalide sur les autres nœuds
– Nouvel accès en lecture rapatrie copie locale
● Réplication
● Changement d'état provoqué par les
– Nouvel accès en écriture bloque tout le monde
types d'accès sur les différents nœuds
● Invalidation
2011-2012 81 2011-2012 82

Modèle de Munin Le protocole MSI

● Modified, Shared, Invalid


● Basé sur des objets
● Conçu pour cohérence entre caches
● Cohérence relâchée matériels
● Objets de synchronisation manipulés par – Implémenté en hard dans les processeurs et
l'application pour aider la DSM bus mémoire
– Pas transparent ● Avec améliorations
● Cohérence uniquement assurée quand on – Applicable aux DSM
relâche un objet et qu'un autre l'acquiert ● Pages ou objets de la DSM au lieu des lignes de
cache

2011-2012 83 2011-2012 84

Le protocole MSI (2/2) L'extension MESI

● Signification des états ? ● Ajout de l'état Exclusive


– Éviter le coût de la transition S->M
● Automate de transition entre état ? ● Pourquoi ?
● Que devient l'automate de transition ?
– Lecture ou écriture, locale ou distante

2011-2012 85 2011-2012 86

Les protocoles MESI*


Autres extensions
pour les DSM
● Objets DSM au lieu des lignes de cache
● Etat Owned (AMD)
– Permet de déferrer la mise à jour de la
● État Owned a priori inutile dans DSM
mémoire centrale – Pas de mémoire centrale derrière
● Évite le coût d'accès à la mémoire centrale quand ● Ou ce sont les disques ?
l'accès aux autres caches est plus rapide ● État Forward utile
– Décision dynamique entre Modified+Invalid ou
Owned+Shared – Il faut un responsable par page
● Etat Forward (Intel récent) ● Peut nécessiter de nombreuses diffusions à
– Si une ligne est en S, il y a une copie en F tous les possesseurs d'une page
– Le propriétaire du F se charge de répondre – Broadcast réseau cher
aux demandes – État Exclusive très utile
2011-2012 87 2011-2012 88
Gestion des pages Gestionnaire centralisé

● Un nœud chargé de traiter les demandes


● Répertoires d'attributs ● Contacte le(s) propriétaire(s) de la page
– Localisation des pages virtuelles ● Donne une copie au demandeur
– Protection des différentes copies physiques ● Met à jour le répertoire global
● Un gestionnaire est contacté pour chaque – Nouvel état et propriétaire
changement d'état ● Tout ceci doit être protégé contre les
accès concurrents

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

Stockage des attributs locaux DSM gérée dans l'application

● 1 octet pour le statut local et/ou le ● Contrat entre utilisateur et la DSM


propriétaire probable – Permet de réduire les garanties
● Occupation mémoire proportionnelle à la ● Modèle de consistence
mémoire totale de tous les noeuds ● Plus facile à mettre en œuvre
– Peut-être problématique ● Espace d'adressage virtuel spécifique
● Oublier le propriétaire probable des pages non – Données identifiées par offset
récemment accédées (LRU)
– Primitives d'accès spécifiques
● Et si ca occupe trop de mémoire ? ● val = Lit(addr) au lieu de val = *addr
– Augmenter la taille des pages ? ● Ecrit(addr, val) au lieu de *addr = val

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

Implémentation des Implémentation des


défauts de page dans l'OS (2) défauts de page
● Accès en écriture dans une page en
lecture seule
– Si page locale non partageable
● Si Copy-on-write
● Évaluation des coûts ?
– Dupliquer et autoriser l'écriture ● Nécessité de réfléchir à l'implémentation
Sinon Segmentation fault
du protocole de cohérence

– 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

Gestion du faux partage


Faux partage
par Copy-on-Write
● Illusion de données partagées ● Détecter les modifications locales par Copy-on-
Write
– Ping-pong entre 2 nœuds
– Garder l'original inchangé
● Coût ?
– Faire un diff entre l'original et la copie modifiée
● Comme dans les caches en local ● Envoyer le diff aux autres propriétaires d'une
– Granularité différente copie la page
● Zone quelconque (page?) au lieu de lignes de – Ils vont essayer de fusionner les changements
cache
● Utiliser ceci pour le faux partage
– Maintien de la cohérence
– Et synchronisation sur les zones en vrai partage
● Comme dans les machines NUMA ● Impose de savoir à l'avance les zones en vrai et
– Migration au plus près faux partage
2011-2012 101 2011-2012 102

Double défaut de page Anticiper


● Accès en lecture puis accès en écriture
– Courant quand on modifie une valeur
● Prévoir les prochains accès d'un nœud
– D'où l'extension MESI du modèle MSI – Localité spatiale
● Difficile à éviter si la DSM est basée sur des – Regroupement des accès
défauts de pages matériels ● Facile dans une DSM dans application
– Défauts causés par instructions exécutées par le – L'application peut prévenir elle-même
processeur
● Facile à traiter dans le cas de DSM gérée par
● Détection difficile dans les DSM dans l'OS
l'application – Comme le Read-ahead des fichiers
– Adapter l'interface d'accès à la DSM pour éviter ● Avec accès concurrents
le problème (lecture et écriture simultanées ?)
2011-2012 103 2011-2012 104
Communications lors d'un Comment transférer les
défaut de page dans une DSM données dans une DSM ?
● Synchronisation explicite lors d'un
rapatriement de page
● La tâche doit rester bloquée en attendant
– Requête + attente Réponse
– Et les autres threads ne peuvent pas toucher
à la même zone
– On peut transférer par RDMA entre les 2
● Faire très attention aux accès concurrents
● Destination mémoire précisée dans requête

● Envoi de requête puis bloquer en


● Moins de synchronisation si migration par
attendant réponse (migration de page) anticipation
– Modèle client-serveur simple
– Mais nécessité de prévenir quand la
migration est terminée
● Problème très similaire au final
2011-2012 105 2011-2012 106

Communications lors d'un Comment invalider les copies


changement d'état distantes ?
● Si lecture dans zone invalide ● Connaître la liste des copies
– Trouver la page et rapatrier une copie
– Coûteux en mémoire?
● Si écriture dans zone en lecture seule ● Dépend granularité et taux accès concurrents
– Pas de migration nécessaire – Ajoute des communications
Prévenir les autres lors d'une nouvelle copie
Invalider tous les autres

– Réduit communications lors de l'invalidation


– Rien à faire si on passe de Exclusive à
– Bien si beaucoup d'invalidations et peu de copies
Modified
– Prévenir tout le monde ?
● Prévenir tout le monde, même si inutile
● Comment faire ça efficacement ?
– Bien si beaucoup de copies et pas trop
d'invalidations
● Attendre la confirmation d'invalidation
2011-2012 107 2011-2012 108

Comment invalider les copies Comment traiter les requêtes


distantes ? (2/2) des autres dans une DSM ?
● L'application passe son temps à calculer
– Traitement des besoins locaux pendant
● Comment invalider toutes les copies ? défauts de page (traitants de signaux)
– Broadcast réseau coûteux ? ● Requêtes inattendues des autres
– Multicast ou collectives MPI imposent de peu – Besoins distants difficiles à prévoir
changer l'ensemble des destinataires ● Sauf si anticipation par heuristiques
– Une requête par destinataire – Pouvoir traiter requête à tout moment
● Pipeliner pour réduire le coût ● Thread dédié aux communications entrantes?
● Modèle actif?
– Souvent basé sur des threads en dessous
2011-2012 109 2011-2012 110

Synchronisation distribué Rappels sur la


vs. DSM? synchronisation locale
● Variables de synchronisation stockées ● Mutex
dans la DSM? ● Sémaphore
– Un spinlock serait extrèmement couteux ● Spinlock
● Ping-pong de pages
– Déjà dans une machine NUMA, ça coûte cher
● Utiliser synchronisation par
● Basé sur des opérations atomiques
communication/messages explicites – test_and_set
– Plus de travail pour le développeur mais – cmpxchg
beaucoup plus efficace ● Très lent sur certaines architectures
2011-2012 111 2011-2012 112
Généralisation à la
Retour sur les coprocesseurs
synchronisation globale ?
● Opérations atomiques sur une DSM ?
– Impose cohérence forte
● Cell, GPGPU, … ont mémoire embarquée
● Coûteux sur une DSM hardware
– Les périphériques n'ont pas forcément
– Latence des accès à la mémoire distante d'accès direct à la mémoire centrale
● Très dur et lent sur DSM logicielle ● DMA nécessaire, coûteux
– Ping-pong de pages – Le processeur central n'a pas forcément
accès à toute la mémoire des périphériques
● Trouver d'autres méthodes de ● Même si PIO possible, c'est coûteux
synchronisation
– Passage de messages explicite
2011-2012 113 2011-2012 114

Migration de données entre


Systèmes parallèles et distribués
(co-)processeurs
● Nécessité de migrer les données à coté
du processeur qui les utilise
– Migrer par gros blocs pour masquer la
latence et profiter du débit élevé
● Centaines de nanosecondes et Go/s
Systèmes d'exploitation
● Pas de défauts de pages
– Migration explicite des données
à image unique
● Déterminer les données nécessaires et les
migrer avant de lancer la tâche sur le
coprocesseur
– Granularité libre
2011-2012 115 2011-2012 116

Présentation Types d'applications parallèles


● SSI (Single System Image)
● La grappe est la machine parallèle du
● Tâches parallèles fixes
pauvre – Nombre fixe de processus
– Corriger cela logiciellement – Fortement synchronisés
● Mise en commun et partage des – Allocation du nombre exact de processeurs
ressources de multiples machines ● Tâches dynamiques
physiques – Ajout/suppression de processus
● Exposition de ressources logiques de – Répartir la charge
manière uniforme sur tous les nœuds
2011-2012 117 2011-2012 118

Objectifs des SSI Transparence

● 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...

2011-2012 119 2011-2012 120


Extensibilité Extensibilité (2)

● 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

2011-2012 121 2011-2012 122

Différences avec DSM Migration de tâches

● SSI contient souvent DSM dans l'OS ● Répartir la charge


● SSI partage aussi d'autres ressources – Profiter des machines inactives
– Périphériques ● Disposer des ressources non-partageables
● Migration de tâches entre machines – Co-processeur
– DSM laisse tâche au même endroit et migre – Carte accélératrice
données si nécessaire – ...

2011-2012 123 2011-2012 124

Migration de tâches (2) Quand et quoi migrer ?


● Lors d'un accès à ressource spécifique
– Migrer le processus fautif près de la ressource
● Placer correctement les entrées-sorties ● Quand le système le décide
– Processus accédant aux données
– Équilibrage de charge
● Près des disques
● Politique de décision du nœud cible
– Processus communicants entre eux
● En cas de défaillance
● Près l'un de l'autre
– Restaurer les processus morts
– Si les I/O saturent
● Répartir les processus
● Quand c'est possible
– Processus qui utilise uniquement des ressources
partageables
2011-2012 125 2011-2012 126

Préparer la migration Contraintes sur la migration

● Geler le processus dans un état ● Architecture des machines


exploitable par la machine distante – Identique ou non (PGCD des processeurs)
– Pas au milieu d'un appel système – SMP ?
● Aucune ressource locale en cours de modification
– Plusieurs binaires multi-architecture dans le
– Attendre fin des traitements en cours même exécutable ? Recompilation à la
● Communications, accès disques, ... volée ?
– Références aux données système partagées ● Comment sauver/restaurer les registres entre
doivent être références globales différentes architectures ?
● Encapsulation des ressources physiques – Insérer des points de sauvegarde via le compilateur ?

2011-2012 127 2011-2012 128


Optimiser le
Migration concrète
temps de migration
● Pré-copier les pages mémoire avant le gel
● Migration de toutes les pages mémoire
– Très utile pour pages en lecture-seule
– En utilisant la DSM du système distribué ● Code et certaines données
● Migration du contexte – Possible pour pages en lecture-écriture
– Sauver/restaurer comme lors d'un ● Recommencer la copie si nouvelle modification
changement de contexte avant le gel
● Trouver un compromis
– Utiliser les informations du cache de pages
● Processus interrompu pendant longtemps ● LRU, FIFO, ...

– Charge la machine destination plus tôt


– Comment optimiser ?
– Réduit le temps de migration apparent
2011-2012 129 2011-2012 130

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é

2011-2012 131 2011-2012 132

Reprise après migration (2) Reprise sur erreur


● Migration permet sauvegarde état d'un
processus
● Rapatrier les ressources logiques
nécessaires
– Permet de reprendre l'exécution au même
droit plus tard
– Les relier localement aux ressources
physiques
● En cas de problème, une sauvegarde
permet de reprendre l'exécution
● Pages mémoire, fichiers, sockets, ...
● Restauration du contexte
– Mort d'une des machines
● Processus transférés et relancés sur une autre
– Comme lors d'un changement de contexte
● Nécessite support de stockage fiable et
performant
2011-2012 133 2011-2012 134

Reprise sur erreur (2) Accès mémoire dans les SSI


● Sauvegarde de l'état périodiquement ● DSM au cœur du système
– État vis-à-vis du système ● Partage mémoire entre processus
– État au niveau de l'application – Dépend du SSI
● Communications en cours
– Si DSM complète avec cohérence forte
● L'application se charge de sauver quand ● Partage mémoire normal
elle le juge nécessaire – Sinon, on peut imposer des contraintes, ex :
– En collaboration avec les autres nœuds ● Threads placés sur même machine physique
● Pour disposer d'un état global sauvegardé ● Pas de partage mémoire entre processus
– Pas forcément tous les nœuds en même temps ● Partage mémoire en lecture
● Pour ne pas saturer le système d'entrées-sorties ● Partage mémoire en écriture sans cohérence forte
2011-2012 135 2011-2012 136
Accès transparent
Accès transparent aux fichiers
aux périphériques

● Espace de nommage global ● Périphériques logiques virtualisés


– Système de fichiers distribué – Migration de l'encapsulation
● Migration de pages dans le cache global ● Périphériques physiques
de fichiers – Gestionnaire local relié aux processus
● Migration des descripteurs de fichiers distants l'utilisant par des connexions réseau

2011-2012 137 2011-2012 138

Accès transparent au réseau Accès transparent au réseau (2)

● Bloquer une socket pendant la migration


● Forwarder une socket ?
– Tunnel passant par la machine précédente
– Saturation possible
pour faire suivre les données à la nouvelle
● Données seront ré-émises automatiquement
– Comment réagir aux migrations successives ?
● Transférer données accumulées vers
nouvelle machine
● Migrer une socket ?
– Même adresse IP sur toutes les cartes réseau
● Mettre en place socket entre nouvelle
Problème de routage
machine et la relier aux destinataires

– Changer l'IP associée à la socket ?


● Même problème avec les tubes ● Problème de connexion

2011-2012 139 2011-2012 140

Gestion des cartes réseau Gestion des processus

● Cartes réseau utilisées pour


– Communications dans le SSI ● Nécessité d'identifiants globaux
● Adresse IP privée ?
– Signaux
– Communications entre le SSI et l'extérieur
– Relation père-fils
● Adresse IP globale ou multiples ?
● Réserver chaque carte pour un seul
● Table globale de PID encapsulant des
usage ? processus locaux bas-niveau
● Filtrer les paquets SSI ou normaux ?

2011-2012 141 2011-2012 142

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

2011-2012 143 2011-2012 144


Mise en œuvre
Parallel Virtual Machine
dans le noyau
● Développement complexe ● Système intégré de communication et
– Très intrusif migration de processus
– Difficile à maintenir et faire évoluer – Pour les applications parallèles
● Très flexible ● Démon local sur le nœud
– Transparence totale – Détecte surcharge locale
● Virtualisation de ressources à travers l'interface – Contacte un nœud libre
standard
– Migre la tâche et adapte les communications
– DSM à cohérence forte possible
● Défauts de page
● Mise en œuvre en espace utilisateur

2011-2012 145 2011-2012 146

OpenMosix OpenMosix (2)


● Système probabiliste de détection et
● Version Open-Source de Mosix équilibrage de charge
– Multicomputer Operating System for unIX – Chaque nœud connaît une approximation de
● Système d'exploitation distribué la charge des autres
– Patch pour le noyau Linux – Passe bien à l'échelle
● Ajout/retrait de nœuds à chaud
● Migration du corps des processus
– Pas de reprise sur erreur – Modèle du home-node
● Mandataire reste sur nœud initial
● Très stable mais fonctionnalités limitées – Contexte noyau
● Fin du projet annoncée récemment – Traitement des appels-système
– Lien persistant entre les deux
2011-2012 147 2011-2012 148

OpenMosix (3) OpenSSI

● Pas de vision globale des processus ● Système à image unique


– Utilitaire spéciaux dédiés – Patch pour le noyau Linux
● Pas de mémoire partagée distribuée ● Beaucoup de fonctionnalités
– Pas de migration de threads – Mais limité en performance
– Pas de migration de processus partageant de ● Communication inter-processus
la mémoire
● Ajout/retrait de nœuds à chaud
● Migration des processus manipulant les
– Tolérant aux pannes, sauf sur le nœud racine
sémaphores, sockets, tubes ou fichiers

2011-2012 149 2011-2012 150

OpenSSI (2) Kerrighed


● Vision globale des processus et des ● Système à image unique
périphériques avec les outils standards
– Patch pour le noyau Linux
● Support des méthodes de ● Beaucoup de fonctionnalités et performant
communications inter-processus
– Support des machines SMP encore en
– Mémoire partagée développement
– Sémaphores – Pas d'ajout/retrait de nœuds à chaud, ni de
– Sockets et tubes tolérance aux pannes
● Pas de vision globale de la mémoire ● Version stabilisée en cours de
● Pas de migration de threads individuels développement
2011-2012 151 2011-2012 152
Kerrighed (2) Kerrighed (3)

● Système à image unique ● Notion de Container


– Migration de tâches – Encapsulation migrable de ressource
● Y compris threads individuels virtualisée
● Outils non-standards pour les manipuler ● Fichier
– Mémoire partagée distribuée ● Segment de mémoire partagée
● Vision globale de la mémoire par outils standards
● ...
– Reprise sur erreur pour programmes
– Cohérence séquentielle en cas de partage
séquentiels – Gestion des copies multiples
– Système de fichiers parallèle – Base de la gestion du système global

2011-2012 153 2011-2012 154

Conclusion Virtualisation ?

● La plupart des fonctionnalités sont ● Migration de machines virtuelles pour


supportables tolérer les pannes
– Gros travail de développement et de – Migration transparente des processus dedans
maintenance dans le noyau
● Pourquoi ca marche mieux ?
– Mémoire partagée distribuée contraignante
à mettre en place mais utile – Xen connecté par Bridge Ethernet
– Vue globale des ressources (notamment ● Mettre à jour le switch et ca marche
mémoire et processus) assez aisée à mettre – Ping ARP, …

en œuvre ● Les connexions IP suivent

2011-2012 155 2011-2012 156

Systèmes parallèles et distribués Un domaine souvent étudié...

● FTP, NFS, Coda, AFS, InterMezzo, PVFS,


GPFS, Lustre, Samba, NCPFS, CIFS, DAFS,
XFS, CFS, Sprite, HPSS, GFS, DCE/DFS,
Stockage distribué Cosmos, NFSp, pNFS, DOMAIN, PPFS,
iSCSI, AoE, KerFS, GmailFS, GoogleFS, ...
● La roue a été réinventée plusieurs fois...

2011-2012 157 2011-2012 158

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érentes réponses Différents niveaux


aux besoins (2) de mise en œuvre
● Stockage réparti ou parallèle
– Support de la charge des clients
● Bibliothèque utilisateur
– Réaction à la distribution géographique
– Manipule des chemins, descripteurs et octets
– Essentiel dans les grappes de calcul
● PVFS, Lustre, ...
● Système de fichiers distribués
● Stockage répliqué – Manipule des i-nœuds et octets
– Tolérance aux pannes ● Cache de fichiers distribué
– Essentiel pour les systèmes répartis – Manipule des i-nœuds et pages
géographiquement
● AFS, Coda
2011-2012 163 2011-2012 164

Différents niveaux
Transparence
de mise en œuvre (2)

● Accéder aux données distantes comme si


elles étaient locales
● Système de blocs distribués
– « montage »
– Manipule des blocs logiques
– Interconnexion des espaces de nommage
● Stockage local ou attaché au réseau local et distant
– Manipule des blocs physiques ● Remplacer un répertoire existant par un
répertoire distant et son contenu
● Transition automatique entre les 2 espaces

2011-2012 165 2011-2012 166

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

2011-2012 167 2011-2012 168


Représentation
Cache de fichiers
des fichiers distants
● Conserver données en mémoire
● Nom serveur + identifiant local
– Réduire les accès disques
– Serveur central
● Latence importante et débit limité
● Goulet d'étranglement
● Pas de migration du stockage
– Améliorer la vitesse de lecture
● Identifiant global
– Réduire la durée apparente des écritures
● Écritures physiques déférées en tâche de fond
– Localiser le serveur
– Utilisation de toute la mémoire disponible
● Serveur de noms
● En régime permanent, il n'y a jamais de mémoire
– Cache de noms facile à mettre en place
disponible sur un système moderne

2011-2012 169 2011-2012 170

Différents niveaux de cache Cache coopératif


● Cache de noms
– Localiser des fichiers
● Mettre en commun les caches de
différents nœuds
● Cache de pages sur le client
– Similaire à GMS pour les fichiers
– Réduire les accès au serveur distant
● Accès réseau plus rapide qu'un accès
● Cache de pages sur le serveur disque
– Réduire les accès au matériel de stockage ● Peut être un sur-cache au cache local
● Cache matériel – Rend complexe l'accès aux pages des caches
– Réduire les accès aux périphériques non-locaux
mécaniques
2011-2012 171 2011-2012 172

Cache coopératif glouton Cache coopératif statique


● Les nœuds remplissent leur cache
● Cache associatif global contenant les
indépendamment les uns des autres ensembles des caches locaux des nœuds
– Fonction de hachage pour déterminer le
● En cas de défaut de page nœud gérant la page
– Le nœud contacte le serveur ● Pas de réplication
– Le serveur sait si des nœuds ont la page – Pas de problème de cohérence
● Le serveur envoie lui-même la page si aucun
● Le serveur fait suivre la demande à un nœud qui a
● Contacter le nœud responsable pour
cette page chaque accès
– Le nœud envoie la page à l'initiateur – Trafic réseau
● Goulet d'étranglement – Mauvaise localité spatiale et temporelle
2011-2012 173 2011-2012 174

Cache collaboratif centralisé Cache collaboratif centralisé (2)

● Compromis entre glouton et statique ● Si mémoire serveur saturée, évincer


● Chaque nœud contient pages dans cache global sur autres
nœuds (LRU)
– Cache local privé
– Taux de succès élevé dans cache global
– Cache global = extension cache du serveur ● Variable dans cache local
● Défauts de pages gérés comme dans ● Goulet d'étranglement important
glouton

2011-2012 175 2011-2012 176


Cache collaboratif distribué Cache collaboratif distribué (2)

● Cache glouton avec copies multiples


– Blocs répliqués évincés en priorité ● Mécanisme de cohérence complexe
● Puis LRU ● Réplication implique sous-utilisation de la
– Notion de singleton
mémoire pour le cache
● Favorisés
● Gain en performance par localité
● Blocs cachés dans nœuds qui ont grande
probabilité de les utiliser – Mais beaucoup de messages échangés
● Mis en œuvre dans XFS
● Élimination des blocs migrés plusieurs
fois sans être utilisés
2011-2012 177 2011-2012 178

Cohérence dans le Sémantique de


stockage distribué cohérence Unix
● Nécessaire si
● Modification d'un fichier immédiatement
vue par les autres applications
– Cache dans le client et accès concurrents
– Serveur parallèle ou réparti
● Ne pas cacher les écritures (Sprite)
– Stockage répliqué
– Prendre un jeton avant écriture
– Ne pas accéder au fichier si quelqu'un tient
● Granularité de la cohérence dépend de la
un jeton
structuration des données ● Et invalider le cache
– Blocs – Très lent
– Fichiers ● Expiration du jeton nécessaire pour
– Pages ou segments de fichiers tolérer les pannes
2011-2012 179 2011-2012 180

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

Sémantique Close-Open Écritures seules concurrentes

● Propagation synchronisée par tous les


● Modifications propagées à la fermeture
clients à intervalle régulier
du fichier
– Quand un client a besoin de mémoire
– Un client sera à jour s'il ouvre le fichier juste
après ● Conservation des dates de modification
pour choisir le plus récent
● Propagations périodiques
– Nécessite horloges à peu près synchronisées
– Pas de garantie précise
● Modifications perdues en cas de faux
● NFS, AFS, ...
partage

2011-2012 183 2011-2012 184


Projection de fichier Chargement à l'avance

● Éviter les prochains défauts dans le cache


● Mapping d'un segment de fichier en
des fichiers
mémoire virtuelle
● Regrouper les accès disques
– Accès aux fichiers comme dans une DSM
● Pas de lecture/écriture explicite
● Pas trop tôt
● Déréférencement de pointeur – Sinon gaspillage mémoire et ralentissement
– Adapter protocole de cohérence ● Pas trop tard
● Refuser projections partagées
– Sinon attente de la fin du chargement

2011-2012 185 2011-2012 186

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

● Préchargement des caches de différents


nœuds
● Accès lents à travers le réseau
– Prévoir quel nœud va utiliser quelle partie
d'un fichier

2011-2012 187 2011-2012 188

Accès parallèles Accès parallèles (2)

● Applications parallèles traitent gros


volumes de données
● Définition de segments de données
spécifiques à chaque nœud
– Tous les nœuds lisent et écrivent dans le
même système de stockage – Structure/granularité des données à traiter
dans l'application parallèle
– Même fichier ou fichiers distincts
● Souvent prévisible à l'avance
● Pointeur de fichier partagé ● Adaptation du stockage à cette
– Accès séquentialisés segmentation
● Lent

2011-2012 189 2011-2012 190

Accès parallèles (3) MPI-IO

● Accès par pas


● Extension MPI-2 pour les entrées-sorties
– Ensemble de segments de taille fixée à
intervalle régulier ● Interface utilisateur
● Accès par pas imbriqués – Accès au stockage
– Pattern ou Stride à 2 niveaux – Spécification de Patterns
● Définition d'un type complexe ● Conçu pour applications parallèles
– Passé à l'interface de programmation des – Correspond aux patterns usuels
accès au système de stockage – Orienté performance
● MPI-IO, Vesta, ...

2011-2012 191 2011-2012 192


MPI-IO (2) Fragmentation du stockage

● Répartition des données sur différents


● Définition des éléments/types de base
serveurs
● Ouverture des fichiers ● Distribution de la charge
– Spécification de sous-parties
– Serveur centralisant la gestion de la
– Affectation des sous-parties aux processus fragmentation
● Accès lecture/écriture ● Éventuellement serveur distribué
– Spécification des emplacements mémoire où ● Pas de problème de cohérence
lire/écrire les données ● RAID 0, LVM, PVFS, ...

2011-2012 193 2011-2012 194

Réplication du stockage Réplication du stockage (2)

● Tolérance aux pannes ● Serveurs indépendants


● Distribution géographique – Pas de synchronisation immédiate
– Être près de tous les clients ● Performances non-limitées
● Service centralisé
– Reconnexion et synchronisation régulière
– Fusion des modifications
– Pas de problème de cohérence
● Dernière instance modifiée du fichier
– Goulet d'étranglement possible – Pas de fusion interne au fichier
– RAID 1, LVM, ... – Coda, AFS, ...

2011-2012 195 2011-2012 196

RAID Fragmentation (RAID-0)


● Redundant Array of Inexpensive Disks ● Striped RAID
● Assemblage de disques multiples pour ● Agrégation de disque
créer de gros disques logiques fiables
– Matériel
● Blocs stockés en alternance sur chacun
des disques
● Rapide
– Logiciel ● Granularité élevée (64ko)
● Assez rapide et flexible – Profiter du débiter élevé
– Distribué géographiquement – Recouvrir les temps d'accès
● Performances, capacité, tolérance aux ● Pas de tolérance aux pannes
pannes, extensibilité
2011-2012 197 2011-2012 198

Réplication (RAID-1) Détection des fautes (RAID-3/4)

● Disques dédiés aux bits de parité


● Mirrored RAID
– RAID 3 ou RAID 4
● Disques identiques contenant les mêmes – Plus de disques de données que de disques
données de parité
● Remplacement d'un disque défectueux ● Moins de 50% de perte de capacité
● Réparation en tâche de fond – Agrégation de capacité
– Tolérance aux pannes
● Perte de 50% de la capacité totale
– Coûteux si mis en œuvre logiciellement

2011-2012 199 2011-2012 200


Détection des fautes (RAID-5/6) Stockage parallèle
● Différents niveaux de RAID combinables
– RAID 10, 15, 50, ...
● Bits de parité distribués en Round-Robin
parmi les données ● Mise en œuvre dans serveurs parallèles
pour les grappes
– RAID 5 ou RAID 6
– Agrégation de capacité
– PVFS, …
● Peu de capacité perdue
● L'empilement de toutes ces couches
– Tolérance aux pannes permet de créer du stockage distribué
– Coûteux si mis en œuvre logiciellement
quelconque
– Réplication, répartition, passage à l'échelle,
cohérence, ...
2011-2012 201 2011-2012 202

Accès au stockage par blocs Stockage distant par blocs


● Données non structurées
– Pas de fichiers
– Pas de répertoires
● iSCSI (Internet Small Computer System Interface)
– Cohérence au niveau des blocs
– Connexion TCP dans couche de transport SCSI
● Conçu pour la longue distance
● Verrou global
● AoE (ATA over Ethernet)
– GFS, GPFS, ...
– Blocs ATA transportés dans paquets Ethernet
● Stockage des blocs sur ● Uniquement pour les LANs
– Disques locaux
– Network Attached Storage (NAS)
2011-2012 203 2011-2012 204

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

2011-2012 205 2011-2012 206

Éviter les goulets


Répartir les serveurs
dans les serveurs parallèles

● 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, ...

2011-2012 207 2011-2012 208


Serveur réseau répliqué Serveur réseau répliqué (2)
● Partage en lecture essentiellement
– Moteurs de recherche
● Réplication de sockets ?
– Difficile avec système standard
● Plusieurs processus
– Recouvrement des entrées-sorties
● Routeur évolué au lieu de proxy
– Partager les données entre processus de – Capable de migrer une connexion
machines multiples ● Migrer extrémité socket sur autre serveur ?
● Proxy redirige vers un des serveurs ● Utile si connexions à longue durée
physiques – Connexions courtes souvent négligeables
– Équilibrer la charge ● Sauf si système critique
– Changer de serveur en cas de panne
2011-2012 209 2011-2012 210

IP Spoofing

● Transmettre la requête à un des serveurs


– Ce serveur répond directement à l'émetteur
● Il spoofe l'IP du premier serveur
● Impossible en mode connecté
– UDP seulement
● NFS, RPC, ...
● NFSp

2011-2012 211

Оценить