Perspectives pour le stockage des données scientifiques. Jean-Yves Nief (CC-IN2P3)

Transcription

1 Perspectives pour le stockage des Jean-Yves Nief (CC-IN2P3)

2 Vue d ensemble de la présentation! Etat des lieux pour le stockage des données.! Evolutions matérielles: Disque dur, SSD, bandes magnétiques.! Etat des lieux et évolution au niveau logiciel: Accès aux données pour I/O intensif, «tiering». Gestion/distribution des données. Archivage pérenne. Place de la grille, cloud et big data? 2

3 État des lieux 3

4 Les besoins des projets scientifiques! Explosion de la masse des données produites (issues des dispositifs expérimentaux et simulations): LHC: ~ dizaine PB / an Astroparticle/astrophysique: volume de l ordre du ~ PB fréquent pour les futurs projets (advirgo, CTA ). LSST: base de données du LSST (15-20 PB dans la décennie à venir!), > 150 PB de données brutes, ~ EB de données dérivées? SKA: ~ EB / jour!!! 4

5 Les besoins des projets scientifiques! Explosion de la masse des données produites (issues des dispositifs expérimentaux et simulations): Biologie: Séquençage génomique: actuellement de l ordre du Po. Microscopie confocale: 1000 images/s => qques Go /s " débit de production LHC. Sciences humaines et sociales: Numérisation des ouvrages, documents audio-visuels etc : actuellement 3 Po pour la Bibliothèque du Congrès, à l avenir d autres projets à l échelle de la centaine de Po. Science de la terre: Geophysique: simulation de tremblement de terres, capteurs etc : ~ Po 5

6 Ex: projection des besoins au CC-IN2P3 (astro + LCG) Volume disque (TB) Volume bande (TB) Hypothèse: LCG: +10% / an expérience type HEP: ratio disque/bande = 30% 6

7 Les besoins de stockage! Traitements et analyses par des dizaines de milliers de processeurs:! Accès performant aux données # I/O intensif.! Type de système de stockage adapté suivant la nature des données (structure interne et type d accès):! Système de fichiers distribués.! Serveurs de données distribués: à la mode Hadoop, systèmes «maison» (ex: pour HEP: dcache, xrootd), etc! Bases de données relationnelles, orientés objet, clé/valeur.! Stockage hiérarchique: Utilisation de media plus ou moins économiques suivant l activité sur les données: systèmes hybrides ou «tiering». 7

8 Les besoins de stockage! Gestion des données: Droits d accès. Gestion du cycle de vie complet (replications, intégrité des données, provenance, audit, propriété des données, metadonnées de tout type, annotations, etc ).! Archivage pérenne: Capacité à conserver des données pour une période de rétention très longue voire infinie. Capacité à relire ces données dans le futur pour de nouvelles analyses # nécessité de faire évoluer le format des données au cours du temps Metadonnées (informations) associées à ces données. 8

9 Les challenges! Accès aux données potentiellement très intensif: Des centaines de milliers de procs accédant à des dizaines ou centaines de PBs.! Utilisateurs et données géographiquement distribués: Centres de traitement multiples. Supports physiques et technos de stockage hétérogènes.! Obsolescence rapide des supports de stockage: migration massive vers de nouveaux supports à opérer régulièrement # intégrité des données.! Conservation des données sur le long terme. 9

10 Les challenges! A différents niveaux: Au niveau des media. Au niveau des systèmes d accès et de gestion des données. Au niveau de l interaction entre les applicatifs et les données. Au niveau de l organisation globale des infrastructures (centralisé, distribué, «cloudifié»). 10

11 Évolutions matérielles 11

12 Les media! Supports de stockage: Bandes magnétiques. Disques durs. SSD. 12

13 Bandes magnétiques! Cible: archivage, stockage de masse.! Avantages: Cout faible au GB. Faible consommation électrique.! Inconvénients: Investissements nécessaires dans des lecteurs et une robotique. Temps de latence montage, positionnement, démontage des bandes. Logiciel d accès aux données pour faciliter l accès via des couches d abstraction (mais solutions à la mode LTFS disponible maintenant). 13

14 Bandes magnétiques! Exemples de performance: Media Capacité Débit T10KA 120 & 500 GB 120 MB/s T10KB 1 TB 120 MB/s T10KC 5 TB 240 MB/s T10KD 8.5 TB 252 MB/s LTO4 800 GB 120 MB/s LTO6 2.4 TB 160 MB/s 14

15 Bandes magnétiques Evolution pour les LTO (actuellement génération 6): 15

16 Disques durs! Cible: accès «rapide» aux données.! Avantages: Media de stockage le plus répandu: offre au niveau performance variée. Bon rapport performance/prix au GB.! Inconvénients: Consommation électrique. Taux d erreur en écriture plus important que sur bandes. # Nécessité d avoir un système de redondance (RAID, etc ), perte de capacité brut. 16

17 Disques durs! 1965 (ex IBM: CDC 6603): Capacité < 205 MB Débit en lecture/écriture < 2 MB/s Vitesse de rotation des disques = 1200 rpm! 1987 (ex IBM: 3380):! 1997: Capacité < 1.2 GB Débit en lecture/écriture < 3 MB/s Vitesse de rotation des disques = 3600 rpm Temps de positionnement = 12 ms Capacité < 9 GB par disque Débit en lecture/écriture < 21 MB/s Vitesse de rotation des disques = rpm Temps de positionnement = 7.7 ms IBM 3380 Sources: Archives IBM, Ray Paden (IEEE MSST 2012) 17

18 Disques durs! 2012: Near line SAS: Capacité < 3000 GB Débit < 210 MB/s Vitesse de rotation des disques = 7200 rpm Temps de positionnement = 9 ms Enterprise SAS: Capacité < 300 GB Débit < 600 MB/s Vitesse de rotation des disques = rpm Temps de positionnement = 2 ms! 2018 (source: G. Grider, Exa-Scale, 07/2010, LANL): Capacité des disques = 30 TB Débit 380 MB/s Sources: Ray Paden (IEEE MSST 2012) 18

19 Disques durs # Rapport débit / capacité décroit!! 1965: 9.8 MB/s par GB! 1987: 2.5 MB/s par GB! 1997: 2.3 MB/s par GB! 2012: optimisé en capacité = MB/s par GB (3.5 x 7200 RPM NL-SAS) optimisé en performance = 2.0 MB/s par GB (2.5 x RPM SAS)! 2018: MB/s par GB (Capacity Optimized)! 2009: 1 PB (1200 x 1 TB/disk) < 10 GB/s! 2012: 1 PB (340 x 3 TB/disk) < 12 GB/s! 2018: 1 PB (34 x 30 TB/disk) < 4 GB/s # Nécessité d augmenter le nombre de disques pour éviter les chutes de performance? # Problème du temps de reconstruction des disques: En RAID-6, 23h pour des disques de 3 TB, 31h pour des disques de 4 TB. # fin du RAID? Solutions: erasure coding? 19

20 SSD! Cible: accès très performant aux données (ex: traitement transactionnel lourd).! Avantages: Performances I/O très supérieures aux disques durs. Faible consommation électrique.! Inconvénients: Cout très élevé au GB. Durabilité (argument contestable). 20

21 SSD! Performances: Temps de recherche d une adresse mémoire: ~ 0.1 ms (en écriture), ~ 0.02 ms en lecture (à comparer au temps de positionnement pour les disques durs les + performants ~ ms). En terme de IOPs (nbre d I/O par seconde): x10-15 entre le SSD le performant et le disque dur le plus performant. # Bien adapté pour des accès aléatoires. 21

22 SSD! Durabilité: Nbre limité de cycle écriture/effacement par cellule. Pour le type MLC/eMLC: ~ cycles écriture/ effacement. Pour le type SLC: ~ cycles écriture/effacement.! Temps de vie: T = Capacité de stockage X qualité du disque/débit moyen en écriture 22

23 SSD! Exemples: 1 baie avec 5 TB de SSD type SLC (débit d écriture de 1 Gbits/s): T = 5 TB X /1 Gbits/s =15.8 ans 1 baie avec 10 TB de SSD type emlc (débit d écriture de 1 Gbits/s): T = 10 TB X 30000/1 Gbits/s =9.5 ans # Durabilité pas nécessairement un problème. 23

24 Densification des médias: les bandes ne sont pas mortes! Source: R. Fontana, IBM 24

25 Mix des types de medias! Tout dépend du type d applications (serveurs de fichiers, bases de données etc ) # mix possible (placement des données suivant patron d accès).! Mix HD/SSD (ex: Tiering dynamic Hitachi) #! Mix HD/bandes (voir plus loin). 25

26 Évolution au niveau logiciel 26

27 Accès intensifs aux données non structurées! Les systèmes de fichiers distribués (ex: GPFS, Lustre etc ) très populaires: Accès concurrents par des applications. Partage simple des fichiers. Systèmes de fichiers très adaptés pour le calcul haute performance. Très bonne extensibilité (attention aux metadonnées: nœud de contention potentiel). # Certainement toujours très présent dans le futur.! Mais beaucoup de données en mode 1 écriture / beaucoup de lectures: solutions parfois surdimensionnées par rapport aux besoins.! Nécessitent pour certains une administration lourde. 27

28 Accès intensifs aux données non structurées! Serveurs de données en cluster: Utilisant du matériel «tout venant» (serveurs DAS: disques attachés directement à chacun des nœuds de stockage). Ex utilisés en physique des particules: dcache, xrootd. # stockage sur disque principal au CC-IN2P3.! Solutions très extensibles (comme xrootd).! Mais pas de vue à la mode «système de fichiers» par défaut.! Pas vraiment «universel» (très ancré à une discipline) contrairement aux systèmes de fichiers distribués (fonctionnalités de droits d accès, quota etc ). 28

29 Accès intensifs aux données non structurées (4) + (5): Staging dynamique HPSS (stockage sur bandes) (4) (5) T1.root Data server: Xrootd Data server: Xrootd n serveurs de données (6): lecture directe Client (3) (1) (2) /hpss/in2p3.fr/t1.root? (6) Redirector server: Xrootd (1) + (2): répartition de charge dynamique (etc ) 1 à n serveurs Exemple de stockage hybride avec xrootd 29

30 Accès aux données structurées! Bases de données relationnelles, orientées objet etc : Quid de l accès à de très grosses bases (ex: LSST, 15 PB à terme avec les index).! Ex: prototype qserv LSST Base de données mysql «clusterisée»: Tables éclatées sur n nœuds. Requêtes sql éclatées sur les n nœuds. Résultats des n nœuds concaténés par le serveur maître. Testé avec 310 machines au CC-IN2P3, 15 TB de données. 30

31 Accès aux données structurées Quelques résultats: - Requêtes lourdes: recherche de pairs d objets dans 100 deg2: 290 s - Requêtes du type interactif (pré-requis exécution < 10s): ok - Quelques problèmes d extensibilité à résoudre 31

32 Accès intensifs aux données! Problématique du calcul parallèle: Loi de Amdahl, facteur d accélération max f: f = T/T = 1/(1 F)+ F/n avec T: temps d execution sans parallélisation et T avec parallélisation.! Ex: application à F= 99.9% parallélisable. Avec n=1000 processeurs # f ~ 500!! Prenons en compte les I/O sur la fraction parallélisable! 32

33 Accès intensifs aux données! Pour la partie parallélisable, déséquilibre de charge potentiel aux niveaux des I/O à cause de: Répartition des données sur les serveurs (ex: points chauds). Saturation réseau, gestion du cache côté client etc! Soit T max, le temps max pour effectuer une opération d I/O ( le nœud).! Soit T moy, le temps moyen d execution d une opération d I/O ( le nœud).! Soit f le facteur d accélération: f = n/1+ Tmax Tmoy/Tmoy! Avec l ex précédent: T moy = 1 s sur 999 nœuds et T max = 1.5 s sur le dernier nœud: f =666 au lieu de 1000 escompté sur la partie //! En reprenant la loi de Amdahl, on arriive à f = 400! => Problèmes liés au parallélisme non triviaux. 33

34 Gestion et distribution des données!! Données scientifiques: Environnement distribué: sites expérimentaux, centre de traitements, collaborateurs éparpillés. 34

35 Gestion et distribution des données! Données stockées sur plusieurs sites.! Stockage hétérogène: Format de données: fichiers plats, bases de données, flux de données Media de stockage: disque, bande. Protocole d accès, système d information.! OS hétérogènes côté serveurs et clients. # Fédérer tout cela d une façon homogène # virtualisation du stockage: vue logique de l organisation des données découplés de l organisation physique. Migration des données vers nouveaux supports transparent pour applications clientes. Organisation virtuelle des utilisateurs: Id unique par utilisateur. Droits d accès, organisation par groupes, rôles. 35

36 Gestion et distribution des données! Virtualisation du stockage pas suffisant. # Virtualisation de la politique de gestion des données.! Besoin fort de définir une politique cohérente et uniforme pour la gestion des données et la gestion des ressources de stockage.! # Vital pour les projets d archivage par exemple.! Moteur de règles centralisé côté serveur (ex: politique de réplication, vérif. d intégrité, enrichissement en metadonnées, workflow plus complexes etc ).! Exemples de règles simples: Extraction automatique de metadonnées lors du dépôt des fichiers (.fits,.dicom etc ). Duplication automatique Interdiction d effacer des fichiers même par le propriétaire.! Au CC-IN2P3, utilisation de irods. 36

37 Archivage pérenne! Gestion du cycle de vie des données: Temps de rétention des données stockées? Propriété des données quand: Un utilisateur disparaît? Un groupe disparaît? Archivage pérenne: Quoi sauvegarder? (migration de media à effectuer dans le temps) Sous quel(s) format(s)? (validation, évolution dans le temps) Avec quelles informations? (métadonnées Dublin core etc : provenance, date de création, propriété intellectuelle etc.) Comment réutiliser les informations sauvegardées?! Pb commun à de nombreux projets. # Sujet primordial pour les centres de données. 37

38 Place de la grille et du cloud! «Grille», systèmes de stockage distribués: Technologies issues de EGEE/EGI/LCG: Orientation vers des organisations de type fédération: plus simple, plus robuste. Système de fichiers distribués: Beaucoup offrent la possibilité de stockage distribué sur plusieurs sites (SONAS, GPFS, Panasas ). Stockage à la mode irods. # Déjà très présent, développement encore plus important à l avenir.! Débat autour la question sur la localisation des données par rapport aux capacités de traitement. 38

39 Place de la grille et du cloud! Stockage cloud: Stockage objet: convient pour les données non structurées (ex: images) non modifiées.! Cloud commercial: Traitement des données: adapté en terme de performances (HTTP)? Archivage: coût, protection du caractère privé des données, planification du stockage à long terme (ex: cessation d activité de Nirvanix à l automne 2013).! Au CC-IN2P3: pas de plan pour fournir du stockage typé «cloud» pour l instant. 39

40 Technologies «big data»! Map-Reduce à la mode Hadoop par exemple.! Modèle souvent basé sur du matériel bon marché.! Traitement effectué au plus près des données.! Évaluations à prévoir au CC-IN2P3, mais pas de plan d investissement dans cette direction pour le moment. 40

41 Conclusion! Explosion du volume de données: L échelle du PB: courant. À la fin de la décennie, centres de calculs avec des centaines de PB commun, en route vers l Exaoctet. # Défi pour l analyse des données: des solutions mais beaucoup d inconnues.! Bandes magnétiques: toujours rôle important.! Stockage sur disques bon marché (serveurs DAS).! Défi de l archivage pérenne. 41