Comme on a eu une longue discussion il y a peu sur ZFS, je me suis dit que ça serait utile d’écrire un article à son sujet pour faire découvrir ce système de stockage très complet…
https://www.computel.fr/2019/10/26/zfs-vous-connaissez-vous-devriez/
super cool , je vais m’y plonger rapidement !
Merci cquest.
édit : je ne comprends toujours pas quant tu fais une sauvegardes des données (et avec quoi 
), zfs a l’air ultra puissant en snapshot, clonage d’un snapshot etc … mais pour sauvegarder avec une rétention sur x jours, y semaine, z années :tu fais comment ?
Ce n’est pas du système de fichier distribué mais bien monté et surtout bien ajusté dans une infra. : c’est en effet redoutable … (mais cela mange de la RAM, attention : avec 8 disques = 10 Go )
je confirme pour un cluster deux nœuds proxmox , les répliques et migration à chaud , cela marche fort.
J’ai pour ma part dédié un lien de migration et des répliques de CM/CT à 2GB (ce n’est pas du Ceph ou on perds à peine un ping , mais on là avec zfs on tourne entre 2 à 13s … donc à voir avec des grosse datas).
Merci cquest ! (je viens de faire une affaire…enfin je pense … 32 x 8Go ddr3 ecc low voltage … 140€)
Les soucis arrivent, heureusement pas en prod.
- remplacer un disque , c’est assez complexe, (j’ai du basculer mes VM de tests sur un autre neouds du clutser, et … zpool destroy … pour en refaire une)
- ajouter un disque dans une zpool : apparemment assez complexe … je cherche.
Ca commence assez mal …
No. ZFS does not work that way. Disks go into VDEVS and VDEVS go into POOLS. You cannot extend a VDEV currently (unless you want to replace each disk with a larger one, one at a time, and let it resilver), but you can extend a POOL. Your redundancy lives at the VDEV level. A VDEV consists of one or more DISKS. So you can grow your 5 disk POOL by adding another VDEV. Preferably another VDEV that matches exactly what the first one is, but you can use different raidz levels within a POOL. The problem with this is that the weakest link is the least redundant VDEV. If that VDEV goes bad, your entire POOL is lost. If you add a single disk to a POOL, that already has a redundant VDEV in it, and that single disk dies, you have lost the entire POOL.
(sinon les replications de VM : ca trace , et sans optimisation !!!)
Il ressemble à quoi ton « zpool status » ?
Remplacer un disque c’est plutôt facile, il ne faut pas modifier le pool mais indiquer que le disque HS est remplacé par un autre et zfs va refaire la redondance (resilver).
1 « J'aime »
Salut christian,
oups, je l’ai déja détruis et refait : oui un bourrin 
mais si tu as le mode opératoir exact, je suis intéressé.
- style je veux changer un disque par un plus gros (est-cela solution pour agrandir l’espace d’un zpool ?)
- style j’ai un disque qui pète , je dois le remplacer (ce fut mon cas).
Note : quand j’ai eu un disque à changer (car offline), j’ai fait n’importe quoi en mélegant les vdev , disque réel etc … (je suis en test de ma nouvelle infra. CHATONS)
Mon souci étant de pouvoir agrandir une zpool , et la visiblement c’est pas possible ?
Je ne sais pas comment ton pool est organisé, donc difficile de répondre.
Un pool contient des vdev, qui peuvent être des disques seuls ou regroupés en grappe (mirroir, raidz, etc).
C’est le vdev complet qui change de taille, sur un disque seul en le replaçant pas un disque plus gros, sur une grappe, en remplaçant tous les disques de la grappe par la taille au dessus.
Si un seul disque d’une grappe change de taille, on ne peut pas utiliser l’espace en plus (sauf en le partitionnant, mais c’est bricoler).
C’est pas 100% souple, donc il faut anticiper un peu en constituant le pool.
Sur mon serveur de stockage, j’ai 3 grappes de 8 disques de 3To en RAIDZ2, donc 6 disques + 2 de redondance à chaque fois.
A cela s’ajoute: 1 SSD pour le cache, 1 disque de 3To en spare que ZFS utilisera automatiquement si un disque d’une des grappes déconne.
Je viens de configurer mon ancien serveur de stockage pour du backup distant… il va aller dans ma maison de campagne et sera branché sur une prise électrique programmable pour un allumage régulier, synchro ZFS puis extinction quand c’est fait.
Tests en cours 
Le bonus: alimentation par panneau solaire / batterie / onduleur… ce que je vais essayer de généraliser chez moi
1 « J'aime »
Complément:
Un zpool peut s’agrandir (zpool add) en ajoutant des vdev, ou en remplaçant tous les disques qui constituent un vdev. Par contre, un vdev ne peut pas s’agrandir en ajoutant juste un disque.
zpool remove existe mais a des limitations… pas possible de retirer un vdev en raidz d’un pool, le reste est ok (de mémoire).
Pour mon serveur principal: 2 disques de redondance (raidz2) par grappe de 8
Pour mon serveur backup: 1 disque sur 5 donc raidz1 (c’est qu’un backup)
Si tu es encore en test, liste moi tes disques dispo, les baies libres pour en ajouter ou pas dans le futur, le niveau de redondance que tu veux.
C’est je pense le sujet le plus discuté autour de ZFS… comment structurer son pool
salut,
rien n’est arrêté , je suis en train de stabiliser la partie hyperviseur (promox me semble adéquate, mais k8s a été envisagé , tout comme du bare-metal pour ispconfig ou cloudmin).
Pour la partie serveur tu sais d’ou elle vient ! J’ai fais des tests de consommation elec., ça se tient bien. (et surtout vu que les supermicro permettent de mettre des HDD RAM etc à des prix modiques)
J’ai surtout racheter un peu de matos : un serveur en plus (identique à ceux que tu m’as donné), bootser la ram à 96 Go (j’ai eu un lot de ram assez dingue niveau prix) , remplacer les proc par des X5677 (15€ la pièce !!).
Pour la partie filesystem (distribué ou pas) : je me tâte.
ZFS avec le système de réplication marche très bien. la VM/CT peut être sur les 3 noeuds en quasi synchro. (synchro qui prennent 3 à40 secondes : c’est rapide)
Ma config est très simple pour l’instant 6 disques de 1To par noeuds (+ il me reste deux slots disque en façade, c’est pour étendre les 6 autres ou placer du ssd).
Seulement j’ai fait un test avec un zpool 4 disques RAIDZ2, outre ma mésaventure de bourrin pour changer un disque. C’est ok.
Mais la , je veux rajouter mes 2 disques en plus dans le zpool RAIDZ2 et la ce n’est pas aussi souple que CEPH. C’est même bloquant , ce veut dire que si je ne place pas dès le début tout les disques pour constituer le vdev : après c’est mort. (ajouter un vdev est, parait-il, pas conseillé du tout , car si un des vdev lache on perds tout le zpoll!)
Là et le dilemme : avec zfs je perds la scalabilité, la souplesse d’extension et du côté de ceph j’ai des perf. moyenne , certes pas catastrophique du tout mais (un peu) moins bonnes qu’avec ZFS , qui lui bouffe aussi de la RAM , ca y’a pas photo.
Avec Ceph j’ai un an d’utilisation et vraiment rien à redire : le truc est béton.
avec ZFS aucun recul prod.
Pas simple ce choix.
Et la je souhaiterai monter à 6 disques
1 « J'aime »
Hum… j’ai un doute sur la fiabilité de ta source d’info du parait-il 
ZFS (comme ceph ou btrfs) nécessite un minimum d’investissement pour comprendre son fonctionnement.
L’essentiel c’est que chaque vdev doit avoir sa propre redondance, c’est juste ça le principe à respecter.
Dans mon cas, j’ai démarré mon pool avec un vdev de 8 disques en raidz2.
Quand il a commencé à arriver vers 80% d’occupation, j’ai rajouté un second vdev de 8 disques en raidz2.
J’ai eu un disque qui montrait des signes de faiblesse à un moment, zed m’a prévenu par mail comme quoi il n’était pas totalement HS mais faisait des I/O error.
Je l’ai remplacé, le resilver s’est fait… zéro indisponibilité, retour à la normale au bout de quelques heures.
J’ai ensuite ajouté un disque en spare, pour que ZFS fasse ce genre de remplacement tout seul (ça fait 1 spare pour 16 disques utilisés).
Depuis, j’ai rajouté un troisième vdev avec encore 8 disques de 3To en raidz2.
Tu vois que pour étendre le pool, ça ne pose aucun problème.
Si tu veux changer la taille des disques (remplacer tes 1To par plus gros), tu peux les remplacer un à un dans un vdev, quand ils seront tous à la nouvelle taille, le vdev offrira automatiquement tout ce nouvel espace au pool. J’ai déjà fait la manip, ça se passe très bien c’est juste un peu long (resilver à chaque remplacement de disque).
Tout ça c’est de la redondance, pas du backup (et encore moins à distance), d’où la mise en place du second serveur pour les backups distants avec les send/recv de ZFS qui font merveille !
Donc tu t’es retrouvé avec 2 block devices ? (un par vdev ?)
/dev/sdx
/dev/sdy
Non, un vdev ne crée pas de block device, c’est interne à ZFS.
Si tes disques sont sda à sdf tu crées ton pool comme ça :
zpool create -o ashift=12 monpool raidz2 sda sdb sdc sdd sde sdf
Il est monté par défaut sur /monpool
L’option ashift=12 c’est pour indiquer à ZFS d’utiliser des blocs de 4Ko (2^12). C’est peut être pas utile avec tes disques de 1To, mais si tu les remplace à l’avenir par des disques en secteurs de 4Ko (fort probable), tu y gagnera car ça ne peut pas se changer après coup.
Tu comprends ce que fais le gars ?
ZFS RAIDZ2 : how to add another disk for extend zpool space ? (c’est ma question chez proxmox)
You only need some other let say temporay(tmp) zfs pool
- zfs send / recive from curent pool to tmp pool
- destroy curent pool
- add your new disk
- create a ne pool using the new disk
- zfs let say receive/send from tmp pool to your new pool
- end task
Il copie son pool sur un autre, temporaire (donc avec des disques pour stocker tout ça)
puis, il casse le pool d’origine, le recrée avec un disque de plus et remet ses données dessus.
C’est lourd, mais seul passage quand on n’a pas trop anticipé. Ridicule aussi de faire un raidz2 avec 4 disques, autant avoir 2 vdev de 2 disques (mirror + mirror).
Pour revenir à ta question de comment organiser ton pool, quel niveau de redondance veux-tu et de quel espace de stockage as-tu besoin à brève et moyenne échéance (2 3 4 ou 5To) ?
tu sais exactement ce que j’ai comme disque lol
plus sérieusement :
je pensais mettre 6 disques sur un zpool (6 x 1 To) par serveur. (je garde 3 slot SATA pour mettre du ssd ou étendre , si je touche des disques pas trop cher)
Et comme j’ai 3 serveurs … j’aurais 3 zpool, avec des replicas type proxmox.
niveau de redondance, je sais pas trop , je sais qu’avec ceph j’ai 6 x 2To (des disques seagate pa cher) donc avec du 3/2 de 12 To on a plus que 4To utilisable au max.
Sur ceph je peux perdre 2 disques sur 6. vu que l’algo sait bosser avec 2 copies (vs 3 en temps normal)
Et ici les adhérents consomment vraiment rien en Go … c’est bizarre d’ailleurs même pas 200Go en 1 ans !
Et je me demande si je pourrai mettre ces disques (des ST2000DM008) , qui ne sont pas vieux même pas un an, dans le serveur supermicro ?
Si tu n’as pas besoin pour démarrer de tant d’espace, fais un zpool avec des vdev mirror et au fur et à mesure du besoin.
Avec sda - sdf ça donne en mirror :
zpool create -o ashift=12 poupoule mirror sda sdb (pour démarrer, avec 1To utilisable)
zpool add poupoule mirror sdc sdd (pour ajouter un 1T en mirror en plus dans le pool)
Avantage : tu pourras retirer ces vdev plus tard si besoin
Tu peux faire pareil en raidz1 pour démarrer avec 2To (sur 3 disques), puis ajouter un deuxième vdev de 2To (et 3 disques). Par contre, ensuite l’évolution ça sera un remplacement d’un paquet de 3 disques 1To par des plus gros (en replace un à un, quand tous les disques d’un vdev sur « upgradés », l’espace supplémentaire devient dispo).
Donc avec du raidz1 ça donne:
zpool create -o ashift=12 poupoule raidz1 sda sdb sdc
plus tard…
zpool add poupoule raidz1 sdd sde sdf
Le raidz2 commencerai à valoir le coup pour 6 disques, mais il t’obligera à changer les 6 disques si tu veux passer à la taille au dessus. Pour ça que je l’utilise sur des vdev de 8 disques.
Si tu veux un poil de redondance en plus, tu peux ajouter un disque en spare (et aussi le retirer du pool quand tu veux) :
zpool add poupoule spare sdg
Comme souvent le tout est de choisir un équilibre entre espace disponible et redondance. La redondance peut être inférieure sur un serveur plus orienté backup (c’est ce que je fais : 1 disque sur 5 en redondance sur le backup mais 2 sur 8 sur le principal). Du coup il y a aussi potentiellement plus d’espace et donc je peux conserver les snapshots sur une plus longue période.
Merci pour toutes ces explications que je dois analyser.
Ok, je comprends mieux ZFS, merci bien pour cet article d’introduction.
du coté kubernetes, les choses ont l’air de bouger, et j’ai l’impression que l’on pourrait utiliser zfs:
https://github.com/openebs/zfs-localpv
Mais en fait, on est parti sur une autre stratégie.
Pour un Nextcloud par exemple, il faut:
- une base de donnée
- des fichiers
Pour la base de donnée, la réplication se passe à ce niveau là, pas besoin ni de zfs, ni de ceph.
Pour les fichiers, on utilise une api comptaible s3. Pour le moment on utilise ceph pour cela, mais il existe aussi minio.
Mais du coup, si on prends l’exemple de minio, il tourne sur un seul nœud, n’est-ce pas?
Donc, si la machine est off, plus de minio.
Mais, grace a zfs, pour les updates, ou changement de disque, tu bouges le service d’une machine a lautre avant j’imagine.
Reste le cas de la panne, la, si une machine tombe, il faut que tu interviennes, pour soit:
- restart sur une autre machine, et tu repars du snapshot de l’heure d’avant par exemple
- ou tu répares la machine et en avant.
Et aussi, si tu as un utilisateur qui a besoin de 55TB du coup, tu peux pas. Mais on est d’accord, c’est assez rare
Du coup, je pense que je préfère ceph pour la tranquillité d’esprit.
Si une machine tombe, c’est pas grave, pour update, j’update les nœuds un après l’autre sans me soucier de applicatif.
(Et pour kubernetes, pour les apps qui tournent dessus, c’est pareil 
)
C’est ce que proxmox gère tout seul avec son fonctionnement en haute-dispo au sein d’un cluster de noeuds physiques… avec ZFS ou ceph en stockage (entre autres).
Le but de cette discussion n’est pas de convaincre que ZFS c’est THE solution, mais de le faire connaitre. Ensuite chacun voit pour ses usages, son archi si ça peut être utile ou pas, mais au moins savoir que ça existe et ce que ça fait (et ne fait pas) est un élément de plus au moment de choisir.
2 « J'aime »