CorbeilleNews wrote: ↑02 Oct 2019 20:22
C'est que tu as du penser presque à tout avec les bons compromis, et c'est justement ce que je recherche
tu vas pas être déçu ... mais surtout te sauver en courant les bras "au ciel"
mon projet en signature fonctionne actuellement.
j'hésitais à en parler car la conception de ZFS peut sembler souvent complexe, et mon "bazar" ... c'est pire !
C'est un projet personnel ... je partage juste mes infos.
Pourquoi et comment j'ai fais ce système ?
Et bien parce que je suis étourdi et que je fais des conneries (par exemple je tape zpool add nas1 /dev/ada5 au lieu de zpool add nas1 cache /dev/ada5, et çà, çà pardonne pas car je me retrouve alors avec mon dev de cache en entrelacement avec le pool).
L'idée première qui me venait dans ces moments là, était "Ahhh si je pouvais remettre comme c'était avant".
Donc, le but est de me protéger de moi-même en plus de tout le reste qui arrive classiquement: un disque qui claque, ...
De plus, en cas de pb de mémoire ECC ou autre, je ne veux pas d'un pool qui soit bloqué ou avoir une situation nouvelle qui ne me convienne pas.
En plus de celà:
- je veux une fiabilité à toute épreuve (je ne cherche pas la haute-dispo, mais un stockage totalement "infaillible" ... rien que çà !)
Une modularité: pouvoir utiliser les données par une machine légère (grand public) ou par un serveur pro (avec mémoire ECC)
si possible: ne pas pouvoir altérer les données par la machine légère (que l'intégrité du pool soit garantie même en cas de pb de mémoire)
- je veux que le système soit scindé (cas d'incendie)
- si possible sans sauvegarde
- optimisable en vitesse et performant
- le moins cher possible
- malléable dans le temps (pouvoir accéder "au passé" sans arrêter ou altérer le stockage existant)
- pouvoir avoir une grosse taille sans "effondrer" le système (pour ce coté là, çà me désole d'avoir un gros pool avec des données qui ne servent jamais, et qui alourdisse un scrub et la gestion du pool, pour pallier à çà il faut une grosse machine, et je veux utiliser du matos "léger".
J'ai réussis tout çà, mais en plus
il est:
- regénérable (de quelques % à 100% ou plus), c'est à dire qu'on peut reformater, remplir de zéro totalement le pool ou les disques du pool , ou mettre carrément un autre FS, partitionner différemment, et, en une seconde, l'ancien FS se remet en place ... comme avant.
- utilisable dans des temps différents (faire marcher le pool en même temps qu'une ou des versions de ce même pool à des époques différentes).
- possibilté de réduire la taille du pool (pour cela, il faut le prévoir à l'avance)
- réparable "hors conscience" du FS (le FS ou pool principal peut fonctionner sans maintenance, alors qu'un dev est en cours de maintenance)
çà fait en gros une décennie que je cherchais à faire ce genre de chose, et j'ai mis un an pour le mettre en service.
Comment çà marche ?
Si on considère ZFS comme une étoile, dans mon cas, ZFS se situera non pas au centre de tout, mais au bout de chaque branches (il existera toujours d'une manière normale au centre si on utilise ZFS, mais çà peut être un autre FS (je préfère toutefois ZFS: j'appelerai ce dernier à l'avenir "pool principal" ou pool "classique")
Toute la puissance et la sécurité de ZFS est mise à profit pour des sortes de "pseudo-device", j'appelle çà des SDA (Super-Devices-Autonomes). "Super" car ce n'est pas un device "passif" géré par un FS, mais un device "actif" car il peut reprendre des états voulus et servir plusieurs serveurs en même temps.
Mon système "laboratoire" (qui est en production désormais) est basé actuellement sur des RPI2b (15e d'occase) avec NAS4Free 10.3.
Le débit étant complètement pourri, j'ai multiplié ces derniers (le nbr de branches) pour avoir un débit acceptable.
Il y en a donc 11 et le pool qui va gérer çà est en raidz3 (donc 8 d'utilisables en capacité), pour info: un RPI2b à la base (pool classique) c'est 3,5 Mo/s en écriture et un peu plus de 10Mo/s en lecture (wow ! ... lol ... de la performance "gastéropodienne"
)
Avec mon système, en raidz3 sur un serveur normal avec mes branches constituées de rpi, j'arrive à un scrub à presque 40Mo/s et 70 à 120 Mo/s en lecture pour les données (mais ceci d'une bonne façon, c'est à dire que çà "tracte" toujours, car le pool ne gère plus les données sur des dev physiques mais des dev un peu "idéaux". Ces derniers (SDA) sont en NFS.
Au départ, je voulais utiliser l'iscsi mais c'est trop lourd à l'usage, j'ai abandonné.
Le principe est le suivant:
- Le RPI n'est pas accessible par l'admin (il est autonome et je ne me connecte pas dessus par le réseau). Pour expliquer le principe, il faut imaginer le pool principal comme une salle au centre d'une prison, et chaque SDA se trouve à l'intérieur d'une cellule fermée à double tour (c'est là, là le principe de la sécurité de ce système). Donc pour y accéder, il faut faire une intervention séparée sur chaque RPI.
- Le RPI possède un pool ou plusieurs et des datasets sont crées, un fichier (conçu par dd) est mis en place dans chaque datasets, le fichier est partagé en NFS.
- le serveur va se connecter à chaque RPI, et chaque fichier est installé dans des montages dédiés, mais, grâce à un lien symbolique, tout ce petit monde 'finit dans un répertoire unique (sur le serveur) qui contient donc des fichiers qui vont représenter chaque dev du pool (en gros c'est comme si on utilisait ZFS sous forme de fichiers, sauf que les fichiers sont en NFS)
- le pool principal va utiliser ces fichiers NFS (on peut toutefois optimiser les choses avec du cache ou du log, mais çà marche tellement bien que je laisse le pool sans rien)
- pour ma part, je triche un peu coté serveur, car je monte les SDA avec l'option "fsc" (cache en lecture) de mount ... autant en profiter !
ZFS se trouvant au niveau de chaque SDA, et, par son extraordinaire fonctionnalité de snapshot, il permet donc de retrouver une situation précise pour chaque SDA.
Pour des raisons de facilité, j'ai des scripts qui me permettent des faire certaines opérations (je veux çà pour ne pas me tromper dans mes manœuvres en tapant des commandes risquées).
Par exemple, je peux lister (zfs list), lister les snapshots des SDA, faire des snapshot des SDA, ... par l'intermédiaire de scripts.
Le principe est le suivant:
(cas d'un pool de 80Go)
- je crée un fichier de 10Go sur chaque SDA
- je crée mes partages en NFS (webgui de NAS4Free)
- je monte les 11 fichiers des SDA en NFS sur le serveur (mount -t nfs ...)
- je crée un pool principal sur mon serveur en raidz3
à ce niveau:
- je scrub et j'exporte le pool principal
- je démonte les partages NFS (script sur le serveur)
- je lance un script qui fait un snapshot sur chaque SDA (avec le même nom: en fait "@date_et_heure")
et à partir de ce moment, rien ne pourra altérer mon pool tout neuf, il est figé.
après:
- je remonte mon NFS
- j'importe mon pool (zpool import -d /repcommun monpool)
je rajoute des fichiers, et je fais vivre mon pool
ensuite, quand j'en ai envie (mais comme je suis parano: donc à chaque fois
- je scrub et j'exporte le pool
- je snapshot sur chaque SDA (par le script)
et cette fois, j'ai deux versions d'un même pool et ceci sans prendre beaucoup de place (car c'est seulement les blocs modifiés sur les SDA qui sont pris en compte).
Imaginons la chose suivante:
je me reconnecte depuis le serveur en montant mes dev en NFS
je peux formater ou effacer la totalité de mes dev par des zéros (en fait, je n'altère que le pool courant)
et bien ce formatage, ne posera en fait aucun pb !
car
- je me déconnecte
- fais un rollback sur chaque SDA
- je me reconnecte
- j'importe mon pool et je retrouve tout ce qu'il y avait avant le formatage !
Mais on peut aller plus loin !
- sur chaque SDA, je fais un clone (çà crée une copie de pool ZFS à partir d'un snapshot)
J'ai un partage NFS fantôme de disponible sur chaque SDA (sorte d’aiguillage par "lien")
- je monte les SDA en NFS
- et je peux importer le pool normal + la copie du pool cloné (et faire un rsync par exemple avec l'option backup pour générer les différences dans un répertoire)
Mais on peut faire encore mieux !
- sur chaque SDA, je fais un ZFS promote (çà crée un pool ZFS complet et totalement utilisable à partie d'un clone)
- je monte les SDA en NFS (le normal + le partage fantôme en faisant quand même un reguid du pool car on ne peut pas monter deux fois le même pool ayant le même id)
- et je peux importer le pool normal + le pool ancien (par exemple le premier que j'ai fais quand il était vide)
De cette manière, si je fais un snapshot de fichier à 10Go, et qu'ensuite je suis monté à 20 puis 30 (par des autoexpand sur le pool principal), je peux remonter la version à 10Go, faire du tri et ensuite valider ce pool "ancien remis à jour" (çà aura réduit indirectement sa taille)
Là, j'en conviens ... faut vraiment avoir toute sa tête, car c'est pas du tout évident, mais çà marche.
Pour ne pas avoir de gros pools lourds à gérer, je découpe tous en morceaux
Et je ne monte que ce que j'ai envie, du coup le scrub et rapide.
Je peux monter aussi plusieurs pools en même temps (attention toutefois à la limitation des serveurs NFS déclarés)
Je peux aussi monter un pool sur un serveur 1 et un autre pool sur un serveur 2 (sur les même SDA physiquement). Dans ce cas, les serveurs sont multiples mais le système de stockage reste unique)
un SDA peut contenir des entités qui sont en ZFS sur le serveur + BTRFS + ext4 et même du bcache en sous-FS (on peut avoir un pool principal en raidz2, un autre en raidz3 et un pool en BTRFS, les trois pouvant fonctionner en même temps)
Un SDA peut se gérer ou travailler d'une manière totalement autonome (mirroir ou autre)
On peut faire un scrub dessus pendant que le pool principal "tourne", le pool principal ne le sait pas.
Pour augmenter la taille, il suffit:
- de mettre un disque en miroir, et une fois le resilvering ok
- de spliter, puis enlever l'ancien disque
Le pool principal ne verra rien, il n'en est pas "conscient".
Le fonctionnement est très bon au niveau vélocité, et j'utilise désormais directement mes mv depuis le serveur.
Le gros avantages, c'est que je peux faire pleins de petits espaces de stockages, du coup j'en fais un pour chaque mv.
C'est extrêmement solide.
Pas besoin de sauvegarde, car on peut toujours tout retrouver (si une version du pool principal ne fonctionne pas, celle n-1 fonctionnera)
Toutefois, par principe, je fais aussi des snapshots sur le pool principal, car c'est un contexte de données "unique", alors que pour les SDA, il y a 11 parties totalement différentes (c'est là que les choses peuvent sembler "complexes" sur ce système, car une perte totale d'un SDA engage la perte des snapshots attenant aux SDA, en gros, le pool principal pourra reconstruire le pool courant (donc le pool courant du SDA) mais pas les snapshots du SDA, car ces dernièrs n'ont aucun rapport avec le pool principal. Ceci étant, si il existe des snapshots du pool principal, il sera alors possible de reconstruire autant de versions sur le SDA que de snapshots du pool principal; c'est pour cela que je fais systématiquement un snapshot sur chaque SDA et un sur le pool principal, car de cette façon, toutes versions du SDA est potentiellement reconstructibles)
Coté taille, avec mes RPI2b, je peux monter 4 disques de 2 To, soit 8 To et çà donne 64 To max (8 x 8To + 3 disques perdu par le raidz3)
En utilisant des petites cartes mères avec des ports usb on monter très très haut en taille.
Pour moi, c'est un peu le Graal.
Ce n'est pas toujours facile à appréhender, mais je sais que mes données sont là et seront toujours accessible.
Dans quelques temps, je vais mettre en place un concept encore plus poussé ... les SDA deviendront des HDA, c'est à dire qu'un HDA sera un SDA + copie d'un autre SDA.
Si on coupe les disques en deux groupes, le HDA 1 (Hyper-Device-Autonome) contiendra l'équivalent du SDA 1 (grp1) + une copie du SDA 6 (grp2)
Le but est que ce système soit délocalisé en deux endroits différents, et qu'une partie puisse fonctionner totalement sans l'autre (HS/volée/carbonisée) tout en bénéficiant toujours des fonctionnalités "raidz".
Une autre possibilité (la moins cher et ne bouffe pas de ports usb sur les SDA, c'est de faire une sauvegarde "verticale" (c'est à dire un serveur qui contient une copie de tous les SDA (une seule machine avec du volume, le but étant de compenser rapidement un SDA HS).
On peut aussi basculer ce système de "réseau" en "local", sur mon bi-xéon qui me sert de serveur (pool principal), j'ai 11 disques SAS de 300Go disponible et je peux basculer un pool de mon système sur le serveur local, pour celà, il faut faire des zpool replace.
Et on peut aussi basculer un pool "local" en "réseau".
L'avantage du NFS, c'est qu'on peut "jouer avec" ... sans rien décâbler.
Pour avoir de la vitesse:
- le SDA peut être Zcaché (j'ai des rpi de modèles différents (v1.1 ou 1.2)et des disques différents, et donc des vélocités non-identiques entre chaques SDA, je compense donc les plus faibles)
- le pool principal peut avoir un très gros Zcache, soit en SAS (secondarycache=all) ou en SSD (secondarycache=metadata pour éviter l'usure de ce dernier)
Je testerai un mode 'turbo" (vitesse de lecture égale au performance "SSD" sur une partie ou la totalité du pool, sans utiliser de Zcache), mais c’est à tester complètement, je n'ai pas encore d'expérience sur ce type de montage.
Voilà en gros.
Ce n'est pas du tout évident comme "structure", car il faut bien connaître son FS (ZFS ou non), et, l'imbriquer dans une "sous-couche ZFS" au sein de chaque device et ceci au travers de NFS.
Mais, pour ma part, je ne pourrais plus m'en passer.
Les SDA peuvent être "mixtes" (du DD pour un type de données, et du SSD pour un autre type), ils peuvent être maintenus et modifier sans que le pool principal le sache.
(mes 11 rpi consomme 11 watts pour le tout, et les disques peuvent s'arrêter totalement), c'est accessible 24h/24h)
Si besoin, je peux faire des schémas de tout ceci ... car je reconnais que ce n'est pas évident.
