Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

Concerne le projet: Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)
Ouverte par Wozzeck - 18/11/2019
Dernière modification par Thibaut Freebox - 09/03/2020

Avec l’apparition du RAID, la Freebox Delta est en mesure désormais de gérer un stockage réseau pouvant aller jusqu’à 8 TO.
De la simple fonction accessoire de partage réseau, le serveur Delta prend clairement un virage NAS.

Avant de confier tant de données précieuses (on pense notamment aux TPE, petites PME qui utilisent beaucoup la Freebox dans un cadre professionnel... même si officiellement Free ne délivre aucune prestation professionnelle... à ce jour du moins), à la Freebox se pose la question de la redondance et sauvegarde des données.

Pour couper court à certaines discussions :

- paramétrer en mirroir Raid 1... oui et non. Le Raid 0 sert à la fois à augmenter la capacité du pool mais aussi à augmenter le débit, or dans un cadre multi-utilisateurs, le débit a son importance.... sauf à investir directement dans du SSD, mais un SSD de 2 TO... ça coûte la peau des fesses.

Et puis le RAID 1 n’est pas une solution de sauvegarde, c’est une solution de redondance. Un fichier vérolé sur le disque 1 sera tout autant vérolé sur le disque 2.... si je veux retrouver un fichier sain, je dois rechercher dans des sauvegardes (abordées ci-après).
C’est une erreur commune commise par de très nombreuses personnes qui confondent RAID 1 et sauvegarde.

- Paramétrer un pool en Raid 5, ce n’est pas forcément l’idéal.
Déjà comme on n’a pas accès en ligne de commande à la Freebox (hormis les dev), personne ne sait comment se passerait effectivement la reconstruction du Raid en cas de perte d’un disque. Je dois faire des tests, mais ça me saoule car à partir de 3 disques, la création d’un pool de disque RAID buggue. Ce point a été reporté récemment, donc je n’ai pas envie de m’emmerder à faire 50 0000 manipulations pour contourner ce bug gênant. J’ai réussi avec difficulté à créer mon Raid 0 de 4 disques, je n’ai pas l’intention de le recasser pour faire des tests.... en attendant que les DEVS nous écoutent et daignent enfin admettre qu’il y a un vrai bug.

- Durant la phase de reconstruction, le pool RAID 5 est disponible mais au prix d’un très fort ralentissement, qui peut s’avérer même insupportable. Seule les énormes pool de Raid avec plusieurs disque de redondance sont capables de gérer la reconctruction de façon quasi transparente sans ralentissement notable pour l’utilisateur, et puis chez les pros il y a de toutes les façons de multiples redondances de serveurs de données.... on entre plus alors dans du Raid 6

- imaginons un pool de 8 TO, cela revient à reconstruire un disque de 2 TO et ça peut prendre.... des semaines sur du petit matériel. J’avais fais des tests sur des petits Raids Array Intel qu’on trouve dans pas mal de PC.... devant la lenteur à reconstruire les données avec à l’issue pas toujours la garantie de retrouver les données, j’ai totalement abandonné le Raid 5.... czr à un niveau domestique, ça ne marche pas, c’est merdique.
Le Raid 5, il faut du gros matos, une carte Raid professionnelle dédié du genre LSI Méga Raid ou autre... là OK

Ma stratégie consiste plus à viser la perf et la capacité en optant pour le tout Raid 0.... mais je prévois alors des solutions de sauvegarde. J’utilise Macrium sur PC....

Donc voilà pourquoi il serait opportun d’intégrer dans Freebox OS un outil de synchronisation, sauvegarde du Disque interne. Plusieurs solutions :

- une synchronisation simple de fichiers vers un emplacement réseau quelconque. Et la le port SFP+ peut avoir une grande importance s’il faut synchroniser 8 Tera octet
- synchronisation simple sur un disque connecté en USB sur la Delta qui devra donc supporter les gros disques durs de 8TO ou plus (je sais que des soucis ont été reportés sur la reconnaissance de certains disques de 3 TO ou plus)

La tâche doit être capable de tourner en tâche de fond pendant des jours, des semaines mêmes.

La synchronisation pure et simple pose souci.... pendant la synchro, si un utilisateur modifie les données ça fout le boxons et la synchro se plante, or là on parle de tâches qui peuvent durer des semaines entières.

DONC il faut passer par un système de cliché. Pour ne parler que de ce que je connais sous UFS (BSD), il y a un système de cliché qui gêle une image disque. Puis on monte cette image virtuelle qui est immuable et en on effectue la réplication, la sauvegarde réplication grâce à des outils comme DUMP,ou un outil de synchronisation de fichiers quelconque. L’image virtuelle se comporte comme n’importe quel système de fichier. L’avantage est que le disque peut continuer à être utilisé librement, mais toutes les modifs postérieures au cliché seront exclues de la sauvegarde bien entendu. Sous ZFS qui s’introduit peu à peu sous Linux, il y a aussi un système natif de cliché. Sous Windows, c’est le très célèbre système VSS qui gère cela sous NTFS

Parallèlement à la synchronisation pure et simple, il faudrait offrir un outils de sauvegarde / compression capable de gérer des sauvegardes différentielles et incrémentielles.
Pourquoi ? Parce que sauvegarder un pool de 8 TO c’est une opération très lourde qu’on ne peut envisager qu’une fois tous les ..... pour accélérer le processus on utilise la sauvegarde différentiel / Incrémentielle, cette outils ayant pour avantage de pouvoir restaurer un ficher avant certaines modifications fatidiques.

Sous BSD le célèbre “Dump” se charge de cela. On peut cumuler un tas de couche de sauvegarde incrémentiel (ou différentielle plus sûr mais plus volumineux) qui ont pour avantage de s’effectuer en quelques minutes, et on peut accéder très facilement à une ancienne version d’un fichier.

En revanche... dans toute stratégie de sauvegarde incrémentielle, il faut à un moment donné toujours penser à effectuer périodiquement des sauvegardes intégrales car lorsque dans la chaine de sauvegarde incrémentielle un bug se déclare, c’est toutes les sauvegardes suivantes qui deviennent invalides, voilà pourquoi l’implémentation d’une sauvegarde différentielle qui ne dépend que de la seule sauvegarde intégrale de départ est aussi nécessaire comme mesure intermédiaire avant de lancer LA GROSSE sauvegarde, lorsque les données ont tellement changé que la sauvegarde différentielle ne présente plus d’intérêts.

Actuellement... il n’y a aucune solution sérieuse pour sauvegarder un énorme NAS de 8 TO
Répliquer un NAS de 250 GO c’est faisable en réseau et avec un peu de patience, mais 4 ou 8 TO, là ça devient compliqué, on ne peut pas laisser un PC tourner en permanence plusieurs jours voire semaines durant, il faut trouver une solution intégrée à la Freebox.

Il s’agit d’un vrai développement qui prendra du temps. Je ne connais pas très bien EXT4, mais peut-être faudra-t-il alors implémenter un autre système de ficher comme XFS qui le cas échéant gérerait mieux le système de cliché système.... il faut que je me renseigne.

J’utilise Opensuse Tumbleweed occasionnellement, j’ai utlisé un peu Mageia.... la seule chose que j’en conclus c’est qu’il ne faut pas trop en demander à EXT4. J’ai déjà perdu des systèmes entiers avec Ext4, alors que sous UFS et NTFS, dans 98% des cas.... je parviens toujours à récupérer les données.
Donc je vais probablement tester XFS, utilisé par défaut sur Mageia qui est plus un système de fichier de grade serveur. Ext4 c’est uniquement cantonné à la station de travail, donc j’ai, quelques appréhensions à lui confier un pool de données de 8 TO

J’ai des expériences absolument excécrables sous BTFRS et ZFS.... ce sont des usines à gaz qui nécessitent des controleurs de disques modernes, une bonne config hardware et BEAUCOUP DE PARAMETRAGES pour que ça fonctionne correctement. Bref... ZFS et BTFRS c’est typiquement.... serveur big data principaleme,t, mais ça ne marche pas forcément bien qur la plupart de nos petits PC

Je pense que XFS, comme UFS, NTFS... sont plus versatiles et s’adaptent plus facilement à des usages multiples.... serveur et stations de travail avec un excellent niveau de sécurité

(Précision : UFS utilisé avec la journalisation Gjournal est diabolique de fiablité, l’UFS simple, ou la journalisation UFS par défaut, c’est de la daube)

Tout cela pour vous dire que vous devrez peut-être implémenter le XFS, “by design” plus robuste que EXT4 car conçu au départ pour la “big data”