Post on 03-Apr-2015
Stockage dans DIET
Groupe de travail du 16 décembre 2002
Objectif
➢ Présenter quelques idées d'intégration du stockage dans DIET
➢ Soulever les problèmes qui vont se poser
Stockage dans DIET !?Pourquoi Faire ?
➢ Stocker/Archiver : – Datawarehouse virtuel : tolérence aux pannes, backup
croisé– Accounting/Gestion des quotas
➢ Accélérer les traitements sur de grandes masses de données– Données accédées plusieurs fois (Read Multiple)– Données produites et réutilisées dans DIET (mailleur
-> solveur)
OceanStore (Berkeley)
➢ Motivation : « outsourcing » du stockage➢ Mise en commun de serveurs➢ Accessible de n'importe où➢ Fortement tolérant aux pannes (big one !)➢ Sans coût de maintenance : automatique
➢ Réseau de serveurs : orienté entreprise & institution➢ Serveurs + abonnement➢ Permanence des connections (de haut débit)
http://oceanstore.berkeley.edu
OceanStore : Nommage et Localisation
➢ Fichier GUID➢ SHA-1
➢ Serveur NodeId➢ GUID RootId➢ Pointeurs répliqués➢ Routage : Tapestry
➢ Dynamique➢ Tolérant aux pannes
OceanStore : Les différents objets
➢ Active Data : Replica➢ Tous les réplicas se signalent aux GUID
➢ Archive Data ➢ Fragmentées et dispersés
➢ Modifications des fichiers➢ Conserve toute les versions (GUID spécifique)➢ Le GUID référence la dernière version
Structure d'un fichier
➢ MAJ :“Copy on Write”
Metadata
RedoLogs
Checkpoint Reference (GUID)
. . . . .
Blocks
Unit of Archival Storage
Unit of Coding
Fragments
NOTE: Each Block needs a GUID
Metadata
RedoLogs
Checkpoint Reference (Later Version)
OceanStore : Tolérance aux pannes
➢ Tapestry ➢ Données
➢ Fragmentation + redondance + dispersion➢ Réparation automatique
➢ Disparition, noeuds malicieux➢ Vérification de toutes les données à intervalle régulier
OceanStore sait faire aussi
➢ Introspection➢ Surveillance de toutes les opérations➢ Optimisation automatique (migration de données,
génération de réplicas les plus demandés, ...)➢ Supporte le travail collaboratif
➢ Bayou system (cohérence)➢ Généraux Byzantin
Y a qu'à prendre OceanStore !
➢ Lourd, trop ambitieux– Travail collaboratif ?
➢ Découplé de DIET– Réseau parallèle : Tapestry– Aucune maitrise sur le placement– Schedulling ?!
Bonnes idées d'OceanStore
➢ Fragmentation + redondance– Tolérance aux pannes– Reconstruction rapide : accès parallèles– Recouvrement reconstruction/calcul (streaming)
➢ Réplicats de travail– Gestion LRU
Intégration dans DIET
➢ Placement des fragments– Minimiser les temps de communications pour la
reconstruction● Global, pour l'ensemble de la grille (IDMAPS)● Selon le type de calcul qui seront effectués sur les données
➢ Placement des réplicats – À la demande– Persistance automatique
➢ Intégrer dans FAST le temps de construction du fichier
Ordonnancement et Placement
➢ Papier de K. Ranganathan and I. Foster– Simulation (ChicSim) de la combinaison de
différentes stratégies de scheduling et de placement des réplicats
– Jeux de simulation : exploitation de données HEP● Utilisateurs uniformément distribués ● Tailles des fichiers uniformément distribuées (500Mo -
2Go)● Chaque job traite un fichier de taille D : durée 300D (?)● Fichier plus ou moins populaire : loi géométrique
➢ Stratégies d'ordonnancement– JobRandom– JobLeastLoaded– JobDataPresent– JobLocal
➢ Stratégies de placement des réplicats– DataDoNothing– DataRandom– DataLeastLoaded
➢ Résultat : – Meilleurs stratégies : (DataRandom ou
DataLeastLoaded) et JobDataPresent➢ Bref, ca sert à rien de co-ordonnancer (?!)
Faut il tout faire ?IBP
➢ Internet Backplane Protocole➢ Service de stockage temporaire :
– Noeuds dépots– Service primitif : vision réseau
➢ Evolution : surcouche :– L-Bone : gestion des ressources (interopérable NWS)– ExNode : ~i-node Unix, gestion de la réplication
(fragmentation ?), description XML➢ Chargement parallèle
Travail à faire
➢ Validation IBP– Déployer IBP– Int égrer la fragmentation + redondance (Exnode)– Premières mesures de perf
➢ Intégration dans DIET– L-Bone -> NWS -> FAST– Scheduling– Meta-Data (répertoire globale au niveau de DIET)