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 (sirj...@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/
