Pastis : un système de fichiers P2P

Pastis : un système de fichiers P2P
J-M. Busca, F. Picconi, P. Sens
Equipe REGAL
Journée P2P & Grid computing
GT Sphere – GDR I3
22 juin 2005
page 0
Système de fichier P2P
Espace de
stockage virtuel
■
Principe
●
●
■
agréger l’espace disque des
calculateurs participants
constituer espace de stockage
virtuel unique de grande capacité
Introduction
Architecture
Cohérence
Intérêt
●
stockage données volumineuses
●
haute disponibilité via réplication
●
faible coût
En cours
Conclusion
1
Caractéristiques des systèmes P2P
Problèmes à résoudre
Caractéristiques intrinsèques
nombre élevé de noeuds
100 000+ noeuds
performances
- de localisation
- d’accès aux données
dispersion géographique
échelle planétaire
très haute volatilité
connexions de qq. heures
disponibilité
des données
absence de fiabilité
propriétaires inconnus
sécurité
- des données
- des traitements
Introduction
Architecture
Cohérence
En cours
Conclusion
2
Briques de base du P2P
put(k,b) b = get(k)
Stockage haute disponibilité de blocs
• associe clé k ↔ bloc de donnée b
niveau 2
Distributed
Hash Table
• stocke b sur l’id le plus proche de k
• maintient plusieurs répliques du bloc b
Exemples : Past, DHash, Tapestry, …
route()
notify()
Routage efficace des messages
• noeud : identifiant id, table de routage sur ids
niveau 1
Key Based
Router
• route(k, m) : route m vers id le plus proche de k
Exemples : Pastry, Chord, Kademlia…
Introduction
Architecture
Cohérence
En cours
Conclusion
3
Positionnement de Pastis
Caractéristiques Pastis
Systèmes existants
fichiers en lecture / écriture
CFS : lecture seule
grand nombre d’écrivains
Ivy : # écrivains limité
entièrement décentralisé
OceanStore : 2 niveaux
Axes de recherche
Introduction
●
modèles de cohérence performants
●
garantissant la sécurité des données
●
dans un contexte asynchrone, avec fautes byzantines
Architecture
Cohérence
En cours
Conclusion
4
Plan
■
Architecture générale
■
Modèles de cohérence
■
Travaux en cours
■
Conclusion
Introduction
Architecture
Cohérence
En cours
Conclusion
5
Architecture générale
page 6
Architecture logicielle
Application
Andrew
Benchmark
FS
Pastis
put(Key, Bloc)
Structure fichiers et répertoires
Sémantique des accès
Bloc = get(Key)
DHT
Past
KBR
Pastry
Introduction
Tests de performances
Architecture
Support stable de blocs
(réplication flottante)
Localisation efficace par clés
(routage Plaxton)
Cohérence
En cours
Conclusion
7
Pastry et Past
0
■
2n -1
Organisation
●
noeuds en anneau logique
●
routage par préfixe croissant
●
répliques sur noeuds contigus
route
#567
k=566
#345
■
#513
Bonnes propriétés de localité
●
#561
distance physique prise en compte pour construire les tables de routage
distroutage ≈ 1,4 x distphysique (moy.), < 2 x distphysique (max)
●
route() atteind très souvent la réplique d’un bloc la plus proche en premier
prob(plus proche) ≈ 75%, prob (2 plus proches) ≈ 90%
Introduction
Architecture
Cohérence
En cours
Conclusion
8
Structures de données
Structure de type UFS
inode fichier
- fichier : inode + blocs
- répertoire : fichier spécial
size, ctime, …
clé bloc #1
clé bloc #2
…
clé bloc #12
size, ctime, …
nom1 clé inode 1
clé bloc #1
null
null
nom2 clé inode 2
null
null
null
contenu fichier
…
…
…
…
clé bloc ind. #1
clé bloc ind. #2
clé bloc ind. #3
nom3 clé inode 3
…
…
contenu répertoire
Différence avec UFS
n° d'inode / @ de bloc =
clé de stockage PAST
inode répertoire
Introduction
Architecture
Cohérence
En cours
Conclusion
9
Problèmes restant à résoudre
■
Sécurité des données
par définition, ne peut être déléguée au niveau DHT
coopération entre DHT et utilisateur final
■
Performances des accès
mêmes localisés rapidement, les données restent distantes
définition de modèles de cohérence optimisant les accès
■
Cohérence des répliques (au niveau DHT)
pas de gestion de données modifiables par la DHT
cohérence des répliques à assurer au niveau supérieur
Introduction
Architecture
Cohérence
En cours
Conclusion
10
Stockage des données
■
■
Objectifs
●
assurer l'intégrité et l’authenticité des données stockées
●
malgré la malveillance possible des noeuds de stockage
Solution
●
ensemble de conventions entre DHT et utilisateurs
●
liant le contenu d'un bloc et sa clé de stockage
●
via des techniques cryptographiques
différents types de blocs : CHB et UCB
Introduction
Architecture
Cohérence
En cours
Conclusion
11
Content Hash Bloc (CHB)
■
■
■
Convention
●
Kstock = SHA-1(Bloc)
●
DHT.put(Kstock, Bloc)
Bloc
Kstock
Vérification
●
Bloclu = DHT.get(Kstock)
●
SHA-1(Bloclu) == Kstock ?
SHA-1(d+s)
Discussion
…
…
données
…
…
…
sel
☹ Kstock ≠ identifiant logique de bloc
☹ données non modifiables
☺ caching facile
Introduction
Architecture
Cohérence
En cours
Conclusion
12
Public Key Bloc (PKB)
■
■
■
Convention
Bloc
●
PKB associé à (Kpub, Kpriv)
●
Kstock = SHA-1(Kpub)
●
DHT.put(Kstock, {Bloc, Sig(Bloc, Kpriv)})
Kstock
Vérification
●
{Bloc, Sig}lu = DHT.get(Kstock)
●
SHA-1(Bloc.Kpub) == Kstock ?
●
verifySig({Bloc, Sig}lu, Kpub) ?
Kpub
n° version
Sig(Kpriv)
Discussion
●
Kstock = identifiant logique
●
mise à jour “en place”
●
coût de lecture élevé
Introduction
Architecture
Cohérence
…
…
données
…
…
En cours
Conclusion
13
User Certificate Block (UCB)
■
■
■
Bloc
Principe
Kstock
●
PKB amélioré pour multi-écrivains
●
utilisateur associé à (Kpub util, Kpriv util)
●
certificat “droit d'écriture” sur bloc
Vérification
●
validité certificat via Kpub bloc
●
validité bloc via Kpub util. du certificat
Kpub bloc
n° version
Sig(Kpriv util.)
Discussion
Kpub bloc
Kpub util.
date expiration
Sig(Kpriv bloc)
☺ diffusion Kpriv bloc inode inutile
☺ retrait droit d’écriture possible
☹ coût de lecture élevé
Introduction
Architecture
…
…
données
…
…
Certificat
Cohérence
En cours
Conclusion
14
Utilisation des blocs
contenu répertoire
nom1 clé inode 1
size, ctime, …
nom2 clé inode 2
clé bloc #1
clé bloc #2
…
clé bloc #12
nom3 clé inode 3
…
…
CHB
■
Avantages
●
●
inode fichier
…
…
…
clé bloc ind. #1
clé bloc ind. #2
clé bloc ind. #3
UCB
bloc = CHB : accès rapide,
caching efficace
■
inode = UCB : mises à jour
circonscrites au fichier
Introduction
contenu fichier
Architecture
Cohérence
CHB
Compromis entre
●
performances lecture / écriture
●
granularité des mises à jour
En cours
Conclusion
15
Implémentation des lectures /
écritures
■
■
■
Lecture d’un fichier
●
lire l’inode + vérifier son intégrité
●
lire les blocs référencés + vérifier leur intégrité
Ecriture – pour chaque bloc modifié :
●
écrire le bloc dans un nouveau CHB
●
modifier l’adresse de stockage dans l’inode
●
signer l’inode et l’écrire dans son UCB
Avantages / inconvénients
☺le contenu de l’inode matérialise une version du fichier (snapshot)
☹ impossible de fusionner deux inodes signés pour fusionner des mises à jour
Introduction
Architecture
Cohérence
En cours
Conclusion
16
Modèles de cohérence
page 17
Modèles de cohérence
■
■
■
Objectifs
●
permettre un accès performant aux fichiers
●
en gardant une sémantique claire et utilisable
Facteurs de bonnes performances
●
diminuer le nombre d'accès aux blocs
●
diminuer la latence des accès aux blocs
Deux modèles de cohérence implémentés
●
close-to-open (défini dans Andrew FS)
●
read-your-writes (inspiré de Bayou)
Introduction
Architecture
Cohérence
En cours
Conclusion
18
Modèle close-to-open (CTO)
■
Définition
●
open() : retourne la dernière version du fichier validée par close()
●
entre open() et close() : seule les mises à jour locales sont vues
O
R(1)
W(2)
R(2)
C
O
R(2)
util. 1
O
R(1)
W(3)
C
util. 2
O
R(2)
R(2)
util. 3
Introduction
Architecture
Cohérence
En cours
Conclusion
19
Modèle CTO – Discussion
■
■
■
Intérêt pour l’utilisateur
●
lit toujours la dernière version du fichier
●
cette version est toujours cohérente (cohérence interne)
●
la cohérence est maintenue durant tout l’accès au fichier
Intérêt pour les performances
●
pas de relectures périodiques à faire après l'open()
●
pas de modification à propager avant close()
Implémentation facilitée par Pastis (snapshots)
●
la lecture de l’inode sur open() arrête le contenu du fichier
●
seule l’écriture de l’inode sur close() valide les mises à jour
Introduction
Architecture
Cohérence
En cours
Conclusion
20
Ecriture et résolution des conflits
■
■
A résoudre
●
résolution des conflits de mise à jour au niveau file system
●
cohérence des répliques d’UCB au niveau DHT
Solution
●
version de fichier identifiée par V = (versionUCB, kpriv. util.)
●
incrémentation de V.versionUCB avant chaque écriture de l’UCB
●
un UCB est enregistré dans Past si et seulement si : Vécrite > Vstockée
util.
répliques
Past.insert( inode )
Introduction
Architecture
Cohérence
En cours
Conclusion
21
Lecture des UCB
■
■
Problèmes
●
attaques de roll-back possibles (noeuds byzantins)
●
réplication paresseuse des blocs (implémentation Past)
Conséquences
●
possibilité de lecture d'une version obsolète d’un UCB
●
pour déterminer la dernière version : lire toutes les répliques, et retenir
celle de plus grand numéro de version
coût et latence très élevés
util.
Past.fetch (replique)
répliques
Past.lookupHandles(inode)
Introduction
Architecture
Cohérence
En cours
Conclusion
22
Performances CTO
400
CHB read+write
UCB write
UCB read
350
coût : 40%
Execution Time (s)
300
250
200
150
100
50
0
Phase 1
Phase 2
Phase 3
Phase 4
Phase 5
Total
Benchmark Phases
Introduction
Architecture
Cohérence
En cours
Conclusion
23
Modèle read-your-writes (RYW)
■
Définition
idem close-to-open, sauf sur open() : la version du fichier
retournée est au moins aussi récente que la dernière lue
O
R(1)
W(2)
C
O
R(2)
util. 1
O
W(3)
C
util. 2
Introduction
Architecture
Cohérence
En cours
Conclusion
24
Modèle RYW – Discussion
■
Domaines d’application
●
fichiers non partagés avec d’autres utilisateurs
●
accès ne nécessitant pas la toute dernière version du fichier
Exemple : imprimer un fichier pour lire ses propres modifications
■
Intérêt pour les performances
●
diminution du coût de open() : la lecture d’une réplique récente suffit
●
lecture à faible coût une version plus récente que la version locale
Introduction
Architecture
Cohérence
En cours
Conclusion
25
Implémentation du modèle RYW
■
Cache local : clé inode → Vréférence
■
Modification de l’appel Past lookup(key)
■
●
introduction d’un critère de recherche : V ≥ Vreférence
●
arrêt de la recherche dès la réplique trouvée
Gain en latence
●
toutes les répliques satisfont V ≥ Vreférence (écritures simultanées)
●
Pastry accède à la plus proche avec une haute probabilité (localité)
util.
répliques
lookup()
Introduction
Architecture
Cohérence
En cours
Conclusion
26
Performances RYW
400
CHB read+write
UCB write
UCB read
350
gain : 33%
Execution Time (s)
300
250
200
150
100
50
0
Phase 1
Phase 2
Phase 3
Phase 4
Phase 5
Total
Benchmark Phases
Introduction
Architecture
Cohérence
En cours
Conclusion
27
Travaux en cours
page 28
Cohérence stricte
■
■
■
Limites du système actuel
●
pertes de mises à jour sur accès concurrents
●
y compris pour les répertoires (open, rename, unlink)
Fournir mécanisme pour cohérence stricte
●
à la demande, pour les applications
●
systématique, pour les répertoires
Différentes implémentations
●
verrouillage (valable pour fichiers et répertoires)
●
atomic broadcast (valable pour les répertoires)
Introduction
Architecture
Cohérence
En cours
Conclusion
29
Preuve de Pastry
■
But final : prouver la correction des mécanismes
●
de lecture / écriture d’inode
●
de verrouillage d’inode
Past.put(UCB)
Past.get(UCB)
t
évolution du réseau
■
Etapes préalables : établir les propriétés des couches Pastry / Past
●
prouver la correction des insertions / retraits de noeuds
●
majorer l’erreur de routage quand le réseau est instable
●
modéliser le mécanisme de réplication paresseuse des blocs Past
●
minorer l’intersection entre deux ensembles de répliques interrogées
Introduction
Architecture
Cohérence
En cours
Conclusion
30
Conclusion
page 31
Résumé
■
■
Caractéristiques de Pastis
●
entièrement décentralisé, scalable
●
assure l’intégrité des données et la cohérence interne des fichiers
●
bonnes performances (seulement 1,4 à 1,8 fois plus lent que NFS)
Enseignements
●
contraintes de sécurité importantes
●
impact sur les performances et les modèles de cohérence implémentables
Introduction
Architecture
Cohérence
En cours
Conclusion
32
Pistes d’évolutions futures
■
■
■
Ajout de nouveaux modèles de cohérence
●
inspirés des bases de données
●
ou des mémoires partagées réparties
Suppression des CHB inutilisés
●
ramasse-miette distribué, en fonction des fichiers ouverts
●
respect des contraintes de sécurité
Implémentation de la confidentialité
●
de façon transparente pour les utilisateurs
●
en utilisant l’encryption convergente (factorisation)
Introduction
Architecture
Cohérence
En cours
Conclusion
33
Liens
Pastis : http://regal.lip6.fr/projects/pastis
LS3 : http://regal.lip6.fr/projects/pastis/ls3
Pastry, Past : http://freepastry.rice.edu
Introduction
Architecture
Cohérence
En cours
Conclusion
34