Oui, nous avons les même besoins et on se pose aussi les mêmes questions.
Attention, ce qui suit n'est pas une méthode pour tout le monde (on dépasse largement les limites d'une utilisation "normale" ou "classique"), c'est écrit juste à titre indicatif pour partager un retour d'expérience avec des personnes du forum de manière publique.
J'ai mis au point mon système à la suite du problème suivant:
Je voulais utiliser un Zcache, et, pour le faire, il faut rentrer la commande suivante:
zpool add monpool cache /dev/truc
... mais comme je suis du genre étourdi, je tapais (un peu vite):
zpool add monpool /dev/truc
... et je me suis retrouvé avec un dev entrelacé à mon pool de plusieurs To, c'est pas top du tout !
Même en essayant de faire attention, cela m'est arrivé plusieurs fois !
Je me suis souvent dis "si seulement je pouvais revenir en arrière".
J'ai donc réfléchis à pouvoir le faire, retrouver une configuration précise, idéale et connue.
Mais j'ai chargé un peu "la mûle", je voulais que le serveur soit interchangeable, c'est à dire que je puisse utiliser une machine légère ou de temps en temps mon bi-xéon (plus gourmand). Je veux surtout que les fichiers soit accessible 24/24h.
avec:
- le moins de consommation
- pouvoir utiliser une ou deux MV directement.
- une sécurité sur les données absolues (par exemple, faire en sorte qu'un pb de pool qui ne peut plus s'importer ne bloque pas la situation, avoir des To de données sous la main et ne pas y avoir accès ... çà me frustre "un peu")
pas facile de lier tout çà !
En gros dans une utilisation normale à 4 disque en raidz1, on a des dev qui sont directement raccordés à un pool.
soit:
dev1 -> sata -> monpool
dev2 -> sata -> monpool
dev3 -> sata -> monpool
dev4 -> sata -> monpool
dans mon système, on a:
un dev = un pool (géré par (micro-)serveur SAN), et, dans ce pool on a un fichier qui constitue un "dev virtuel", pour éviter la confusion avec les dev virtuels de ZFS, je l'appellerai dev-virtuel-iscsi (pourquoi virtuel? car ce qui est accessible en iscsi n'est pas le dev physique mais un simple fichier).
on a deux parties disctinctes:
(1) dev -> SAN (NAS utilisé en SAN) -> (2) NAS
la partie (1) c'est les données physique propre à ZFS (les branches du pool principal)
la partie (2) c'est les données utilisables, c'est à dire le "pool principal" (ce pool peut être importé par d'autres machines; les données sont locales (fixes) et le pool principal est interchangeable/transportable).
çà donne ceci
(la structure est coupée en deux):
(1) et (2) seront ré-utilisés dans le texte ci-dessous.
coté dev-virtuel-iscsi (1):
dev1 -> sata -> pool1 (pool secondaire 1) -> dev-iscsi-disk1
dev2 -> sata -> pool2 (pool secondaire 2) -> dev-iscsi-disk2
dev3 -> sata -> pool3 (pool secondaire 3) -> dev-iscsi-disk3
dev4 -> sata -> pool4 (pool secondaire 4) -> dev-iscsi-disk4
coté NAS (2):
dev-iscsi-disk1-> monpool (pool principal)
dev-iscsi-disk2-> monpool (pool principal)
dev-iscsi-disk3-> monpool (pool principal)
dev-iscsi-disk4-> monpool (pool principal)
Le principe, c'est que chaque dev soit autonome (et que la puissance nécessaire à la gestion de ce dernier n'impacte pas la gestion du pool principal): par exemple, un pool secondaire peut être en miroir ou avoir un disque en cours de remplacement, alors que coté dev-virtuel-iscsi on ne percevera rien, en gros les "affaires" propres au SAN ne sont pas connues du NAS.
On peut mettre un gros Zcache sur le NAS pour compenser les pertes dues aux imbrications.
On peut mettre un Zlog mais çà ne sert pas bien à grand chose dans mon cas (je ne fais que du stockage principalement).
L'avantage et le principe, c'est que pool1 est snapshotable, donc on peut remettre le dev physique dans une configuration antérieure (donc du coup, le dev-virtuel-iscsi).
Pour être correct, tous les pools secondaires doivent être câlé sur une même version de snapshot.
Par rapport à un montage "normal", le pool principal n'aura pas "la main", il est totalement tributaire des pools secondaires (qui reçoivent pourtant bien les données du pool principal)
En fait, le pool principal est "l'état direct des pools secondaires" (c'est pour çà qu'en modifiant l'état des pools secondaires par l'intermédiaires des snapshots, on modifie l'état du pool principal).
Ce montage n'est pas facile a appréhender, j'en conviens, car il s'agit d'une imbrication ZFS dans ZFS oû la possibilité des snapshots a lieu en dehors du pool principal (sachant que le pool principal peut aussi avoir ses propres snapshots), et comme ZFS offre certaines possibilités, cette imbrication donnera aussi de nouvelles possibilités inconcevables sur un "montage direct" (dev-pool)
En fait, mon système fait une sorte de gros COW (Copy-On-Write) au sein de chaque dev réel(physique), et si les pools secondaires sont délocalisés, et, ne sont pas accessibles facilement, il deviendra alors très dur d'altérer le pool principal de manière volontaire.
Mon objectif était justement çà: "ne pas pouvoir altérer le pool facilement", mais seulement, au prix d'une suite d'opérations bien particulières)
En faisant, par exemple un dev-virtuel-iscsi de 1To sur un disque de 2To, on peut se permettre de modifier à 100% tous les dev du pool principal, on peut remplir intégralement avec des zéros tous les dev sans exceptions, formater et remplir ensuite totalement les disques avec un autre FS, et, en quelques secondes, tout peut revenir comme avant (en faisant un simple rollback sur chaque pools secondaires).
Alors je vois venir les questions suivantes:
a) qu'en est-il du matos à mettre en oeuvre ?
b) à quelle vitesse çà marche ? (une imbrication de ce genre est forcément néfaste)
En fait çà dépend de ce que l'on veut:
- plus on veut du débit, plus il faudra du matos cher et rapide
- pour la vitesse, le débit chez moi semble en gros divisé par 4 par rapport à du "direct" (avec un Zcache en SSD sur le pool principal, la lecture sera ultra-rapide, presque comme en direct, c'est l'écriture qui sera le point le plus lent).
Mon premier système a été un serveur composé de 4 disques (donc 4 pools secondaires) sur une carte mère dual/core avec N4F/clef USB, un ou des serveurs distants peuvent se connecter dessus (par l'iscsi), j'avais ~70Mo/s en écriture.
A noter, le serveur qui contient le pool principal est en Linux/UbuntuServer 16.04, car la gestion de l'iscsi est beaucoup plus aisée, et je peux utiliser VirtualBox avec les additions invités (qui n'existe pas sous Xig), celà me permet d'utiliser le RDP et l'USB.
Actuellement, je suis passé à 11 "micro-serveurs SAN" ... des Raspberry PI-2B ! (on pourrait imaginer que çà "rame à mort !", mais non, car chaque RPI est totalement autonome et les flux sont divisés par 8)
Le pool principal est en raidz3.
En plus d'une ou des machine(s) de secours (SAN), je peux mettre des dev de remplacement locaux au cas oû (c'est à dire sur la machine oû se trouve le pool principal), ce qui laisse du temps pour réparer une machine SAN secondaire.
La vitesse d'écriture est seulement de 33Mo/s, mais c'est un débit très constant et très solide. Avec un Zcache, j'obtient 235Mo/s en lecture (attention, il ne faut pas croire que le Zcache fait tout, ce dernier n'est pas un périphérique "fiable", donc ZFS fait toujours des contrôles de parité avec la source réelle des données, et ainsi, doit donc toujours utiliser un tout petit peu les dev réels)
Il est vrai que coté vitesse, c'est un peu ridicule, mais pour moi çà marche bien, et, la structure est vraiment "costaud".
Bon, je n'ai pas optimisé non plus mon installation (tout est sur le même réseau, c'est fait un peu exprès).
Je n'ai jamais pu utiliser un orangePI avec l'iscsi, mais cela serait mieux car le port rj45 serait 10 fois plus rapide, et avec un bananaPI, j'aurais un port sata direct en plus.
Avec mon système, je peux lancer une MV directement !, çà marche très bien (il vaut mieux du Zcache, mais je l'utilise sans), car même si c'est un débit faible, c'est un "vrai" débit, il ne s'écroule pas.
Le gros avantage de ce type de montage, c'est qu'on peut utiliser du matos ultra-pourris pour les dev secondaires, et en gros n'importe quoi (un disque de 2 To ou 2 disques de 1To ou 4 disques de 500Go entrelacés), le raidz3 ne bronche pas (toutefois, le pool secondaire le plus faible ralentira tout le reste ... la réalité est toujours là !).
Pour ma part, je fais obligatoirement mes scrubs et mes travaux avec mon bi-xéon en ECC, et, pour certaines autres fois j'utilise un PC normal en FANLESS qui n'est pas ECC (il m'est déjà arrivé d'utiliser le pool avec le bi-xéon et un clone de ce même pool avec l'autre PC).
Si j'ai un problème sur le pool courant (principal), je peux transformer les anciens snapshots secondaire en pool (clonage) et obtenir un deuxième pool principal et récupérer sur ce dernier ce que je pourrai récupérer.
En gros, on peut (ré-)activer la version d'un pool que l'on veut, c'est comme si on dupliquait les choses), dans le cas d'un montage classique (normal dev-pool) un rollback détruit les versions suivantes, c'est à dire que çà ne marche que dans un sens.
Dans tous les cas, si çà marche avec des pauvres RPI, çà marche forcément avec du matériel plus performant.
Pour ma part un pool secondaire, c'est en gros:
10 à 30 euros pour le RPI pi2B
25 à 50e pour un disque de 2To
11e pour l'adaptateur USB-sata avec alim 220v
donc 60/90e maxi pour un dev-virtuel-iscsi X 11 = 700/1000 euros tout de même (en vrai ~ 500e en flairant bien).
J'avais pensé à trouvé un lot de petits serveurs anciens, mais la consommation est beaucoup trop élevé pour le tout au repos.
Je me suis orienté sur le RPI (là pas de choix, c'est N4F/2258), au départ j'en ai utilisé 4 (raidz1) et j'ai été surpris de pouvoir faire fonctionner une MV (avec un SSD en Zcache), donc pour avoir quelque chose qui me convienne bien (écriture correcte de MV), je suis passé à 11 SAN pour avoir un débit plus important.
La capacité est de 8 disques de 2To, soit 8To pour une régénération possible à 100%: c'est à dire qu'il est possible de tout détruire (depuis 1) et de tout reconstruire (depuis 2).
On peut faire des dev-iscsi de 1,8To pour un disque de 2To, mais dans ce cas, la régénération sera "partielle/limitée" et la taille des snapshots ne devra pas être supérieur à 200Go sur le pool secondaire.
Le Raspberry est idéal pour moi, avoir 11 disques "froid" me convient très bien, surtout en été.
Je pense qu'un miroir de 3 disques (2 cartes fanless + un PC normal: 2 en service et un pour le remplacement) pourrait être une solution, mais moins il y a de dev-virtuel-iscsi, plus le risque est élevé (on peut toutefois mettre les dev secondaire en miroir ou avoir une sauvegarde de ces dev-virtuel-iscsi sur la machine hébergeant le pool principal.
Une chose qui est bien, c'est qu'un pool secondaire n'impacte pas le travail du pool principal (par exemple le pool principal n'est pas du tout "conscient" du resilvering d'un dev physique sur un des pools secondaires), donc en gros, on peut faire des opérations de réparation ou maintenance qui laissent un pool "propre".
C'est pas évident tout çà, mais c'est tellement solide qu'il n'y pas de sauvegarde, car en fait chaque dev physique est potentiellement une partie de la sauvegarde.
Il faut toutefois une sauvegarde en cas de feu ou vol, mais seulement si les dev (pools) secondaires se trouvent dans le même bâtiment).
A grande échelle, avec du gros matos dans des lieux différents, et avec un pool principal sous proxmox, cela ferait une haute disponibilité à la fois en virtualisation et en stockage.
On peut imaginer une salle informatique ou le serveur principal (2) est utilisé par un ou des admins (là oû se trouve l'OS et le FS), et une ou des salles sécurisées et séparées oû se trouvent les dev/pools secondaires (1) avec des machines uniquement accessibles en "mode console", il faudrait alors (pour altérer le pool principal) pouvoir pénétrer dans chaque salles et éffectuer les bonnes modifications nécessaires pour chaque pool).
Dans mon cas, j'ai des petits scripts qui supervise mes pools secondaires:
- j'exporte mon pool
- je me délogue des dev-virtuel-iscsi (en fait pas obligatoire)
- je lance mon script (un snapshot est crée sur chaque pools secondaires)
et quelques secondes après tout est figé !
- je me relogue
- j'importe et c'est repartis "comme en 40".
quelques secondes seulement pour 1 ou des centaines de To.
A terme, toutes les opérations se feront par un menu whiptail ou dialog ... et pourquoi pas un bouton poussoir par le gpio.
J'ai des scripts qui m'affichent l'état des pools, les tailles libres et les snaphots (1).
Le seul défaut avec le RPI est la vitesse du scrub sur le pool principal, donc, il ne faut pas faire un gros pool énorme (car ce dernier mettra plusieurs jours pour se réaliser), surtout qu'on peut mettre 4 disques de 2To (x 11), soit une capacité de 32To régénérable à 100%, là c'est plus d'une semaine de scrub qu'il faut !
Dans mon cas, j'ai trouvé une solution: faire des "liens durs" au sein de la cible iscsi (aiguillage).
J'ai 2 ou 3 cibles qui peuvent se "lier" avec des dizaines de pools. et là un scrub se fait en moins d'une nuit.
La seule contrepartie est donc de faire manuellement les aiguillages sur tous les pools secondaires concernées (faisable par un script).
En gros, sur mon système, on ne peut pas accéder à tout le stockage en une seule fois, mais juste à des "tranches" (des pools secondaires relatifs en somme), ces "tranches" peuvent être agrandies par auto-expand de ZFS (2).
Cela peut constituer toutefois un gros avantage: quand les tranches sont dé-liées, elles sont "figées", un défaut sur le pool en cours n'affecte pas les autres tranches.
Pour ma part, 2 ou 3 aiguillages me suffisent (1 accès régulier + 2 ou 3 pour des autres opérations: recherche de fichiers, ...)
Ce n'est pas du tout évident à conceptualiser, et à utiliser au quotidien, mais c'est très solide (grace à l'accumulation des propriétés de ZFS), les tailles mises en oeuvre peuvent être démentielles malgré un hardware de base "taillé très petit".
Avec ce système, je peux stocker pleins de VM (en utilisant des tranches, celles-ci n'impactent pas la gestion du pool principal (elles sont présentes potentiellement (1) mais absentes du pool (2).
Dans ton cas, je ne pense pas que mon système soit intéressant (trop de serveurs SAN sans doute)
Peut-être en prendre des idées.
Sinon, tu pourrais essayer la chose suivante:
- mettre 9 disques ou plutôt 11 en raidz3
- les monter sur une carte fanless
- loguer toutes les unités iscsi sur un serveur afin de faire un pool principal accessible par tout le monde
mais rien ne t'empêche d'avoir 2 PC connectés sur les pools secondaires (2 pools principaux)
pour la suite, tu peux rajouter un miroir ou une autre carte fanless de x disques, il est même possible de mettre 3 disques, puis de passer à un pool à 6 disques et augmenter, cela peux se faire tranquillement en fonctionnement: tu crées un nouveau pool et une fois fait, tu supprimes l'ancien sans risque (2) ! ... puisqu'il sera toujours là (1)
Les manipulations sur une structure imbriquée sont longues et demande de la rigueur, mais tant qu'on ne modifie pas les pools secondaires (1), rien ne se perd.
Voilà, je ferai sans doute des dessins pour mettre tout çà en visuel.
En tout cas, pour ma part, je resterai sur cette méthode, car une fois qu'on a intégré ce genre de structure, quelle sérénité !
(ce n'est pas toujours facile à intégrer, déja que ZFS c'est tout un poème, mais là les choses sont encore plus complexes).
Je ne dis aucunement que l'on doit faire "comme çà", c'est "ma" méthode adapté à moi, qui "me permet de", on a tous des besoins différents et chacun doit penser à "ses" besoins et adapter les choses pour "son" utilisation.
Je ne sais pas si c'est la meilleur solution pour moi, mais c'est en tout cas la première fois que je suis vraiment zen avec mes données.
Cela fait un an que je monte mon install, j'ai eu 7 disques durs HS lors de la mise en service, je me suis bien fait la main dessus.
Voilà tu sais tout !
... et pas à jour en plus 
(çà craint)
de "super-devices-autonomes" en NFS gérés par des micro-serveurs SAN(+nas) sous N4F (11 super-devs en raidz3) taille actuelle: 16To / prévue: 64To / théorique: 320To (consommation < 15W en veille - 24/24h) en service depuis 2 ans.