Hello,
C'est difficile de répondre sans avoir toutes les contraintes en tête ou votre 
maturité technique.

Une solution simple serait un autre cluster cephfs en EC

Une nouvelle fonctionnalité a été ajouté sur le cephfs, le snapdiff comme pour 
RBD.
https://github.com/ceph/ceph/pull/53229 à voir si ça peut vous être utile.

https://docs.ceph.com/en/latest/dev/cephfs-mirroring/ 
https://docs.ceph.com/en/quincy/cephfs/cephfs-mirroring/ 
je ne sais pas si de la tape est intéressante compte tenu de la taille de votre 
infra, c'est à calculer.

--
Étienne Menguy



Jan 3, 2024, 18:55 by schar...@lasotel.fr:

> Probablement gros impact sur les process métiers en place, mais je pense que 
> "pour une fois", le stockage objet serait adéquat type S3. ;-)
>
> En plus cela reste possible sur base Ceph.
>
> Sylvain
>
>
> Le 03/01/2024 à 18:42, 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
>>
>>
>> _______________________________________________
>> Liste de diffusion du %(real_name)s
>> http://www.frsag.org/
>>
> _______________________________________________
> Liste de diffusion du %(real_name)s
> http://www.frsag.org/
>

_______________________________________________
Liste de diffusion du %(real_name)s
http://www.frsag.org/

Répondre à