Bonjour Fabien, la liste,
Petit retour d'expérience d'un labo de recherche sur EOS que Gilles a mentionné.
je gère 2 instances EOS dans 2 contextes d'utilisation différents :
* Stockage de données scientifique d'un laboratoire de recherche : Stockage de datasets de données de CMS (https://cms.cern) et de nos autres expériences internes, supportant à la fois les protocoles de transfert de données (XRootD and HTTPS) entre datacenters de la grille WLCG (https://wlcg.web.cern.ch/) et EGI (https://www.egi.eu/) et à la fois des accès locaux (type POSIX via FuseX)
* Stockage Online des données qui sortent d'une expérience, sorte de buffer proche du détecteur, pour que les données soient calibrées / traitées / filtrées / nettoyées sur place avant d'être exportées vers les centres de calcul CERN/IN2P3/FNAL...
Authentification supportée : kerberos et certificats x509 depuis longtemps, OIDC plus récemment
Au niveau du stockage, c'est très versatile : sur du RAID matériel ou logiciel (pas conseillé), sur du JBOD. Tu peux aussi assurer de la redondance via des réplicas ou alors de l'erasure coding, par répertoire. par exemple /eos/stockage/cycle1/exp1/processed en réplica 2 et /eos/stockage/cycle1/exp1/raw en erasure coding. L'erasure coding prends tout son sens sur du JBOD puisque tu assures la redondance des données sur des disques différents et sur des serveurs de stockage différents avec un overhead faible.
Quotas par utilisateur, par groupe, par projet (arborescence)
Comme stockage distribué c'est bien pensé puisque les meta-données sont distribuées dans QuarkDB (KV store backend en haute dispo) et si tu utilises l'erasure coding avec un nb de FST (serveurs de stockage) > N+P, alors tu continues à avoir accès à tes données même si tu perds un FST.
Au niveau de tes critères :
* open source
* scalable natif. + il y a de serveurs de stockage, mieux c'est. Au niveau du roulement des serveurs : drain du serveur à remplacer (1 commande à taper), on revient + tard quand il a fini de déplacer les n TB vers les autres serveurs de stockage, on traite les cas particuliers, on le sort de prod, on le remplace et le nouveau serveur entré en prod récupère sa part comme avec CEPH.
* interfacé avec les bandes via un autre de leurs soft CTA (https://cta.web.cern.ch/cta)
* Pas trop complexe / usine à gaz : un peu complexe quand même quand on veut utiliser les fonctionnalités ou modifier le comportement des sous composants, mais une fois qu'on a compris les briques de bases (Namespace MGM + persistance des meta-données dans QuarkDB + stockage des données dans les FST), le reste est de la routine de services de stockage.
Au niveau des performances, aucun problème pour saturer des liens a n*10Gb/s, même pour des petits fichiers.
Petit retour d'expérience d'un labo de recherche sur EOS que Gilles a mentionné.
je gère 2 instances EOS dans 2 contextes d'utilisation différents :
* Stockage de données scientifique d'un laboratoire de recherche : Stockage de datasets de données de CMS (https://cms.cern) et de nos autres expériences internes, supportant à la fois les protocoles de transfert de données (XRootD and HTTPS) entre datacenters de la grille WLCG (https://wlcg.web.cern.ch/) et EGI (https://www.egi.eu/) et à la fois des accès locaux (type POSIX via FuseX)
* Stockage Online des données qui sortent d'une expérience, sorte de buffer proche du détecteur, pour que les données soient calibrées / traitées / filtrées / nettoyées sur place avant d'être exportées vers les centres de calcul CERN/IN2P3/FNAL...
Authentification supportée : kerberos et certificats x509 depuis longtemps, OIDC plus récemment
Au niveau du stockage, c'est très versatile : sur du RAID matériel ou logiciel (pas conseillé), sur du JBOD. Tu peux aussi assurer de la redondance via des réplicas ou alors de l'erasure coding, par répertoire. par exemple /eos/stockage/cycle1/exp1/processed en réplica 2 et /eos/stockage/cycle1/exp1/raw en erasure coding. L'erasure coding prends tout son sens sur du JBOD puisque tu assures la redondance des données sur des disques différents et sur des serveurs de stockage différents avec un overhead faible.
Quotas par utilisateur, par groupe, par projet (arborescence)
Comme stockage distribué c'est bien pensé puisque les meta-données sont distribuées dans QuarkDB (KV store backend en haute dispo) et si tu utilises l'erasure coding avec un nb de FST (serveurs de stockage) > N+P, alors tu continues à avoir accès à tes données même si tu perds un FST.
Au niveau de tes critères :
* open source
* scalable natif. + il y a de serveurs de stockage, mieux c'est. Au niveau du roulement des serveurs : drain du serveur à remplacer (1 commande à taper), on revient + tard quand il a fini de déplacer les n TB vers les autres serveurs de stockage, on traite les cas particuliers, on le sort de prod, on le remplace et le nouveau serveur entré en prod récupère sa part comme avec CEPH.
* interfacé avec les bandes via un autre de leurs soft CTA (https://cta.web.cern.ch/cta)
* Pas trop complexe / usine à gaz : un peu complexe quand même quand on veut utiliser les fonctionnalités ou modifier le comportement des sous composants, mais une fois qu'on a compris les briques de bases (Namespace MGM + persistance des meta-données dans QuarkDB + stockage des données dans les FST), le reste est de la routine de services de stockage.
Au niveau des performances, aucun problème pour saturer des liens a n*10Gb/s, même pour des petits fichiers.
NB : Prochain workshop EOS en mars 2024 https://indico.cern.ch/event/1353101/
Cordialement
Denis
----- Le 3 Jan 24, à 20:43, Gilles Mocellin <gilles.mocellin@nuagelibre.org> a écrit :
Le mercredi 3 janvier 2024, 18:42:10 CET Fabien Sirjean a écrit :Bonsoir la liste,
En ce début d'année, je me creuse la cervelle autour des sauvegardes,
alors je vous partage mes questionnements :)
Petit topo du contexte : je bosse dans un centre de recherche
scientifique, dont les instruments produisent pas mal de données.
Ces données sorties des instruments "raw" sont ensuite traitées et
transformées pour analyse (données "processed"), en vue de publier des
papiers de recherche.
Les données raw sont produites pendant des "cycles" de fonctionnement (3
à 4 cycles par an) et l'approche est WORM (c'est la valeur produite par
l'institut, les données raw sont impossibles à reproduire).
Les données processed sont produites en continu selon l'activité des
scientifiques, parfois plusieurs années après la production des données
raw associées. Les données processed sont recalculables à partir des
données raw, mais ça peut être coûteux (temps et puissance de calcul).
On a actuellement 1.3 PiB de data (raw+processed) sur notre stockage
primaire. Ça tourne sur une infra Ceph en triple réplication,
grosso-merdo ça fait 600 disques mécaniques de 20TB.
Évidemment on est sur un scénario loin d'être idéal pour le stockage :
on a principalement de très nombreux petits fichiers (<128 KB). Mais on
a aussi des fichiers >1TB, sinon c'est pas drôle...
Si vous voulez une idée de la tête de l'arborescence, ça ressemble à ça
: https://pastebin.com/vVF31cv4
On aimerait changer de solution de backup pour ces données, au profit
d'un truc qui coche au moins plusieurs de ces critères (tous, je sens
que ça va être compliqué) :
* Open Source
* Pas trop complexe / usine à gaz
* Scalable (marre de changer tout le matos tous les 4-5 ans parce que
y'a plus de place...)
* Qui permette de gérer indépendamment le backup des données "raw" (ça
bouge pas mais on veut vraiment pas les perdre) des données
"processed" (ça bouge, on peut se permettre de les perdre, on peut
réduire la rétention pour les vieux cycles)
* Qui fasse pas nécessairement tourner des tas de disques en
permanence (les données raw pourraient très bien être sur de la
bande magnétique, vu qu'elles ne bougent plus du tout une fois le
cycle terminé)
* Qui coûte un prix raisonnable
Jusqu'ici on fait du bacula et du rsync sur ZFS (un serveur avec plein
de baies JBOD en SCSI). Mais c'est plein, et il faut donc faire évoluer
tout ça.
Le plus simple pour nous serait probablement de continuer avec la même
solution sur le plan logiciel, en passant sur un stockage distribué
comme Ceph pour avoir la scalabilité souhaitée.
Mais ça fait la même techno pour le stockage primaire et le backup (pas
top), et Ceph n'est pas très efficient (même si on peut faire des choses
en Erasure Coding). De plus, ça ne permet pas d'intégrer des bandes
magnétiques dans l'équation.
Voilà, n'hésitez pas à partager vos avis et expériences. Notamment je
n'ai jamais bossé avec de la bande magnétique, je me questionne pas mal
sur la pertinence et la facilité de gestion.
Si des commerciaux passent par là : vous pouvez me contacter sur mon
mail pro (sirjean@ill.fr) mais je suis plutôt dans une phase
exploratoire (il y aura de toutes façon un appel d'offres).
Merci pour vos retours, et à bientôt :)
Fabien
Bonjour,
En restant dans le domaine de la recherche, on a évidemment le CERN qui peut
être pris comme référence / inspiration.
https://home.cern/science/computing/storage
Ils ont du Ceph, mais à priori, pas pour les données des expériences, surement
pour leur Cloud OpenStack.
Leur stockage est fait maison (EOS https://eos-web.web.cern.ch/eos-web/)
Et le stockage long terme, archivage est sur bande.
PS:
Tien, je vois que EOS a plusieurs backends de stockage à proprement dit, et
qu'on y retrouve Ceph aussi, en mode RADOS direct ou CephFS...
_______________________________________________
Liste de diffusion du %(real_name)s
http://www.frsag.org/
--
 | Denis PUGNÈRE Institut de Physique des 2 Infinis de Lyon |
Campus LyonTech la Doua, bâtiment Dirac 4 rue Enrico Fermi, 69622 Villeurbanne | |
  https://www.ip2i.in2p3.fr |
