Le document présente les enjeux et les stratégies du pôle HPC du CNES autour du big data et du big processing, en mettant l'accent sur l'interopérabilité entre différents centres de calcul et les architectures de traitement des données. Il aborde des projets tels que Gaia et Euclid, soulignant les défis techniques et les innovations en matière de stockage et de traitement. Enfin, le document conclut sur l'importance de centrer les algorithmes au cœur des plateformes pour maximiser leur valeur ajoutée.

1. 1
From Big Data to Big Science
Pierre-Marie Brunet,
Responsable du pôle HPC, CNES DSI/DV/AR

2. 2
 Présentation du pôle HPC
 Introduction au BigProcessing
 Trois perspectives selon trois projets
 Interopérabilité entre centres de calcul

3. 3
Deux grandes classes de calcul
 Simulation numérique (HPC)
 Recherche, phase amont des projets
 Optimisation algorithmique très poussée:
“proche du matériel
 Parallélisme à grain fin
 Traitement de données (HTC)
 Phase aval, traitement des données générées
par capteurs
 Données brutes des capteurs => données
intelligibles par scientifiques
 Parallélisme gros grain
Pôle calcul intensif du CNES

4. 4
Datacenter

5. 5
Infrastructure primaire

6. 6
 Présentation du pôle HPC
 Introduction au BigProcessing
 Trois perspectives selon trois projets
 Interopérabilité entre centres de calcul

7. 7
HPC et BigData

8. 8
Présentation DCT
Contexte du Processing spatial
Le segment spatial
Le satellite
Les instruments
La plateforme / Les servitudes
Stations TM/TC Stations TMCU
Le segment sol
Segment sol de MissionSegment sol de
Commande Contrôle
Les utilisateurs
Le lanceur

9. 9
Big Processing
Au cnes
Demain
Aujourd’hui
Hier

10. BigProcessing
Big problématiques
 Déplacement des données (acquisition / diffusion)
 Accès intelligent aux données (cataloguées/classées pour être utilisées)
 Exigences de distribution des données/traitements à l’échelle ESA
 Cacher la complexité croissante des centres de mission
 Offrir des interfaces de développement simples
 Application des politiques de sécurité publique (PPST, PSSIE)

11.  Présentation du pôle HPC
 Introduction au BigProcessing
 Trois perspectives selon trois projets
 Interopérabilité entre centres de calcul

12. 12
GaiaEnjeux scientifiques
• Produire une cartographie
3D de notre proche galaxie
• Localisation de plus d’un
milliard d’objets avec une
précision inégalée
• Détermination des
paramètres
stellaires/astrophysiques
Focus sur les techniques de
développement

13. CRIP – 16/10/201313
Les chiffres:
- 10 chaines scientifiques
- 3Po de données
- 290 milliards d’entrée dans la
base de données
- Complexité des requêtes d’accès
- Plus de 1000 connexions
concurrentes à la base
Le développement:
- Language Java
- Pas de parallélisme (géré à haut niveau)
- Concept Façade
- Algorithmes scientifiques en boite noire
- Unification de l’invocation des modules
- Abstraction de l’accès aux données
L’architecture
- 6 datacenters impliqués
- Répartition statique des données
- Répartition statique des traitements

14. 14
Etude technologique (2011-2012)
 Première architecture : données centralisées
» Stockage sur une baie SAN
» Accès concurrents à la BD PostgreSQL
» Traitements sur nœuds de calcul « classiques »
Architecture logicielle
point bloquant identifié
 Benchmark nouvelles technologies
» Performance
» Scalabilité de la solution
» Fiabilité (data safety)
» Impacts sur l’existant (software et hardware)
» Coût global
» Pérennité de la solution
» Exploitation de la solution

15. 15
Hadoop & Cascading
Seconde architecture : données distribuées
 Hadoop :
 Batch execution framework : paradigme Map/Reduce (calcul parallèle gros grain)
 Système de fichier parallèle HDFS
 Avantages :
 Performance
 Scalabilité
 Ecosystème logiciel Hadoop
Calcul
Stockage
Rapprocher le calcul
des données

16. 16
Hadoop & Cascading
Map/Reduce paradigm
UC BerkeleyX courses, Spark lectures

17. 17
Cascading
 API Java pour les developpeurs au dessus de la couche Hadoop MapReduce
 Process Cascading sont traduits “à la volée” en tâches Map Reduce (5%
d’overhead constaté)
 Permet des opérations complexes (proches de SQL : join, group,…) sans
penser en MapReduce
Hadoop & Cascading

18. 18
Exemple
Requête SQL
Requête M/R (15 étapes)
Requête Cascading (7 étapes)

19. 19
1ère leçon : Ca marche ! Mais quelques pistes d’optimisation
 Hadoop v1 : problème intrinsèque de performance
» Synchronisation parallèle par… les I/O Mappers & Reducers fixes
 Passsage à Hadoop v2
» Meilleure utilisation du hardware (cœurs de calcul)
» Upgrade toujours délicat sur une plateforme de production
REX Gaia

20. 20
1ère leçon : Ca marche ! Mais quelques pistes d’optimisation
 Quantité de logs difficilement exploitable (métier, middleware, système).
Résolution d’incident complexe.
REX Gaia
R&T Fouille de données (w/ Atos)

21. 21
1ère leçon : Ca marche ! Mais quelques pistes d’optimisation
 Quantité de logs difficilement exploitable (métier, middleware, système).
Résolution d’incident complexe.
REX Gaia
R&T Fouille de données (w/ Atos)

22. 22
1ère leçon : Ca marche ! Mais quelques pistes d’optimisation
 Quantité de logs difficilement exploitable (métier, middleware, système).
Résolution d’incident complexe.
REX Gaia
R&T Fouille de données (w/ Atos)

23. 23
Si on repartait à zéro…
 Nouvelles approches BigProcessing : InMemory
REX Gaia 2015
UC BerkeleyX courses, Spark lectures UC BerkeleyX courses, Spark lectures

24. EUCLID
24
Cartographier la géométrie de l’Univers Sombre
L’expansion de l’univers accélère !
L’accélération de l’univers
est dûe à l’énergie sombre
Focus sur l’architecture
du centre de mission

25. 25
Concepts clefs d’architecture
 « cluster de clusters » : pas de centralisation de datacenter
 Distribution des données et du calcul
 Déplacer les calculs et non les données
 Les codes de calcul doivent pouvoir être exécutés sur toutes les plateformes
 Séparation des métadonnées des données (base de métadonnée centralisée)
 Deux niveaux de parallélisation
 Bas niveau : sur les tuiles (ensemble minimal de données traitable couvrant une
portion de ciel donnée) constituant des catalogues d’objets
 Haut niveau : cross matching/correlation
EUCLID

26. Mission
Operations
Centre
External
Data
Providers
Science
Operations
Centre
Public
Data
Level 1
Data Files
Metadata
(prime)
SDC-NL
Raw EXT
Data
Data
Files
Metadata
(backup)
SDC-DE
Raw EXT
Data
Data
Files
SDC-CH
Data
Files
SDC-ES
Data
Files
SDC-US
Data
Files
SDC-UK
Data
Files
SDC-FI
Data
Files
SDC-FR
Data
Files
Raw EXT
Data (TBC)
Sky allocation through Coordinator
EUCLID
Architecture

27. DB
Euclid Archive
Metadata
Storage System
Euclid Archive
Orchestration,
Monitoring &
Control
Computing
Infrastructure for
Processing Tasks
Manage Processing Tasks:
fetch/enhance/ingest data
configure/submit tasks
SDC
File
s
Euclid Archive
Data Storage
System
Infrastructure Abstraction
Layer
CODEEN
Managing and
Deploying Software
other SDCSOC
EUCLID
Architecture

28. 28
Plateforme d’Exploitation des Produits Sentinels :
• accès libre et gratuit aux données via portail web.
• capacité de traitement sur les données.
PEPS
Focus sur les technologies
de stockage

29. Eléments directeurs
 Infrastructure de stockage
hautement scalable
 Profil d’utilisation fonction de l’intérêt
(temps, localisation, etc.)
 Fort couplage avec cluster de calcul
Architecture informatique CNES

30. Besoin de technologie de stockage…
… du futur

31. 31
Disques vs bandes
Disque Bande
Bande passante 150 Mo/s 350Mo/s
Latence 6ms 60s
Capacité 8To 10To
Evolution 20To * 120 To
Durée de vie (REX) 3-5 ans 10-20 ans
Coût ($/To) 30 - 50 12 - 20
Consommation (idle) 6-8W 0W

32. 32
2 Po
6To480 x
Bases DB2
Core Server VFS Servers
2 x baies NetApp E5560
2 x baies NetApp E2724
DataMovers
Cache disque HPSS
Stockage bande
IBM TS4500
6 x Jaguar 5
14 Po
Méta données
HPSS
2 x Dell R730
vue filesystem
NFS
FTP
ou pFTP
Dell R730 Dell R730
10Gbe
10Gbe
10Gbe
SAS
SAS FC
Accès utilisateurs
10Gbe
10 Gbe
Staging
Migration

33. ForumHPC – CLS – 15/10/201533
2015

34. 34
 Présentation du pôle HPC
 Introduction au BigProcessing
 Trois perspectives selon trois projets
 Interopérabilité entre centres de calcul

35. 35
Interopérabilité
Objectifs
Exécuter un traitement sur « n’importe quel
centre de calcul » ou comment abstraire une
infrastructure de calcul parallèle…
Permettre aux développeurs de déposer des
traitements au plus proche de la donnée « sans
contrainte ».

36. 36
Concepts clefs d’une plateforme fédérée
 Cacher la complexité !
Les scientifiques/développeurs doivent se concentrer sur les algorithmes
Notion de notebook pour les maquettages rapides
 Un seul portail pour accéder/télécharger/traiter les données
 Multi paradigmes (Spark, MPI, OpenMP, etc.)
 Interfaces génériques pour :
 rechercher et décrire la donnée
 lancer un traitement
 échanger des données entre centres de calcul
 exécuter des codes de calcul

37. 37
Exploitation des Données Interopérables Multicentres
Euclid

38. 38
Euclid
Bilbio :
- Wes. Felter, Alexandre. Ferreira, Ram. Rajamony and Juan. Rubio, “An Updated Performance Comparison of Virtual
Machines and Linux Containers” IBM Research Report, vol. 28, July, 2014
- MORABITO, Roberto, KJÄLLMAN, Jimmy, et KOMU, Miika. Hypervisors vs. Lightweight Virtualization: a Performance
Comparison.
Passer des applications aux containers applicatifs

39. 39
Euclid
Performance container vs exécution native

40. 40
Prototypage R&T multicentre
15/03/201640

41. 41
results
15/03/201641

42. 42
results
15/03/201642

43. 43
results
15/03/201643

44. 44 15/03/201644
Prototypage R&T multicentre

45. 45 15/03/201645
Prototypage R&T multicentre

46. 46 15/03/201646
Prototypage R&T multicentre

47. 47 15/03/201647

48. 48 15/03/201648

49. 49 15/03/201649
Prototypage R&T multicentre

50. 50
Results
15/03/201650

51. 51
Exploitation des Données Interopérables Multicentres
Euclid
REX Prototype
 Fonctionnel mais pas industrialisable
 Les batch/schedulers HPC ont pris le train en marche
» PBSPro compatible Docker
 Proactive en tant que metascheduler

52. 52
Cas d’utilisation « cluster de clusters »
Euclid
PBSPro
v13
Hadoop
Amazon,
Openstack,
etc.
Slurm
Chronos/
Mesos
Proactive
jobs

53. 53
Conclusion
 Convergence du HPC et BigData
 Les données sont de moins en moins transportables,
besoin d’avoir des portails thématiques (visualisation,
traitement)
 Les algorithmes sont la vraie valeur ajoutée, besoin de
les mettre au centre des plateformes
 REX CNES : travailler en mémoire, distribuer
dynamiquement les calculs, considérer les stockages
hiérarchiques passé un certain seuil

54. 54
Pour aller plus loin…
Contact :
jerome.gasperi@cnes.fr
pierre-marie.brunet@cnes.fr
R&T CNES
https://rt-theses.cnes.fr

55. Présentation générale du CNES – Janvier 201555
Merci pour votre attention