Bonjour à tous, Je souhaite configurer un serveur Dell R720XD avec 12DD de 4To pour qu'il m'exporte en NFS du To dédié à de la sauvegarde. Dans ce cas de figure, je privilégie donc le capacitif plutôt que la performance et je souhaite bénéficier de la compression et déduplication. ZFS me paraît alors approprié (et puis ça m'arrange vu que ça fait un bail que je veux le tester!). Je précise que j'ai 2 DD dédiés pour l'OS.
Après avoir installé le FreeBSD had hoc, je me pose la question de la géométrie du zpool.
Dans la doc (http://www.freebsd.org/doc/handbook/filesystems-zfs.html), il est indiqué : " Sun™ recommends that the amount of devices used in a RAID-Z configuration is between three and nine. For environments requiring a single pool consisting of 10 disks or more, consider breaking it up into smaller RAID-Z groups. If only two disks are available and redundancy is a requirement, consider using a ZFS mirror. Refer to zpool(8) for more details. "
Faire 2 zpool de 6 disques et donc 2 export NFS est contraignant ...
Quel est votre avis ? Merci par avance. Laurent.
Bonjour, (Je me rends compte que j'ai oublié de répondre à la liste, alors je le refais ici:)
On Thu, Oct 31, 2013 at 10:51:45AM +0100, Laurent Beunèche wrote:
Sun™ recommends that the amount of devices used in a RAID-Z configuration is between three and nine. For environments requiring a single pool consisting of 10 disks or more, consider breaking it up into smaller RAID-Z groups. If only two disks are available and redundancy is a requirement, consider using a ZFS mirror. Refer to zpool(8) for more details. "
Faire 2 zpool de 6 disques et donc 2 export NFS est contraignant ...
Quel est votre avis ?
Mon avis, est qu'il faut faire non pas 2, mais 1 zpool avec plusieurs vdevs.
Par contre, pour la configuration des vdev, je conseillerais pas nécessairement du raidz1 sur 6 disques, si jamais deux disques pètent sur le même vdev, c'est pas bien marrant. Il me semble qu'on trouve ça dans les recommendations chez sun, sur 6 disques de plutôt utiliser du rzaid2 dans ce cas.
Bonne journée,
-- Pablo Joubert
On 31/10/2013 10:51, Laurent Beunèche wrote:
Bonjour à tous, Je souhaite configurer un serveur Dell R720XD avec 12DD de 4To pour qu'il m'exporte en NFS du To dédié à de la sauvegarde. Dans ce cas de figure, je privilégie donc le capacitif plutôt que la performance et je souhaite bénéficier de la compression et déduplication. ZFS me paraît alors approprié (et puis ça m'arrange vu que ça fait un bail que je veux le tester!). Je précise que j'ai 2 DD dédiés pour l'OS.
Après avoir installé le FreeBSD had hoc, je me pose la question de la géométrie du zpool.
Dans la doc (http://www.freebsd.org/doc/handbook/filesystems-zfs.html), il est indiqué : " Sun™ recommends that the amount of devices used in a RAID-Z configuration is between three and nine. For environments requiring a single pool consisting of 10 disks or more, consider breaking it up into smaller RAID-Z groups. If only two disks are available and redundancy is a requirement, consider using a ZFS mirror. Refer to zpool(8) for more details. "
Faire 2 zpool de 6 disques et donc 2 export NFS est contraignant ...
Quel est votre avis ? Merci par avance. Laurent.
Bonjour, je vais laisser les autres repondre pour le zpool, je vais plutot m attarder sur un seul mot de ce mail : déduplication.
Sur tous les tests que j'ai fait, plus mon experience en prod (5 ans chez un vendeur de solutions de sauvegarde) + les diverses confs que j ai vu (je pense notamment a la conf zfs faite par gandi/beorn), je deconseille l utilisation de la deduplication. Son cout par rapport au gain est vraiment peu interessant dans la tres grande majorite des cas. que ce soit de la deduplication au niveau bloc comme au niveau fichier.
Guillaume,
Pourrais tu allez plus loin dans ta réponse car pour ma part les différente fois ou j'ai activé la dedup sur des baies (ou il y avait de la virtualisation) ou sur des systèmes de test cela avait un apport relativement intéressant (entre 25 et 60%) de gain d'espace avec un overhead de qq % de cpu et io. Surtout que dans le cas demandé ce "n'est que" du backup donc moins critique en terme de performance.
Cdt,
Cyrille Le 31 oct. 2013 11:24, "Guillaume Friloux" guillaume.friloux@asp64.com a écrit :
On 31/10/2013 10:51, Laurent Beunèche wrote:
Bonjour à tous, Je souhaite configurer un serveur Dell R720XD avec 12DD de 4To pour qu'il m'exporte en NFS du To dédié à de la sauvegarde. Dans ce cas de figure, je privilégie donc le capacitif plutôt que la performance et je souhaite bénéficier de la compression et déduplication. ZFS me paraît alors approprié (et puis ça m'arrange vu que ça fait un bail que je veux le tester!). Je précise que j'ai 2 DD dédiés pour l'OS.
Après avoir installé le FreeBSD had hoc, je me pose la question de la géométrie du zpool.
Dans la doc (http://www.freebsd.org/doc/**handbook/filesystems-zfs.htmlhttp://www.freebsd.org/doc/handbook/filesystems-zfs.html )**, il est indiqué : " Sun™ recommends that the amount of devices used in a RAID-Z configuration is between three and nine. For environments requiring a single pool consisting of 10 disks or more, consider breaking it up into smaller RAID-Z groups. If only two disks are available and redundancy is a requirement, consider using a ZFS mirror. Refer to zpool(8) for more details. "
Faire 2 zpool de 6 disques et donc 2 export NFS est contraignant ...
Quel est votre avis ? Merci par avance. Laurent.
Bonjour, je vais laisser les autres repondre pour le zpool, je vais
plutot m attarder sur un seul mot de ce mail : déduplication.
Sur tous les tests que j'ai fait, plus mon experience en prod (5 ans chez un vendeur de solutions de sauvegarde) + les diverses confs que j ai vu (je pense notamment a la conf zfs faite par gandi/beorn), je deconseille l utilisation de la deduplication. Son cout par rapport au gain est vraiment peu interessant dans la tres grande majorite des cas. que ce soit de la deduplication au niveau bloc comme au niveau fichier.
Liste de diffusion du FRsAG http://www.frsag.org/
Quelque soit la techno, la dédup est pratique lorsque vous avez des données redondantes. C'est typiquement le cas dans des parcs de VM par exemple. Pour des logs, pas certain que la déduplication fasse gagner grand chose.
Sinon pour parler de ZFS spécifiquement, les rares bugs que j'ai vu sur ce système de fichiers concernait à chaque fois la partie dédup (souci de consommation mémoire, overhead, ...). Perso, j'hésite à l'activer et je préfère me reposer sur la compression à la volée.
Olivier
Le 31 octobre 2013 12:05, Cyrille Verger cverger99@gmail.com a écrit :
Guillaume,
Pourrais tu allez plus loin dans ta réponse car pour ma part les différente fois ou j'ai activé la dedup sur des baies (ou il y avait de la virtualisation) ou sur des systèmes de test cela avait un apport relativement intéressant (entre 25 et 60%) de gain d'espace avec un overhead de qq % de cpu et io. Surtout que dans le cas demandé ce "n'est que" du backup donc moins critique en terme de performance.
Cdt,
Cyrille
Le 31 oct. 2013 11:24, "Guillaume Friloux" guillaume.friloux@asp64.com a écrit :
On 31/10/2013 10:51, Laurent Beunèche wrote:
Bonjour à tous, Je souhaite configurer un serveur Dell R720XD avec 12DD de 4To pour qu'il m'exporte en NFS du To dédié à de la sauvegarde. Dans ce cas de figure, je privilégie donc le capacitif plutôt que la performance et je souhaite bénéficier de la compression et déduplication. ZFS me paraît alors approprié (et puis ça m'arrange vu que ça fait un bail que je veux le tester!). Je précise que j'ai 2 DD dédiés pour l'OS.
Après avoir installé le FreeBSD had hoc, je me pose la question de la géométrie du zpool.
Dans la doc (http://www.freebsd.org/doc/handbook/filesystems-zfs.html), il est indiqué : " Sun™ recommends that the amount of devices used in a RAID-Z configuration is between three and nine. For environments requiring a single pool consisting of 10 disks or more, consider breaking it up into smaller RAID-Z groups. If only two disks are available and redundancy is a requirement, consider using a ZFS mirror. Refer to zpool(8) for more details. "
Faire 2 zpool de 6 disques et donc 2 export NFS est contraignant ...
Quel est votre avis ? Merci par avance. Laurent.
Bonjour, je vais laisser les autres repondre pour le zpool, je vais plutot m attarder sur un seul mot de ce mail : déduplication.
Sur tous les tests que j'ai fait, plus mon experience en prod (5 ans chez un vendeur de solutions de sauvegarde) + les diverses confs que j ai vu (je pense notamment a la conf zfs faite par gandi/beorn), je deconseille l utilisation de la deduplication. Son cout par rapport au gain est vraiment peu interessant dans la tres grande majorite des cas. que ce soit de la deduplication au niveau bloc comme au niveau fichier.
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
On Thu, Oct 31, 2013 at 12:15:00PM +0100, Olivier Doucet wrote:
Sinon pour parler de ZFS spécifiquement, les rares bugs que j'ai vu sur ce système de fichiers concernait à chaque fois la partie dédup (souci de consommation mémoire, overhead, ...). Perso, j'hésite à l'activer et je préfère me reposer sur la compression à la volée.
It's not a bug ! Dédupliquer, c'est conserver en RAM le checksum de chaque bloc, afin de retrouver ce bloc si on voulait stocker le même contenu. La RAM nécessaire est directement proportionnelle au nombre de bloc du pool, cf http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-siz...
Par conséquent, la déduplication consomme énormément de RAM, je n'en recommande pas l'usage, sauf si on a un budget RAM disproportionné … déjà que ZFS est très gourmant en RAM... (ARC)
-- Pablo Joubert
Je me suis mal exprimé : les bugs rencontrés étaient une consommation excessive de la mémoire, disproportionnée avec l'usage normal attendu d'une déduplication.
Le 31 octobre 2013 13:27, piti pablo.piti@gmail.com a écrit :
On Thu, Oct 31, 2013 at 12:15:00PM +0100, Olivier Doucet wrote:
Sinon pour parler de ZFS spécifiquement, les rares bugs que j'ai vu sur ce système de fichiers concernait à chaque fois la partie dédup (souci de consommation mémoire, overhead, ...). Perso, j'hésite à l'activer et je préfère me reposer sur la compression à la volée.
It's not a bug ! Dédupliquer, c'est conserver en RAM le checksum de chaque bloc, afin de retrouver ce bloc si on voulait stocker le même contenu. La RAM nécessaire est directement proportionnelle au nombre de bloc du pool, cf http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-siz...
Par conséquent, la déduplication consomme énormément de RAM, je n'en recommande pas l'usage, sauf si on a un budget RAM disproportionné … déjà que ZFS est très gourmant en RAM... (ARC)
-- Pablo Joubert _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
+--On 31 octobre 2013 11:24:16 +0100 Guillaume Friloux guillaume.friloux@asp64.com wrote: | Sur tous les tests que j'ai fait, plus mon experience en prod (5 ans chez | un vendeur de solutions de sauvegarde) + les diverses confs que j ai vu | (je pense notamment a la conf zfs faite par gandi/beorn), je deconseille | l utilisation de la deduplication. Son cout par rapport au gain est | vraiment peu interessant dans la tres grande majorite des cas. que ce | soit de la deduplication au niveau bloc comme au niveau fichier.
Je plussoie grandement, pour que ça fonctionne de manière utilisable, (c'est à dire ou on peut écrire sur le disque sans trop de latence,) il faut que le checksum de tous les blocs du pool tiennent en mémoire, et ça veut dire que ça va prendre *beaucoup* de mémoire.
J'avais fait des tests sur nos serveurs de sauvegarde, la déduplication n'apporte rien, ça coûte moins cher d'acheter un ou deux disques de plus que d'avoir la déduplication.
Le 31/10/2013 15:56, Mathieu Arnold a écrit :
+--On 31 octobre 2013 11:24:16 +0100 Guillaume Friloux guillaume.friloux@asp64.com wrote: | Sur tous les tests que j'ai fait, plus mon experience en prod (5 ans chez | un vendeur de solutions de sauvegarde) + les diverses confs que j ai vu | (je pense notamment a la conf zfs faite par gandi/beorn), je deconseille | l utilisation de la deduplication. Son cout par rapport au gain est | vraiment peu interessant dans la tres grande majorite des cas. que ce | soit de la deduplication au niveau bloc comme au niveau fichier.
Je plussoie grandement, pour que ça fonctionne de manière utilisable, (c'est à dire ou on peut écrire sur le disque sans trop de latence,) il faut que le checksum de tous les blocs du pool tiennent en mémoire, et ça veut dire que ça va prendre *beaucoup* de mémoire.
[...]
Hello,
Juste en passant, je ne connais pas assez ZFS pour savoir. N'y a-t-il pas un moyen de faire de la déduplication en batch plutôt qu'à la volée ? Ça consommerait de la mémoire que pendant ce traitement, le reste du temps, pas d'overhead ni de conso mémoire.
Bonjour,
Avec 12 disques et pour du backup, tu peux tester une config du genre : => 1 zpool composé de 2 vdev raidz de 6 disques
En pratique, un truc du genre : zpool create mybigbackupzpool raidz disque1 disque2 disque3 disque4 disque5 disque6 raidz disque7 disque8 disque9 disque10 disque11 disque12
En fait, 2 vdev raidz, ca veut dire une géométrie très proche du RAID50 en gros : tes lectures écritures sont découpés en 2 (découpage du type raid0) entre 2 "vdevs" (sorte de sous-zpool) raidz donc très proche du raid5.
Plus d'info et un schéma sur ce post par exemple : http://forums.freebsd.org/showpost.php?s=df9c7255bfbb379e336347eb1fc52d1f&am...
Hello,
ZFS est tres consommateur de ram, surtout avec dedup. tu as prevu combien ? Regarde aussi pour mettre ZIL et L2ARC sur des SSD en mirroir. Pour ma part, en termes de performance, je prefere un solaris based comme OS pour ZFS même si j'avoue ne plus être au courant des évolutions de BSD/FreeNAS
Pour t'inspirer: http://www.zfsbuild.com/2010/06/03/howto-our-zpool-configuration/
Mehdi
Le 31 octobre 2013 12:18, Florent Rivoire florent@rivoire.fr a écrit :
Bonjour,
Avec 12 disques et pour du backup, tu peux tester une config du genre : => 1 zpool composé de 2 vdev raidz de 6 disques
En pratique, un truc du genre : zpool create mybigbackupzpool raidz disque1 disque2 disque3 disque4 disque5 disque6 raidz disque7 disque8 disque9 disque10 disque11 disque12
En fait, 2 vdev raidz, ca veut dire une géométrie très proche du RAID50 en gros : tes lectures écritures sont découpés en 2 (découpage du type raid0) entre 2 "vdevs" (sorte de sous-zpool) raidz donc très proche du raid5.
Plus d'info et un schéma sur ce post par exemple :
http://forums.freebsd.org/showpost.php?s=df9c7255bfbb379e336347eb1fc52d1f&am...
-- Florent
2013/10/31 Laurent Beunèche lb@univ-tours.fr:
Bonjour à tous, Je souhaite configurer un serveur Dell R720XD avec 12DD de 4To pour
qu'il m'exporte en NFS du To dédié à de la sauvegarde.
Dans ce cas de figure, je privilégie donc le capacitif plutôt que la
performance et je souhaite bénéficier de la compression et déduplication.
ZFS me paraît alors approprié (et puis ça m'arrange vu que ça fait un
bail que je veux le tester!).
Je précise que j'ai 2 DD dédiés pour l'OS.
Après avoir installé le FreeBSD had hoc, je me pose la question de la
géométrie du zpool.
Dans la doc (http://www.freebsd.org/doc/handbook/filesystems-zfs.html),
il est indiqué :
" Sun™ recommends that the amount of devices used in a RAID-Z
configuration is between three and nine. For environments requiring a single pool consisting of 10 disks or more, consider breaking it up into smaller RAID-Z groups. If only two disks are available and redundancy is a requirement, consider using a ZFS mirror. Refer to zpool(8) for more details.
"
Faire 2 zpool de 6 disques et donc 2 export NFS est contraignant ...
Quel est votre avis ? Merci par avance. Laurent.
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le 31/10/2013 13:35, Mehdi Sebbar a écrit :
Hello,
ZFS est tres consommateur de ram, surtout avec dedup. tu as prevu combien ? Regarde aussi pour mettre ZIL et L2ARC sur des SSD en mirroir.
Pas besoin de mirroir pour le L2ARC. Par contre en ZIL, les effets de la perte d'un disque non redondé restent toujours de l'ordre de la divination pour moi. Certains disent qu'ils ont perdu des données et les devs du truc disent que ca doit se passer sans problème (mais je vois mal comment). Du coup, je mirorrise.
Aussi regarder les perfs des SSD, certains sont bons en lecture, d'autre en écriture (à l'époque c'était la différence entre SLC et MLC mais avec les eMLC, c'est plus flou).
Julien
On Thu, Oct 31, 2013 at 03:45:52PM +0100, Julien Escario wrote:
Pas besoin de mirroir pour le L2ARC. Par contre en ZIL, les effets de la perte d'un disque non redondé restent toujours de l'ordre de la divination pour moi. Certains disent qu'ils ont perdu des données et les devs du truc disent que ca doit se passer sans problème (mais je vois mal comment). Du coup, je mirorrise.
En fait, ce qui est annoncé, c'est qu'il n'y aura pas de corruption du système de fichier. Par contre, des fichiers perçus comme écrits par les clients pourraient être perdus dans l'aventure.
Le ZIL, c'est juste un cache d'écriture, si celui-ci casse avant d'avoir été flushé dans les disques (par burst), les données annoncées comme écrites sont en fait perdues. (Même effet pour un ZIL en RAM et un shutdown)
Dans tous les cas, on est plus sur avec un mirroir :)
-- Pablo Joubert
On 31/10/2013 14:45, Julien Escario wrote:
Pas besoin de mirroir pour le L2ARC. Par contre en ZIL, les effets de la perte d'un disque non redondé restent toujours de l'ordre de la divination pour moi. Certains disent qu'ils ont perdu des données et les devs du truc disent que ca doit se passer sans problème (mais je vois mal comment). Du coup, je mirorrise.
Pour répondre à tes interrogations : ça dépend à quel moment le SLOG (et non pas le ZIL, qui est un abus de langage ici) foire.
Si le SLOG meurt simplement de lui-même alors que le système est en train de tourner, alors tout ira bien : ZFS va le retirer de la pool et écrire les données en vol du TXG courant dans la pool, ensuite il va ignorer le SLOG et écrire le ZIL sur la pool. Il faut bien comprendre que le ZIL sur disque est toujours une copie du ZIL en RAM, donc ZFS peut sans problème réécrire les données. Donc pas de souci.
En revanche, si le décès du SLOG coïncide avec un arrêt brutal du système (cas typique : le système crashe et le SSD meurt au redémarrage), alors les données qui étaient commitées dans le ZIL mais se trouvant encore dans la TXG en vol au moment de l'arrêt du système (les 5 dernières secondes, en gros) seront définitivement perdues, car ZFS ne peut alors plus se replier sur le ZIL en RAM pour retrouver ses petits.
Il faut également mentionner que du fait de la manière dont ZFS gère les groupes de transactions, qui sont toujours flushés dans l'ordre, le système de fichier présente une propriété intéressante qui est que même avec sync=disabled (c'est-à-dire ZIL désactivé), il est possible de perdre des données, mais il n'y aura pas de corruption à proprement parler - c'est-à-dire que le système revient « proprement » à un moment donné dans le passé (ici la dernière TXG qui est arrivée à temps sur le disque, typiquement 5 secondes en arrière). En d'autres termes, dans les propriétés ACID seul le « D » est affecté, le reste tient toujours. Cela n'est pas vrai pour d'autres systèmes de fichiers tels que ext4.
Yop,
On Thu, Oct 31, 2013 at 09:44:31PM +0000, Etienne Dechamps wrote:
Il faut également mentionner que du fait de la manière dont ZFS gère les groupes de transactions, qui sont toujours flushés dans l'ordre, le système de fichier présente une propriété intéressante qui est que même avec sync=disabled (c'est-à-dire ZIL désactivé), il est possible de perdre des données, mais il n'y aura pas de corruption à proprement parler - c'est-à-dire que le système revient « proprement » à un moment donné dans le passé (ici la dernière TXG qui est arrivée à temps sur le disque, typiquement 5 secondes en arrière). En d'autres termes, dans les propriétés ACID seul le « D » est affecté, le reste tient toujours.
Cela n'est pas vrai pour d'autres systèmes de fichiers tels que ext4.
Humm, t'es sûr de ça ? Ça ressemble aux barriers, et c'est activé par défaut en ext4.
Sylvain
On 31/10/2013 21:55, Sylvain Rochet wrote:
On Thu, Oct 31, 2013 at 09:44:31PM +0000, Etienne Dechamps wrote:
Il faut également mentionner que du fait de la manière dont ZFS gère les groupes de transactions, qui sont toujours flushés dans l'ordre, le système de fichier présente une propriété intéressante qui est que même avec sync=disabled (c'est-à-dire ZIL désactivé), il est possible de perdre des données, mais il n'y aura pas de corruption à proprement parler - c'est-à-dire que le système revient « proprement » à un moment donné dans le passé (ici la dernière TXG qui est arrivée à temps sur le disque, typiquement 5 secondes en arrière). En d'autres termes, dans les propriétés ACID seul le « D » est affecté, le reste tient toujours.
Cela n'est pas vrai pour d'autres systèmes de fichiers tels que ext4.
Humm, t'es sûr de ça ? Ça ressemble aux barriers, et c'est activé par défaut en ext4.
Les barriers telles qu'elles sont normalement implémentées offrent la garantie (D) suivante : si une barrier est exécutée avec succès après la fin d'une écriture A, alors A est durablement écrite sur stockage durable (sous-entendu pourra être relu après un crash).
(D) implique directement la propriété suivante (C) : si une barrier est exécutée après la fin d'une écriture A, et qu'une écriture B est effectuée après l'exécution de la barrier, alors si on peut relire B, cela implique qu'on peut relire A.
La proposition (D) est indispensable pour garantir la durabilité. Par contre elle n'est pas indispensable pour garantir la cohérence (non-corruption) des données. Pour garantir la cohérence des données (C) est suffisant.
ZFS avec le ZIL activé offre la garantie (D), c'est-à-dire les barriers. C'est une garantie de cohérence *et* de durabilité. Comme ext4 par défaut.
ZFS avec le ZIL désactivé (sync=disabled), qui présente évidemment l'avantage d'être plus rapide, n'offre plus la garantie (D), mais il offre toujours la garantie (C), c'est-à-dire qu'il offre une garantie de cohérence.
Le parallèle que je faisais avec ext4 (et je me rends compte que je me suis mal exprimé sur ce point) est que par défaut ext4 offre (D), et si tu désactives les barriers (via data=writeback ou barrier=0, si j'interprète correctement les options), alors tu n'obtiens plus rien, même pas (C). ZFS, lui, te donne l'option d'obtenir des performances supérieures en laissant tomber la durabilité (D), mais en conservant la cohérence (C).
Merci pour ces infos, est ce que tu peux nous donner des liens ou tu les as obtenu? (Mis a part le code ;) )
J'ai trouve ça:
http://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSTXGsAndZILs Le 31 oct. 2013 22:44, "Etienne Dechamps" etienne@edechamps.fr a écrit :
On 31/10/2013 14:45, Julien Escario wrote:
Pas besoin de mirroir pour le L2ARC. Par contre en ZIL, les effets de la perte d'un disque non redondé restent toujours de l'ordre de la divination pour moi. Certains disent qu'ils ont perdu des données et les devs du truc disent que ca doit se passer sans problème (mais je vois mal comment). Du coup, je mirorrise.
Pour répondre à tes interrogations : ça dépend à quel moment le SLOG (et non pas le ZIL, qui est un abus de langage ici) foire.
Si le SLOG meurt simplement de lui-même alors que le système est en train de tourner, alors tout ira bien : ZFS va le retirer de la pool et écrire les données en vol du TXG courant dans la pool, ensuite il va ignorer le SLOG et écrire le ZIL sur la pool. Il faut bien comprendre que le ZIL sur disque est toujours une copie du ZIL en RAM, donc ZFS peut sans problème réécrire les données. Donc pas de souci.
En revanche, si le décès du SLOG coïncide avec un arrêt brutal du système (cas typique : le système crashe et le SSD meurt au redémarrage), alors les données qui étaient commitées dans le ZIL mais se trouvant encore dans la TXG en vol au moment de l'arrêt du système (les 5 dernières secondes, en gros) seront définitivement perdues, car ZFS ne peut alors plus se replier sur le ZIL en RAM pour retrouver ses petits.
Il faut également mentionner que du fait de la manière dont ZFS gère les groupes de transactions, qui sont toujours flushés dans l'ordre, le système de fichier présente une propriété intéressante qui est que même avec sync=disabled (c'est-à-dire ZIL désactivé), il est possible de perdre des données, mais il n'y aura pas de corruption à proprement parler - c'est-à-dire que le système revient « proprement » à un moment donné dans le passé (ici la dernière TXG qui est arrivée à temps sur le disque, typiquement 5 secondes en arrière). En d'autres termes, dans les propriétés ACID seul le « D » est affecté, le reste tient toujours. Cela n'est pas vrai pour d'autres systèmes de fichiers tels que ext4.
-- Etienne Dechamps ______________________________**_________________ Liste de diffusion du FRsAG http://www.frsag.org/
On 31/10/2013 22:04, Mehdi Sebbar wrote:
Merci pour ces infos, est ce que tu peux nous donner des liens ou tu les as obtenu? (Mis a part le code ;) )
J'ai trouve ça:
http://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSTXGsAndZILs
Si tu vas voir les sources citées par ton article, tu remarqueras que l'une d'entre elles est en fait un de mes propres messages sur la mailing list de ZFS On Linux, qui fait partie d'un long thread sur le sujet: http://thread.gmane.org/gmane.linux.file-systems.zfs.user/9119/focus=9299 Si tu veux plus de détails, tu devrais lire le thread en question dans lequel moi-même et d'autres personnes débattent du sujet en citant directement le code.
Je vais juste mettre en garde contre une tournure dans l'article qui me semble un peu maladroite :
"If the ZIL is active for a dataset the dataset no longer has strong write ordering properties for data that is not explicitly flushed to disk via fsync() or the like."
Ce paragraphe laisse penser que si on désactive le ZIL alors on obtient subitement des garanties d'ordonnancement même si on n'utilise pas fsync(), ce qui est techniquement faux, principalement parce que rien n'empêche une couche au-dessus de ZFS (au hasard, le sous-système I/O du kernel) de réordonner les écritures lui-mêmes. Même avec le ZIL désactivé il y a toujours un intérêt à utiliser fsync() pour s'assurer que les écritures sont faites dans l'ordre (ce qui est indispensable pour éviter la corruption).
Il y a également une affirmation un peu déroutante : "A filesystem with 'sync=disabled' actually has stronger write ordering guarantees than a filesystem with the ZIL enabled" ce qui théoriquement parlant est vrai, mais pas en pratique puisqu'il faut que fsync() soit correctement utilisé de toute façon. L'article fait un peu du pinaillage à outrance en faisant une fixation sur un comportement un peu exotique de l’ordonnancement des écritures dans le ZIL lorsque ce dernier est activé, alors que cela ne fait aucune différence pratique au niveau des garanties offertes par fsync() (qui est la seule chose qui importe).
J'ai également repéré une erreur :
"A setting of 'disabled' disables ZIL commits but not the in-memory ZIL, which will continue to accumulate records between TXG commits and then drop the records when a TXG commits."
Cette affirmation est tout simplement fausse ; si sync=disabled alors rien n'est gardé en mémoire (et heureusement, sinon ce serait du gaspillage de RAM). Preuve : https://github.com/zfsonlinux/zfs/blob/master/module/zfs/zfs_log.c#L462 https://github.com/zfsonlinux/zfs/blob/master/module/zfs/zil.c#L2195
Le 31 oct. 2013 à 22:44, Etienne Dechamps etienne@edechamps.fr a écrit :
On 31/10/2013 14:45, Julien Escario wrote:
Pas besoin de mirroir pour le L2ARC. Par contre en ZIL, les effets de la perte d'un disque non redondé restent toujours de l'ordre de la divination pour moi. Certains disent qu'ils ont perdu des données et les devs du truc disent que ca doit se passer sans problème (mais je vois mal comment). Du coup, je mirorrise.
Pour répondre à tes interrogations : ça dépend à quel moment le SLOG (et non pas le ZIL, qui est un abus de langage ici) foire.
Si le SLOG meurt simplement de lui-même alors que le système est en train de tourner, alors tout ira bien : ZFS va le retirer de la pool et écrire les données en vol du TXG courant dans la pool, ensuite il va ignorer le SLOG et écrire le ZIL sur la pool. Il faut bien comprendre que le ZIL sur disque est toujours une copie du ZIL en RAM, donc ZFS peut sans problème réécrire les données. Donc pas de souci.
En revanche, si le décès du SLOG coïncide avec un arrêt brutal du système (cas typique : le système crashe et le SSD meurt au redémarrage), alors les données qui étaient commitées dans le ZIL mais se trouvant encore dans la TXG en vol au moment de l'arrêt du système (les 5 dernières secondes, en gros) seront définitivement perdues, car ZFS ne peut alors plus se replier sur le ZIL en RAM pour retrouver ses petits.
Pour cela (entre autre mais aussi pour la perf) qu'il faut porter un soin particulier au choix du SLOG...
Dire que certains utilisent des SSD Intel pour ce faire :-(
Il faut également mentionner que du fait de la manière dont ZFS gère les groupes de transactions, qui sont toujours flushés dans l'ordre, le système de fichier présente une propriété intéressante qui est que même avec sync=disabled (c'est-à-dire ZIL désactivé), il est possible de perdre des données, mais il n'y aura pas de corruption à proprement parler - c'est-à-dire que le système revient « proprement » à un moment donné dans le passé (ici la dernière TXG qui est arrivée à temps sur le disque, typiquement 5 secondes en arrière). En d'autres termes, dans les propriétés ACID seul le « D » est affecté, le reste tient toujours. Cela n'est pas vrai pour d'autres systèmes de fichiers tels que ext4.
Comme la perte de données est inimaginable dans le monde de l'entreprise, je ne conseil jamais de désactiver les ZIL... Les puristes trouvent d'ailleurs cette manip suicidaire et je suis de cet avis.
Ou alors il faut se reposer (donc proprement configurer et tester) sur son onduleur et un outil comme nut pour éteindre le serveur mais ca ne couvre que la cas d'une panne électrique et pas le crash de la machine...
Cordialement, Yacine Kheddache
Bonjour à tous, Le 31 oct. 2013 à 10:51, Laurent Beunèche lb@univ-tours.fr a écrit :
Bonjour à tous, Je souhaite configurer un serveur Dell R720XD avec 12DD de 4To pour qu'il m'exporte en NFS du To dédié à de la sauvegarde. Dans ce cas de figure, je privilégie donc le capacitif plutôt que la performance et je souhaite bénéficier de la compression et déduplication.
Alors avant tout, vérifies bien que ton contrôleur SAS/SATA soit du type JBOD (just a bunch of disk) que du raid, généralement déployé pas défaut sur les Dell.
D'autre part, le ZFS a besoin de : - mémoire : 32Go est le minimum vu ce que tu veux faire - du CPU avec du GT/s élevé.
ZFS me paraît alors approprié (et puis ça m'arrange vu que ça fait un bail que je veux le tester!). Je précise que j'ai 2 DD dédiés pour l'OS.
Après avoir installé le FreeBSD had hoc, je me pose la question de la géométrie du zpool.
FreeBSD 9.2 AMD64 obligatoire, le 9.0 à des GROS BUG EN NFS AVEC ZFS. Testés et approuvé par mon Association.
Dans les Zpool, tu as deux choix : - faire du raidz[1-3] sur tous les disques avec les risques que ca comporte - faire n raidz[1-3]
Je partirais sur la seconde option. Pourquoi ?
Si tu veux changer de disques, type passer de 4To a 5To (le jour ou il sortirons) et que tu n'as pas tout utilisé, l'extension sans faire : sauver tout / refaire le zpool est plus facile.
Ah ne pas oublier : garder des hot spare... C'est *VITAL*.
Autres points : - Pourquoi utiliser 2 fois 4To pour l'OS FreeBSD, ? c'est un peux beaucoup non ? Je crois que les dell on des supports SD en interne. Configurer un FreeBSD avec du MFS en ReadOnly est "assez trivial" pour pouvoir en profiter ? - Attention compression ET dedup = consommation hallucinante en RAM et emmerdes en perspective. J'ai l'habitude d'activer l'un OU l'autre JAMAIS les deux en même temps (surtout sur FreeBSD). J'ai déjà perdu un zpool entier en raidz2 avec ces 2 activés (heureusement j'avais un backup) car j'avais pas assez de RAM (oui 32Go c'était pas suffisant). - Pour pas mettre NexentaStor Community ? C'est plus "facile" de gestion qu'un FreeBSD car des fois si tu n'es pas habitué, les habitudes Linux peuvent te faire perdre du temps (moi ça me gêne pas je suis un habitué de FreeBSD). Et certaines fonctionalités de OpenSolaris ZFS sont pas encore toutes migrées sur FreeBSD.
Pour du log, le simple compress=on fais de beaux miracles, idem avec les backup de vmdk.
Xavier
On Thu, Oct 31, 2013 at 03:25:30PM +0100, Xavier Beaudouin wrote:
Bonjour à tous, Le 31 oct. 2013 à 10:51, Laurent Beunèche lb@univ-tours.fr a écrit :
Bonjour à tous, Je souhaite configurer un serveur Dell R720XD avec 12DD de 4To pour qu'il m'exporte en NFS du To dédié à de la sauvegarde. Dans ce cas de figure, je privilégie donc le capacitif plutôt que la performance et je souhaite bénéficier de la compression et déduplication.
Alors avant tout, vérifies bien que ton contrôleur SAS/SATA soit du type JBOD (just a bunch of disk) que du raid, généralement déployé pas défaut sur les Dell.
D'autre part, le ZFS a besoin de :
- mémoire : 32Go est le minimum vu ce que tu veux faire
- du CPU avec du GT/s élevé.
Merci à tous pour vos réponses. Je n'ai que 16 Go ... Ca va être vraiment juste alors ! Je teste qd même et reviens vers vous pour quelques chiffres.
ZFS me paraît alors approprié (et puis ça m'arrange vu que ça fait un bail que je veux le tester!). Je précise que j'ai 2 DD dédiés pour l'OS.
Après avoir installé le FreeBSD had hoc, je me pose la question de la géométrie du zpool.
FreeBSD 9.2 AMD64 obligatoire, le 9.0 à des GROS BUG EN NFS AVEC ZFS. Testés et approuvé par mon Association.
Dans les Zpool, tu as deux choix :
- faire du raidz[1-3] sur tous les disques avec les risques que ca comporte
- faire n raidz[1-3]
Je partirais sur la seconde option. Pourquoi ?
Si tu veux changer de disques, type passer de 4To a 5To (le jour ou il sortirons) et que tu n'as pas tout utilisé, l'extension sans faire : sauver tout / refaire le zpool est plus facile.
Ah ne pas oublier : garder des hot spare... C'est *VITAL*.
Autres points :
- Pourquoi utiliser 2 fois 4To pour l'OS FreeBSD, ? c'est un peux beaucoup non ? Je crois que les dell on des supports SD en interne. Configurer un FreeBSD avec du MFS en ReadOnly est "assez trivial" pour pouvoir en profiter ?
Les disques pour l'OS sont des 300G SAS, j'ai de la place et des perfs pour en faire autre chose d'ailleurs.
- Attention compression ET dedup = consommation hallucinante en RAM et emmerdes en perspective. J'ai l'habitude d'activer l'un OU l'autre JAMAIS les deux en même temps (surtout sur FreeBSD). J'ai déjà perdu un zpool entier en raidz2 avec ces 2 activés (heureusement j'avais un backup) car j'avais pas assez de RAM (oui 32Go c'était pas suffisant).
- Pour pas mettre NexentaStor Community ? C'est plus "facile" de gestion qu'un FreeBSD car des fois si tu n'es pas habitué, les habitudes Linux peuvent te faire perdre du temps (moi ça me gêne pas je suis un habitué de FreeBSD). Et certaines fonctionalités de OpenSolaris ZFS sont pas encore toutes migrées sur FreeBSD.
Pour du log, le simple compress=on fais de beaux miracles, idem avec les backup de vmdk.
Ma config actuelle : --- root@vlscc:~ # zpool list vlscc NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT vlscc 36.2T 223K 36.2T 0% 1.00x ONLINE -
root@vlscc:/tmp # zpool status vlscc pool: vlscc state: ONLINE scan: none requested config:
NAME STATE READ WRITE CKSUM vlscc ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 label/disk1 ONLINE 0 0 0 label/disk2 ONLINE 0 0 0 label/disk3 ONLINE 0 0 0 label/disk4 ONLINE 0 0 0 label/disk5 ONLINE 0 0 0 raidz1-1 ONLINE 0 0 0 label/disk6 ONLINE 0 0 0 label/disk7 ONLINE 0 0 0 label/disk8 ONLINE 0 0 0 label/disk9 ONLINE 0 0 0 label/disk10 ONLINE 0 0 0 spares label/disk11 AVAIL label/disk12 AVAIL
root@vlscc:~ # df -h Filesystem Size Used Avail Capacity Mounted on vlscc 28T 46k 28T 0% /vlscc
---
Question : Je fais du 2 x raidz1, je perd l'équivalent de 4 dd. Faire du z2 avec 2 spares, je perds l'équivalent de 6 disques, ça fait bcp là non ?! :) root@vlscc:~ # df -h Filesystem Size Used Avail Capacity Mounted on vlscc 21T 50k 21T 0% /vlscc
Xavier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
2013/10/31 Laurent Beunèche lb@univ-tours.fr:
Question : Je fais du 2 x raidz1, je perd l'équivalent de 4 dd. Faire du z2 avec 2 spares, je perds l'équivalent de 6 disques, ça fait bcp là non ?! :) root@vlscc:~ # df -h Filesystem Size Used Avail Capacity Mounted on vlscc 21T 50k 21T 0% /vlscc
Sur du raidz2, je pense que tu peux raisonnablement ne pas avoir de spare. Et donc, perdre "seulement" les 4 disques de parités.
Bonjour,
Dans les Zpool, tu as deux choix :
- faire du raidz[1-3] sur tous les disques avec les risques que ca comporte
- faire n raidz[1-3]
Je partirais sur la seconde option. Pourquoi ?
Si tu veux changer de disques, type passer de 4To a 5To (le jour ou il sortirons) et que tu n'as pas tout utilisé, l'extension sans faire : sauver tout / refaire le zpool est plus facile.
Sur nos systèmes (Solaris et Sun X4540) on a fait l'extension à chaud (passage de disques de 500 Go à 2To en 2010) et ça c'est plutôt bien passé. Notez que j'ignore comment ça pourrait fonctionner avec le couple FreeBSD et DELL R720.
@+,
Olivier.
-
Cyrille Verger -
Etienne Dechamps -
Florent Rivoire -
Gilles Mocellin -
Guillaume Friloux -
Julien Escario -
Laurent Beunèche -
Mathieu Arnold -
Mehdi Sebbar -
Olivier DELHOMME -
Olivier Doucet -
piti -
Sylvain Rochet -
Xavier Beaudouin -
Yacine Kheddache