Gestion de données dans un environnement distribué.

Présentation au sujet: "Gestion de données dans un environnement distribué."— Transcription de la présentation:

1 Gestion de données dans un environnement distribué.
Un exemple d’intergiciel de grille: SRB. Jean-Yves Nief, CC-IN2P3, Lyon Journées Informatiques IN2P3/DAPNIA, 18–21 Septembre 2006

2 Aperçu. Introduction: big science, big data, big problem.
SRB: un exemple d’outil de gestion de données distribuées. Distribution et gestion des CC-IN2P3: quelques exemples dans différents domaines (HEP, astroparticule, applications biomédicale) utilisant SRB. Gestion des données ailleurs: quelques exemples intéressants d’applications de gestion des données dans divers domaines. Chausse-trappes et défis: le choix et le déploiement des outils de gestion n’est pas la fin de l’histoire. Perspectives. JI IN2P3/DAPNIA, 18/09/06

3 Introduction. JI IN2P3/DAPNIA, 18/09/06

4 La situation actuelle. Grand volume de données produites par les projets scientifiques. Ordre de grandeur: ~ 100 To, ~ Po, millions d’enregistrements. Dans divers domaines: HEP (SLAC, Fermilab, CERN etc..). Astrophysique (simulations: Enzo, Terascale Supernova Initiative…, données issues d’observations: Eros, MACHO, 2MASS, USNO-B, SDSS, IVOA …). Sciences de la terre (Terashake, Terra …). Biologie / Biomédical (BIRN …). JI IN2P3/DAPNIA, 18/09/06

5 Et l’avenir .... Difficile à dire mais déjà quelques indications.
Quelques exemples (prochaine décennie): DOE Genomics, GTL program. Biblitohèque numérique pour l’administration US (NARA). Ordre de grandeur: ~ Eo, des trillions d’enregistrements ! Explosion de la quantité de données et metadonnées. Plus large variété d’acteurs! Aussi vrai pour la partie réseau (page 6: source ESnet). JI IN2P3/DAPNIA, 18/09/06

6 Science Areas Today End2End Throughput 5 years End2End Throughput 5-10 Years End2End Throughput Remarks High Energy Physics 0.5 Gb/s 100 Gb/s 1000 Gb/s high bulk throughput Climate (Data & Computation) Gb/s N x 1000 Gb/s SNS NanoScience Not yet started 1 Gb/s 1000 Gb/s + QoS for control channel remote control and time critical throughput Fusion Energy 0.066 Gb/s (500 MB/s burst) 0.198 Gb/s (500MB/ 20 sec. burst) time critical throughput Astrophysics 0.013 Gb/s (1 TBy/week) N*N multicast computational collaborations Genomics Data & Computation 0.091 Gb/s (1 TBy/day) 100s of users high throughput

7 Un monde numérique. Beaucoup de projets scientifiques ou de bibliothèques numériques impliquant des collaborateurs / utilisateurs dispersés. Gros besoins de stockage. Nécessité d’un backup de données. Et/ou besoin des données proches des utilisateurs (replicats sur différent sites). Besoin d’outils collaboratifs pour échanger des données. Fédérer les ressources informatiques distribuées. JI IN2P3/DAPNIA, 18/09/06

8 Pré-requis (I). Prise en compte d’un environnement hardware hétérogène. Prise en compte d’un environnement de stockage hétérogène (cartouches, disques, base de données). Prise en compte d’un environnement hétérogène pour les OS. Prise en compte de politique variées de préservation des données à travers l’environnement distribué. JI IN2P3/DAPNIA, 18/09/06

9 Pré-requis (II). Virtualisation du stockage: Organisation virtuel:
Developpement d’applications clientes transparentes aux évolutions technologiques des systèmes de stockage sous-jacents. Organisation virtuel: Droits d’accès. Gestion des groupes, domaines: politique . Politiques de conservation des données. JI IN2P3/DAPNIA, 18/09/06

10 Pré-requis (III). Indépendence infrastructure:
Virtualisation des données: Gestion de l’espace des noms indépendents des lieux de stockage. Support des opérations d’accès indépendamment des lieux de stockage. Authentification: Certificats: GSI etc… Mécanisme de challenge-réponse: pas de mot de passe envoyé à travers le réseau. Mot de passe encrypté. Ticket: valide pour un certain temps pour accéder à l’organisation virtuelle. JI IN2P3/DAPNIA, 18/09/06

11 Pré-requis (IV). Propriété des données / Autorisation:
Gestion de la propriété des fichiers à travers plusieurs sites (découplage partiel ou total entre l’organisation interne de chaque site et l’organisation virtuelle). ACLs valides pour l’ensemble de l’organisation virtuelle (domaines, groupes, utilisateurs etc…). Tickets: valide pour un laps de temps donné pour accès aux données. JI IN2P3/DAPNIA, 18/09/06

12 Pré-requis (V). Data operations: Accès aux fichiers:
Open, close, read, write, stat… Audit, gestions des versions, « pinning », checksums, synchronisation etc… I/O parallèles, interactions avec les pare-feu. Gestion des temps de latence: Opérations «massives»: enregistrement, transfert, effacement etc… Procédures : réplication, agrégation, parsing des fichiers, requêtes I/O (FITS, DICOM, HDF5 …). Gestion des métadonnées: Annotations, requêtes sur métadonnées / audit, interface avec des systèmes d’informations divers (extension du schéma de l’infrastructure de base). JI IN2P3/DAPNIA, 18/09/06

13 SRB: Storage Resource Broker.
JI IN2P3/DAPNIA, 18/09/06

14 Qu’est-ce que SRB ? Storage Resource Broker: développé par le SDSC (UC San Diego) à partir de 1998. Fournit une interface uniforme à des systèmes de stockage hétérogènes: remplit une très grande partie des pré-requis précédents. Outil collaboratif d’échange de fichiers. Qui utilise SRB ? HEP (BaBar, Belle). Biologie, applications biomédicales (ex: BIRN, BBSRC, IB …). Astrophysique, Sciences de la Terre (ex: NASA). Bibliothèques numériques (ex: NARA). Dans le monde entier: USA, Europe, Asie, Australie. JI IN2P3/DAPNIA, 18/09/06

15 Architecture SRB. 1 zone:
1 ou (n) serveur(s) SRB/MetaCatalogue: contient la liste des fichiers, ressources physiques, utilisateurs, ACLs etc… Plusieurs serveurs SRB pour l’accès aux données à l’endroit de stockage. SRB Site 3 SRB MCAT (4) (2) Site 1 (3) test1.txt SRB Site 2 (1) Application (demande test1.txt, connexion à site 2 par ex.) JI IN2P3/DAPNIA, 18/09/06

16 Interfaces, portabilité.
Commandes binaires (Scommands). APIs: C, Java, Perl, Python. Interface Web (mySRB). Client graphique pour Windows (inQ). Portabilité: Linux, Windows, Mac OS, Solaris, etc… Bases de données: Oracle, DB2, Sybase, PostgreSQL, Informix … JI IN2P3/DAPNIA, 18/09/06

17 Distribution et gestion des données au CC-IN2P3: exemples d’utilisation de SRB.
JI IN2P3/DAPNIA, 18/09/06

18 SRB @ CC-IN2P3 En vert = test, évaluation. HEP: Astroparticule:
BaBar (SLAC, Stanford). CMOS (International Linear Collider R&D). Calice (International Linear Collider R&D). Astroparticule: Edelweiss (Modane). Observatoire Pierre Auger (Argentine). Astrophysique: SuperNovae Factory (Hawaii). Applications biomédicales: Neuroscience. Mammographie. Cardiologie. JI IN2P3/DAPNIA, 18/09/06

19 Vue d’ensemble. 3 serveurs SRB: MCAT:
1 Sun V440, 1 Sun V480 (Ultra Sparc III), 1 Sun v20z (AMD Opteron). OS: Solaris 9 and 10. Espace disque total: ~ 8 TB HPSS driver (non DCE): Utilisation de HPSS 5.1. MCAT: Oracle 10g. Environnement avec de multiples OS pour clients et autres serveurs SRB: Linux: RedHat, Scientific Linux, Debian. Solaris. Windows. Mac OS. Interfaces: Scommands invoquées à partir d’un shell (scripts). Java APIs. Perl APIs. Web interface mySRB. JI IN2P3/DAPNIA, 18/09/06

20 BaBar et SRB. Utilisé en production depuis Avril 2004.
Gain de temps considérable dans le développement des applications de gestion. Accès transparent aux données: Très pratique dans un env. hybride (bandes + disques). Facile d’étendre le service (ajout de serveurs à la volée). Indépendence au niveau de l’application cliente de l’endroit où se trouvent les fichiers. Procédures de publication et d’import des données entièrement automatisées. Facile pour Slac de récupérer des données perdues. 300 To ( files) migrées à Lyon. Max. de 3 To / jour de cartouche à cartouche. Maintenant possibilité de monter jusqu’à 5-6 To / jour. JI IN2P3/DAPNIA, 18/09/06

21 Architecture SRB BaBar.
2 Zones (SLAC + Lyon) SRB (2) (1) (3) SRB HPSS/Lyon HPSS/SLAC SRB SRB SRB MCAT SRB MCAT CC-IN2P3 (Lyon) SLAC (Stanford, CA) JI IN2P3/DAPNIA, 18/09/06

22 Neuroscience (P. Calvat).
IRM Siemens MAGNETOM Sonata Maestro Class 1.5 T (Lyon hospital) DICOM DICOM DICOM DICOM DICOM Acquisition DICOM SRB Consol Siemens Celsius Xeon (Window NT) FTP, File sharing, … Export PC Dell PowerEdge 800 DICOM DICOM

23 Neuroscience (II). But: rendre SRB invisible aux utilisateurs.
Plus de 500,000 fichiers répertoriés. Enregistrement de données de recherche provenant des hôpitaux de Lyon et Strasbourg: Procédure automatique incluant l’anonymisation. Interfacé avec l’environnement MATLAB pour l’analyse. ~ 1.5 FTE pour 6 mois. But: rejoindre le réseau BIRN (US biomedical network). JI IN2P3/DAPNIA, 18/09/06

24 Deployé mais tests à effectuer.
Cardiologie. SRB (Hôpital de Lyon) CC-IN2P3 PACS Deployé mais tests à effectuer. PACS (système d’information interne à l’hôpital): invisible du monde extérieur. Interfacé avec un serveur SRB à l’hôpital grâce au driver SRB/DICOM (CR4I, Italie). Données du PACS publiées dans SRB et anonymisées à la volée. Possibilité d’échanger de façon sécurisée des données. JI IN2P3/DAPNIA, 18/09/06

25 Gestion des données ailleurs: quelques exemples.
JI IN2P3/DAPNIA, 18/09/06

26 Neuroscience: BIRN (I).
BIRN = BioInformatics Research Network Imagerie cérébrale (humain, animaux: souris, singes): - IRMf, TEP, MEG etc… Partage et échange de données expérimentales entre chaque labo et projets. JI IN2P3/DAPNIA, 18/09/06

27 Neuroscience: BIRN (II).
BIRN Coordination Center à San Diego: 1 rack (serveur SRB, base de données etc…) sur chaque site. Administration centralisée à partir du BIRN-CC: 24/7. Partage de logiciel, APIs… 15 millions de fichiers (16 To), 360 utilisateurs: recherche de fichiers à partir de métadonnées sur l’ensemble des catalogues (impressionnant!) Hôpital John Hopkins: « done more in 6 months than in 18 years ». BIRN: 30 personnes au premier meeting (2001), 115 en Février 2005, presque 400 maintenant  succès. Démarrage de sites en Europe: Edinburgh, Manchester. Certainement un site français dans un avenir proche. JI IN2P3/DAPNIA, 18/09/06

28 ROADNet (UCSD). Observation temps réel, Applications et réseau de gestion de données. Le problème: Gestion intégré en temps réel de vastes flux de données hétérogènes et distribués provenant d’un réseau de capteurs. Capteurs: Seismometers, Accelerometers, Displacement, Barometric pressure, Temperature, Wind Speed, Wind Direction, Infrasound, Hydroacoustic, Differential Pressure Gauges, Strain, Solar Insolation, pH, Electric Current, Electric Potential, Dilution of oxygen, Still Camera Images, Codar. Projet pluridisciplinaire: Sismologie. Oceanographie. Hydrologie. Météorologie. etc… JI IN2P3/DAPNIA, 18/09/06

29 ROADNet (UCSD). Grille pour du temps réel, gestion de flux de données.
DATASCOPE Archives/Processing/Review (ORB= Online Ring Buffer) Grille pour du temps réel, gestion de flux de données. JI IN2P3/DAPNIA, 18/09/06

30 Chausse-trappes et problèmes.
JI IN2P3/DAPNIA, 18/09/06

31 Chausse-trappes potentiels.
Pour construire un environnement viable connectant des sites éparpillés: Bonne coordination et communication entre les administrateurs des sites: facteur « social ». Manpower: nécessaire dans divers domaines (réseau, sys. admin. et bases de données). Le décalage horaire rend les choses plus compliquées. JI IN2P3/DAPNIA, 18/09/06

32 Besoins matériels. Réseau: Serveurs:
% de paquets perdus doit être très faible. Réseaux haute latence (Round Trip Time > 100 ms): source d’inefficacité. Duplication des systèmes d’information (bases de données) doit être considérée (ex: expérience Belle avec des sites en Australie, Japon, Corée du Sud). Serveurs: Baie de disque de qualité: corruption des données etc… Duplication des données peut être un frein important au niveau budgétaire. Serveurs de base de données dimensionnés correctement. JI IN2P3/DAPNIA, 18/09/06

33 Autres besoins. Intégrité des données (checksum).
Stratégie de backup pour prévenir les pertes de données. Extensibilité du middleware. Middleware doit être multi OS. Tolérance au panne du système. Compatibilité des applications clientes en fonction des évolutions du middleware: prévenir les migrations douloureuses. Middleware doit être aussi transparent que possible aux évolutions technologiques (matériel, bases de données …). JI IN2P3/DAPNIA, 18/09/06

34 La grille, la solution ? Est-ce qu’un environnement « grid » est toujours la solution ? Pas évident !!! Coût en termes de: Matériel. Réseau. Manpower (plus de sites, plus de données dispersées, plus d’admins). peut être prohibitif. JI IN2P3/DAPNIA, 18/09/06

35 Perspectives. JI IN2P3/DAPNIA, 18/09/06

36 Résumé et perspectives (I).
Intergiciel: nécessaire pour une gestion efficace pour des données réparties sur plusieurs sites. Extensibilité: pb potentiel à l’avenir pour les systèmes d’information (bases de données) : Inflation des métadonnées. Inflation du nbre de fichiers. Coût économique et humain souvent négligé. JI IN2P3/DAPNIA, 18/09/06

37 Résumé et perspectives (II).
SRB: un très bon candidat. iRODS (Intelligent Rule Oriented Data management System): Remplacement de SRB à terme (license BSD, à maturité dans 3-4 ans). Base: Compatible avec SRB (1 appli SRB pourrait se connecter à un serveur iRODS). SDSC a démarré le projet. CC-IN2P3, un des premiers partenaires qui va être engagé dans les spécifications, tests et peut-être développement. JI IN2P3/DAPNIA, 18/09/06

38 Remerciements & Références.
Reagan Moore et son équipe (SDSC, USA). Adil Hasan (CCLRC-RAL, UK). Wilko Kroeger (SLAC, USA). Pascal Calvat (CC-IN2P3, France). BIRN: ESnet: ROADNet: SRB: CC-IN2P3: JI IN2P3/DAPNIA, 18/09/06