Je viens de tomber sur ce post en cherchant des trucs sur ZFS.
Je viens de voir quelques échanges et je me dis que je pourrais y ajouter un petit grain de sel ;-)
Je n'étais pas inscris sur LinuxFR ... c'est chose faite.
Voici ce que je peux dire:
J'ai testé ZFS sur Freenas puis sur Nas4Free (pour info, Nas4free est la suite de Freenas, Freenas ayant été racheté par une société commerciale à la version 8)
Cela fait des années que j'utilise ZFS, mon serveur perso de la maison a 3 disques de 2To sur une petite carte D510 Intel avec 4Go de RAM, ça marche Nickel et ça fait serveur DLNA.
J'ai 3 onduleurs ... sans batteries, lol ... et mes nas sous ZFS ont connus plusieurs fois des coupures de courant en plein travail (écritures multiples) ... même pas d'erreurs ! normal c'est du COW (CopyOnWrite).
Cela fait quelques mois que je me mets a utiliser ZFS sur Linux et je trouve que cela marche très bien, très simple avec des disques usb avec la notion d'export (pas besoin de partoche, ça dit ce qu'on peut monter .. ou pas avec la commande zpool import).
Pour la gestion de ZFS, il faut de la RAM, c'est mieux mais pas obligatoire, avant, cela posait des pb, mais depuis quelques temps la gestion est mieux faite, normalement, on dit qu'il faut 1Go de RAM par To.
En fait ce qu'il faut comprendre c'est que ZFS va fonctionner par couches, il utilise d'abord la RAM, puis le(s) SSD; puis le(s) disques.
Pour ma part, j'ai commencé avec du SATA, mais aujourd'hui j'utilise du SAS, pas pour les donnée mais pour le log (des fois) mais surtout pour le cache (zpool add nomdupool cache /dev/sdd /dev/sdd, par exemple)
Quand on a pas de RAM et pas de SSD, il faut avoir un bon cache disque, je conseille de trouver de cartes SAS (de 20 à 100 euros sur les sites de bonnes affaires et de mettre quelques disques SAS (mais on peut utiliser un disques SATA ça marche aussi ... mais moins bien;-)
Perso, je monte à plus de 1,1 Go/s avec 6 disques Seagate de 300Go 15k7, mais déjà avec 2 disques en raid0 matériel ou en entrelacés ZFS, on peut avoir de bons résultats.
La carte SAS, à l'avantage de passer par le "pont-nord" de la carte mère, alors que les ports SATA passeront par le "pont-sud", ce qui dans certains cas donneront des performances mauvaises (le SATA peut être bon sur le papier mais ça ne tient pas la route "en charge", il a un fonctionnement plus simpliste que le SAS)
Une astuce, on peut mettre du SATA sur une carte SAS et bénéficier du "pont-nord" (accès direct avec le proc)
Si je peux donner un conseil, c'est de privilégier ce point: avoir un "bon cache ZFS" (Si possible SSD ou SAS: ne pas oublier que ZFS a été conçu pour du SAS).
Pour la déduplication, je viens de faire pleins de tests là dessus, en fait, vouloir dédupliquer toutes ces données est une utopie, car cela va représenter une table de déduplication immense et il faudra une machine de guerre pour gérer cela.
Pour ma part, j'utilise désormais la déduplication ZFS sous Debian uniquement sur des fichiers VMDK de machines virtuelles et de même type. J'ai 150Go à sauvegarder par jour.
Tous les essais de déduplication que j'ai fais sur:
- l'ensemble de mes données (fichiers courant)
- les fichiers OVA
- la vidéo
s'est révélés catastrophique, car quand la table augmente, le temps d'accès devient très long et le taux de transfert peut finir en Ko/s !!!
En revanche, si on cible "ses données", c'est à dire que l'on comprend bien ce qu'on veut dédupliquer, on a un bon résultat, par exemple, sur un fichier brut de type VMDK, il y aura quelques Mo de différents. Ce fichier (brut) ne bougera pas et c'est seulement les différences qui seront écrites en plus par ZFS. Si on copie un fichier OVA, soit une exportation d'un fichier VMDK+config, alors là on aura une différence depuis le début et, du coup, c'est tous les blocs qui seront différents ... adieu la déduplication !)
On peut jouer sur le cache primaire et secondaire pour améliorer mais ça ne fera pas tout.
Après quelques copies de fichiers VMDK, j'ai un cache de 3Go, donc, pour que le système puisse s'en sortir, deux solutions:
- soit du SSD et là, il trouve rapidement "ses petits" (vu le prix des SSD j'abandonne)
- soit "l'ensemble disque" est performant et là on aura des performances acceptables (actuellement, j'ai 2 disques de cache 15k7 (200Mo/s pour chaque disque) et une carte LSI avec 512Mo de cache).
J'ai ciblé mes sauvegardes de fichiers vmdk en faisant un pool dédié (de même type) et je ne fais que ça, j'arrête surtout ZFS quand je change de pool (/etc/init.d/zfs-fuse stop), car sinon, il va garder sa table en mémoire et elle augmentera avec les autres données et là ce sera 10Go en cache qu'il faudra scruter !
Donc, le ZFS oui ! la déduplication ... oui MAIS sous des conditions strictes de bon sens avec une bonne compréhension des données que l'on possède... ou alors on investi dans une carte bi-xéon avec 192Go de RAM, 32Go de SSD, et là c'est fantastique.
Pour info, pour avoir une bonne déduplication, il faudrait "aller" vers des blocs petits (512 octets), la déduplication par défaut est sur des blocs de 128Ko (plus les blocs sont gros, moins ça déduplique).
Avec des fichiers de type "image de disque", vdi, ou vmdk, il faut utiliser les blocs de 128Ko.
Pour l'instant, je suis en production avec une B75/AsRock/8Go de RAM avec un i5-2500, carte LSI de 512Mo de cache et 4 disques SAS 15k7, ça rame en moyenne à 15Mo/s, c'est le temps qu'il faut pour scruter le cache et la table.
Je suis pris à la gorge car mes données s'accumulent, mais bon, ça charge doucement, le facteur de déduplicaction monte, c'est l’essentiel !
Mais dans quelques temps, je mets en service une carte bi-xéon avec 32Go de RAM avec 4 ou 6 disques de cache soit 10 disques durs SAS uniquement pour le fonctionnement de ZFS (2 cartes contrôleurs SAS), tant que je peux le faire en 'disques durs', je ferai ! na!
..; en été c'est pas top avec 10 disques ;-/ .. quand les SSD seront moins cher j'investirai.
Voilà en gros mon avis.
PS: je crois que les nouvelles cartes mères n'ont plus de "pont-nord".
# petit retour d'expérience en ZFS
Posté par mtiburs . En réponse au message ZFS performance et déduplication. Évalué à 3.
Bonjour,
Je viens de tomber sur ce post en cherchant des trucs sur ZFS.
Je viens de voir quelques échanges et je me dis que je pourrais y ajouter un petit grain de sel ;-)
Je n'étais pas inscris sur LinuxFR ... c'est chose faite.
Voici ce que je peux dire:
J'ai testé ZFS sur Freenas puis sur Nas4Free (pour info, Nas4free est la suite de Freenas, Freenas ayant été racheté par une société commerciale à la version 8)
Cela fait des années que j'utilise ZFS, mon serveur perso de la maison a 3 disques de 2To sur une petite carte D510 Intel avec 4Go de RAM, ça marche Nickel et ça fait serveur DLNA.
J'ai 3 onduleurs ... sans batteries, lol ... et mes nas sous ZFS ont connus plusieurs fois des coupures de courant en plein travail (écritures multiples) ... même pas d'erreurs ! normal c'est du COW (CopyOnWrite).
Cela fait quelques mois que je me mets a utiliser ZFS sur Linux et je trouve que cela marche très bien, très simple avec des disques usb avec la notion d'export (pas besoin de partoche, ça dit ce qu'on peut monter .. ou pas avec la commande zpool import).
Pour la gestion de ZFS, il faut de la RAM, c'est mieux mais pas obligatoire, avant, cela posait des pb, mais depuis quelques temps la gestion est mieux faite, normalement, on dit qu'il faut 1Go de RAM par To.
En fait ce qu'il faut comprendre c'est que ZFS va fonctionner par couches, il utilise d'abord la RAM, puis le(s) SSD; puis le(s) disques.
Pour ma part, j'ai commencé avec du SATA, mais aujourd'hui j'utilise du SAS, pas pour les donnée mais pour le log (des fois) mais surtout pour le cache (zpool add nomdupool cache /dev/sdd /dev/sdd, par exemple)
Quand on a pas de RAM et pas de SSD, il faut avoir un bon cache disque, je conseille de trouver de cartes SAS (de 20 à 100 euros sur les sites de bonnes affaires et de mettre quelques disques SAS (mais on peut utiliser un disques SATA ça marche aussi ... mais moins bien;-)
Perso, je monte à plus de 1,1 Go/s avec 6 disques Seagate de 300Go 15k7, mais déjà avec 2 disques en raid0 matériel ou en entrelacés ZFS, on peut avoir de bons résultats.
La carte SAS, à l'avantage de passer par le "pont-nord" de la carte mère, alors que les ports SATA passeront par le "pont-sud", ce qui dans certains cas donneront des performances mauvaises (le SATA peut être bon sur le papier mais ça ne tient pas la route "en charge", il a un fonctionnement plus simpliste que le SAS)
Une astuce, on peut mettre du SATA sur une carte SAS et bénéficier du "pont-nord" (accès direct avec le proc)
Si je peux donner un conseil, c'est de privilégier ce point: avoir un "bon cache ZFS" (Si possible SSD ou SAS: ne pas oublier que ZFS a été conçu pour du SAS).
Pour la déduplication, je viens de faire pleins de tests là dessus, en fait, vouloir dédupliquer toutes ces données est une utopie, car cela va représenter une table de déduplication immense et il faudra une machine de guerre pour gérer cela.
Pour ma part, j'utilise désormais la déduplication ZFS sous Debian uniquement sur des fichiers VMDK de machines virtuelles et de même type. J'ai 150Go à sauvegarder par jour.
Tous les essais de déduplication que j'ai fais sur:
- l'ensemble de mes données (fichiers courant)
- les fichiers OVA
- la vidéo
s'est révélés catastrophique, car quand la table augmente, le temps d'accès devient très long et le taux de transfert peut finir en Ko/s !!!
En revanche, si on cible "ses données", c'est à dire que l'on comprend bien ce qu'on veut dédupliquer, on a un bon résultat, par exemple, sur un fichier brut de type VMDK, il y aura quelques Mo de différents. Ce fichier (brut) ne bougera pas et c'est seulement les différences qui seront écrites en plus par ZFS. Si on copie un fichier OVA, soit une exportation d'un fichier VMDK+config, alors là on aura une différence depuis le début et, du coup, c'est tous les blocs qui seront différents ... adieu la déduplication !)
On peut jouer sur le cache primaire et secondaire pour améliorer mais ça ne fera pas tout.
Après quelques copies de fichiers VMDK, j'ai un cache de 3Go, donc, pour que le système puisse s'en sortir, deux solutions:
- soit du SSD et là, il trouve rapidement "ses petits" (vu le prix des SSD j'abandonne)
- soit "l'ensemble disque" est performant et là on aura des performances acceptables (actuellement, j'ai 2 disques de cache 15k7 (200Mo/s pour chaque disque) et une carte LSI avec 512Mo de cache).
J'ai ciblé mes sauvegardes de fichiers vmdk en faisant un pool dédié (de même type) et je ne fais que ça, j'arrête surtout ZFS quand je change de pool (/etc/init.d/zfs-fuse stop), car sinon, il va garder sa table en mémoire et elle augmentera avec les autres données et là ce sera 10Go en cache qu'il faudra scruter !
Donc, le ZFS oui ! la déduplication ... oui MAIS sous des conditions strictes de bon sens avec une bonne compréhension des données que l'on possède... ou alors on investi dans une carte bi-xéon avec 192Go de RAM, 32Go de SSD, et là c'est fantastique.
Pour info, pour avoir une bonne déduplication, il faudrait "aller" vers des blocs petits (512 octets), la déduplication par défaut est sur des blocs de 128Ko (plus les blocs sont gros, moins ça déduplique).
Avec des fichiers de type "image de disque", vdi, ou vmdk, il faut utiliser les blocs de 128Ko.
Pour l'instant, je suis en production avec une B75/AsRock/8Go de RAM avec un i5-2500, carte LSI de 512Mo de cache et 4 disques SAS 15k7, ça rame en moyenne à 15Mo/s, c'est le temps qu'il faut pour scruter le cache et la table.
Je suis pris à la gorge car mes données s'accumulent, mais bon, ça charge doucement, le facteur de déduplicaction monte, c'est l’essentiel !
Mais dans quelques temps, je mets en service une carte bi-xéon avec 32Go de RAM avec 4 ou 6 disques de cache soit 10 disques durs SAS uniquement pour le fonctionnement de ZFS (2 cartes contrôleurs SAS), tant que je peux le faire en 'disques durs', je ferai ! na!
..; en été c'est pas top avec 10 disques ;-/ .. quand les SSD seront moins cher j'investirai.
Voilà en gros mon avis.
PS: je crois que les nouvelles cartes mères n'ont plus de "pont-nord".