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)