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.

NB : Prochain workshop EOS en mars 2024 [ https://indico.cern.ch/event/1353101/ | 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 :

BQ_BEGIN 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/

BQ_END