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)

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 Redo Logs Checkpoint Reference (GUID)..... Blocks Unit of Archival Storage Unit of Coding Fragments NOTE: Each Block needs a GUID Metadata Redo Logs 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)