ZFS comme son nom ne l'indique pas n'est pas juste un système de fichiers. Plus je l'utilise plus je dirais même que le système de fichiers n'est qu'une des fonctionnalités sympa de ZFS. ZFS est avant tout un moyen d'organiser de façon efficace ses ressources de stockage, une sorte de carte RAID surpuissante.
NDA : merci à Nicolas Casanova, Tonton Th, NeoX, Jiehong, jcr83 et ZeroHeure pour leur relecture attentive
Sommaire
Histoire d'une libération
L'histoire dit que Jeff Bonwick aurait commencé à développer ZFS en 2001, mais il faudra attendre le début de l'année 2005 et Solaris 10 pour pouvoir en profiter.
Solaris 10, c'est aussi la libération du code sous licence CDDL et l'écosystème OpenSolaris qui, depuis le rachat de Sun par Oracle, se fédère autour du projet Illumos avec des distributions comme OpenIndiana, SmartOS ou NexentaStor.
La licence CDDL est un dérivé de la licence MPL reconnue comme libre par la FSF et OpenSource par l'OSI. Hélas elle est à la fois incompatible avec la GPL et la licence BSD. C'est pour cela entre autre que ZFS ne peut pas être compilé en dur dans le noyau FreeBSD mais doit être chargé sous forme d'un module externe.
Oracle ne publiant plus de versions OpenSource, des développeurs d'Illumos, de FreeBSD, de ZFS on Linux et de ZFS OSX, mais également de nombreuses entreprises ont fondé en septembre 2013 le projet OpenZFS, visant à poursuivre et coordonner le développement du système de fichier.
Le premier changement fut que les numéros de version furent abandonnés au profit des feature flags (masque permettant de savoir si telle ou telle fonctionnalité est supportée). Ainsi sous FreeBSD on est passé de la version 28 à la version 5000 !
Le projet travaille sur la qualité du code et en particulier les tests, la portabilité ainsi que les futures fonctionnalités.
Autre fait marquant dans l'actualité de ZFS, le 28 mars 2013 le projet ZFS on Linux a publié sa première version stable, ce qui semble faire de ZFS le système de fichier le plus largement géré depuis le vFAT (ou presque).
ZFS est en effet aujourd'hui porté sous :
- Solaris
- IllumOS et ses dérivés
- FreeBSD
- NetBSD
- Linux
- Mac OSX
À noter que son architecture d'origine (Solaris Sparc / Solaris x86), lui a permis d'être insensible aux problèmes de boutisme (Endianness).
Zpool
Un zpool est une entité qui regroupe des ressources matérielles telles que des disques, de la mémoire, des périphériques d'échange rapide (SSD entre autres). La commande homonyme sert à contrôler le tout.
Des disques
Les disques servent au stockage des données. Ils peuvent être configurés en miroir (raid 1) en stripe (raid 0) ou en raid Z{2,3} (variante autour du raid5/6) comportant un nombre plus ou moins grand de disques de parité (1 pour le raidZ, 2 pour le raidZ2, 3 pour le raidZ3).
Par exemple, pour créer l'équivalent d'un raid10, on agrège deux miroirs :
root@host:~# zpool create storage mirror da0 da1 mirror da2 da3
root@host:~# zpool status storage
pool: storage
state: ONLINE
scan: resilvered 481G in 7h50m with 0 errors on Mon Oct 14 19:07:10 2013
config:
NAME STATE READ WRITE CKSUM
storage ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
da0 ONLINE 0 0 0
da1 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
da2 ONLINE 0 0 0
da3 ONLINE 0 0 0On notera que le stripe est implicite. Autre exemple, un raidZ3 :
root@host:~# zpool create nfs raidz3 c4t0d0 c4t1d0 c4t2d0 c4t3d0 c4t4d0 c4t5d0 c4t6d0 c4t7d0 c4t8d0 c4t9d0 c4t10d0 c4t11d0 c4t12d0 c4t13d0 c4t14d0 c4t15d0 c4t16d0 c4t17d0 c4t18d0 c4t19d0 c4t20d0 c4t21d0 c4t22d0
root@host:~# zpool status nfs
pool: nfs
state: ONLINE
scan: resilvered 314G in 34h30m with 0 errors on Thu Dec 12 22:50:17 2013
config:
NAME STATE READ WRITE CKSUM
nfs ONLINE 0 0 0
raidz3-0 ONLINE 0 0 0
c4t0d0 ONLINE 0 0 0
c4t1d0 ONLINE 0 0 0
c4t2d0 ONLINE 0 0 0
c4t3d0 ONLINE 0 0 0
c4t4d0 ONLINE 0 0 0
c4t5d0 ONLINE 0 0 0
c4t6d0 ONLINE 0 0 0
c4t7d0 ONLINE 0 0 0
c4t8d0 ONLINE 0 0 0
c4t9d0 ONLINE 0 0 0
c4t10d0 ONLINE 0 0 0
c4t11d0 ONLINE 0 0 0
c4t12d0 ONLINE 0 0 0
c4t13d0 ONLINE 0 0 0
c4t14d0 ONLINE 0 0 0
c4t15d0 ONLINE 0 0 0
c4t16d0 ONLINE 0 0 0
c4t17d0 ONLINE 0 0 0
c4t18d0 ONLINE 0 0 0
c4t19d0 ONLINE 0 0 0
c4t20d0 ONLINE 0 0 0
c4t21d0 ONLINE 0 0 0
c4t22d0 ONLINE 0 0 0Un disque peut également être configuré en HotSpare pour remplacer à la volée un disque défaillant :
zpool add tank spare ada12Il est déconseillé d'utiliser ZFS au dessus d'un RAID matériel. Autant que faire se peut, on configurera ses disques en JBOD ou idéalement pass-through. Il y a deux raisons à cela.
Tout d'abord ZFS est conçu pour utiliser le cache des disques. En empilant une autre couche de cache (celle du contrôleur RAID) on risque de dégrader fortement les performances.
Mais surtout, le RAID matériel étant vu comme un disque unique, on risque de priver ZFS de toute redondance au niveau des données et donc de le priver de tout moyen de se réparer en cas d'incohérence.
Un RAID matériel sera donc dans la plupart des cas au mieux nuisible et au pire dangereux. En production, un zpool a besoin de redondance. Sinon, il n'offre aucune sécurité.
Le seul point pour lequel un contrôleur RAID est intéressant est la présence d'une BBU (batterie de secours permettant d'éteindre les disques proprement en cas de crash) qui permet d'avoir une stratégie d'IO plus agressive. Nous y reviendrons.
Dans la plupart des cas, un contrôleur SATA ou SAS basique fera très bien l'affaire, voire, si on souhaite un grand nombre de disques, un HBA standard couplé à des boîtiers JBOD.
Toujours au niveau performance, penser à activer la commande TRIM lorsqu'elle est disponible — comme par exemple sous FreeBSD avec le pilote ada — car elle permet d'indiquer aux périphériques de type SSD quels blocs ne sont plus utilisés et ainsi d'optimiser leurs performances.
Enfin, sachez que si vos disques présentent quasiment tout le temps des secteurs de 512 octets, ils gèrent en réalité 4k ou 8k. Aligner le zpool sur cette taille permet d'éviter beaucoup d'opérations de copie en mémoire et donc d'accélérer considérablement les performances. Généralement, avec des disques récents, on ne se pose pas de questions et on part sur 4k.
Pour ce faire, il faut positionner correctement la propriété ashift au moment de la création du zpool. Il s'agit du logarithme en base 2 de la taille des secteurs. Ainsi 2ashift est la plus petite IO possible sur le périphérique.
Il faudra utiliser :
- le pseudo device gnop sous FreeBSD ;
- sd.conf sous Illumos ;
- Et l'option -o ashift=12 à la commande zpool sous Linux.
Cette dernière méthode devrait se généraliser.
Pour retrouver l'ashift utilisé, on utilise la commande zdb :
zdb tank | grep ashiftCommandes pour survivre
Maintenant que nous avons un zpool avec de beaux disques, il faut le garder en vie.
Configuration
A l'image des cartes RAID, ZFS stocke sa configuration directement sur les disques sous formes de métadonnées y compris les points de montage.
Il est toutefois possible de la sauvegarder en copiant le fichier défini par la propriété cachefile. Ce fichier contient une image de la configuration trouvée sur les disques et détectée par ZFS à l'initialisation.
Cette configuration est portable. Ainsi un zpool créé depuis un liveCD peut très bien être réutilisé par la suite par un autre système. C'est ce qu'on fait généralement lorsqu'on veut utiliser ZFS pour sa partition racine.
On marque le pool comme libéré :
zpool export poolOn peut ensuite le réimporter :
zpool import poolSi on a sauvegardé le cachefile :
zpool import pool -c /path/to/cachefileMaintenance
Au niveau des diagnostics, la commandes de base est zpool status, qui affiche l'état des différents périphériques ainsi que l'état de cohérence du pool, et un résumé des dernières erreurs.
zpool iostat permet de monitorer l'activité en live :
zpool iostat nfs 1 10
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
nfs 6,24T 14,6T 145 91 2,39M 4,15M
nfs 6,24T 14,6T 108 43 13,6M 115K
nfs 6,24T 14,6T 334 0 41,8M 0
nfs 6,24T 14,6T 526 0 65,5M 0
nfs 6,24T 14,6T 510 233 63,8M 28,3M
nfs 6,24T 14,6T 511 718 63,9M 69,7M
nfs 6,24T 14,6T 579 0 72,5M 0
nfs 6,24T 14,6T 698 0 87,3M 0
nfs 6,24T 14,6T 443 0 55,3M 0
nfs 6,24T 14,6T 579 0 72,5M 0zpool scrub permet de lancer une vérification exhaustive des données. Contrairement au fsck, le scrub peut être effectué à chaud.
On peut bien entendu remplacer un disque, le mettre offline ou online :
zpool replace tank sda sdb
zpool offline tank c1t3d0
zpool online tank c1t3d0
zpool replace tank c1t3d0
L'ensemble des propriétés du pool s'obtient avec zpool get all, zdb donne des informations de debug et de cohérence et enfin zpool history retrace les événements survenus.
zpool history
2013-12-11.10:36:15 zpool offline nfs c4t22d0
2013-12-11.12:17:25 zpool replace -f nfs c4t22d0 c4t22d0
2012-09-19.16:05:03 zpool create -f rpool c3t0d0s0
2012-09-19.16:09:57 zpool set bootfs=rpool/ROOT/openindiana rpool
2012-09-19.17:31:58 zpool upgrade rpoolLe cache
Si on cherche des performances, il est important de donner à notre zpool de quoi gérer du cache, autrement dit de la mémoire et des SSD.
Le premier niveau de cache réside en mémoire. Il utilise une variante de l'algorithme Adaptive Replacement Cache développé et breveté par IBM.
Par défaut, ZFS va utiliser jusqu'à 75% de la mémoire pour les systèmes ayant moins de 4 Gio et toute la mémoire moins 1 Gio pour les autres. Il est conseillé de limiter cet usage si on a besoin de mémoire par ailleurs (par exemple pour un SGBD). Il faut en particulier faire attention avec l'hyperviseur Xen à bien limiter le arc_max_size à 80% de la mémoire de l'hyperviseur et non à celle de la machine.
Cela se fait via sysctl sous FreeBSD, dans /etc/system sous Solaris, dans /etc/modprobe.d/zfs.conf sous Linux.
Lorsqu'on vise les performances, une bonne formule est 8 Gio + 1 à 2 Gio par Tio. Ceci dit on peut être bien plus modeste suivant le contexte. Pour de l'archivage de log ou des backups par exemple inutile de mettre autant de RAM. Dans tous les cas avec moins de 4 Gio de RAM votre machine ne sera pas taillée pour les performances. ZFS désactive un tas de choses dans ce cas et en particulier le prefetch.
Bien évidemment 1 Gio par Tio c'est bien jusqu'à une certaine limite et suivant les volumes à stocker, cela peut rapidement devenir irréaliste. Heureusement ZFS possède un second niveau de cache, le L2ARC, qui utilise du stockage rapide comme par exemple des SSD.
zpool add storage cache ada1Pour connaître l'état de fonctionnement du cache ARC il faut regarder les variables du noyau avec l'outil approprié (kstat, sysctl, /proc fu), soit par le biais d'un script tel que arcstat.pl (Solaris) ou sysutils/zfs-stats (FreeBSD).
Il existe trois types de cache (tout, rien, uniquement les métadonnées). Mais cette configuration se fait plutôt suivant l'usage par volume.
Gestion des écritures synchrones
Les développeurs sont des gens bien gentils, mais s'ils pouvaient arrêter d'ouvrir leurs fichiers avec le flag O_FSYNC à tout bout de champ, cela arrangerait tout le monde. Ce flag indique en effet que les écritures ayant lieu sur ce descripteur de fichier ne doivent être acquittées que lorsque l'ensemble des données sont effectivement écrites sur le disque, ce qui est globalement lent.
Pour pallier ce problème, on peut ajouter au zpool un périphérique tampon chargé d'accélérer les écritures synchrones. Le ZFS Intent Log (ZIL) stockera de façon temporaire et sécurisée les données à écrire, permettant un acquittement précoce sans pour autant sacrifier la cohérence et la sécurité. Par exemple on peut utiliser deux disques SSD en miroir :
zpool tank add log mirror ada12 ada13Il est également possible d'utiliser le ZIL pour toutes les écritures en désactivant le mécanisme d'écriture asynchrone (writeback). À moins d'avoir un périphérique magique, cela devrait être plus lent mais peut toutefois être une option si on ne veut pas perdre de transactions lors d'un arrêt brutal. On peut également faire plus rapide et moins sûr à condition d'avoir du matériel secouru par BBU (battery backup unit). Mais cela se configure alors volume par volume et non plus au niveau du zpool.
Les volumes
Une fois notre pool opérationnel, on peut l'utiliser pour créer des volumes. Il en existe deux sortes :
- les zvols, qu'on peut utiliser comme un périphérique de bloc quelconque ;
- les datasets, qui contiennent un système de fichier ZFS et qu'on peut monter où bon nous semble.
En fait ce sont les mêmes, à quelques propriétés près.
Pour un dataset :
zfs create -o mountpoint=/var tank/varOn peut ensuite créer des sous volumes :
for i in log spool tmp empty lib; do
zfs create tank/var/$i
doneEnfin, on peut donner les propriétés qu'on souhaite :
zfs set exec=off tank/var/tmp
zfs set refquota=10G tank/var/log
zfs set sharenfs=on tank/isosPour un volume, il suffit de spécifier la propriété volumesize :
zfs create -V 8G tank/swapLe volume est alors accessible dans /dev/zvol/tank/swap :
mkswap /dev/zvol/tank/swap
swapon /dev/zvol/tank/swapOn peut aussi faire du thin-provisionning :
zfs create -s -V 100G tank/vm-01-data
zfs set shareiscsi=on tank/vm-01-dataComme on le voit, il est très simple de manipuler tout cela.
Propriétés
La commande zfs permet de manipuler les propriétés des zvols et des datasets telles que :
- la gestion des ACL POSIX :
aclinherit=discard | noallow | restricted | passthrough
aclmode=discard | groupmask | passthrough | restricted- les options de montage traditionnelles :
canmount=on | off | noauto
mountpoint=path | none | legacy
exec=on | off
readonly=on | off
setuid=on | off
atime=on | off- un certain nombre d'options concernant la façon de stocker les données :
checksum=on | off | fletcher2 | fletcher4 | sha256 | noparity
compression=on | off | lzjb | gzip | gzip-N | zle | lz4
dedup=on | off | verify | sha256[,verify]Il est à noter que la déduplication a un effet certain sur les performances. Pour l'heure, l'utilisation des clones reste la meilleure façon de partager les mêmes données entre différents utilisateurs.
Le taux de compression est donné par la propriété compressratio du dataset ou du volume. Le taux de déduplication apparaîtra lui dans les propriétés du zpool.
Ici, l'outil zdb est également très utile. zdb -c vérifiera l'ensemble des sommes de contrôle, zdb -D donnera des informations détaillées sur la déduplication, la compression et notamment le ratio dedup x compress / copies qui correspond au taux effectif de place gagné. On y trouvera notamment :
- le type de cache :
primarycache=all | none | metadata
secondarycache=all | none | metadataLe cache metadata est particulièrement utile pour les systèmes de backup qui comparent les métadonnées des fichiers sources et destination (rsync : building filelist). Désactiver complètement le cache ne présente pas à ma connaissance d’intérêt si ce n'est celui d'éviter dans certains cas précis les effets de double cache.
- les quotas utilisateurs :
userquota@user=size | none
groupquota@group=size | none- la taille du volume.
Si pour un zvol la taille est fixée une fois pour toute à la création (volsize), celle d'un dataset peut être décidée de façon plus flexible. Par défaut, un dataset n'est limité que par la taille du zpool.
On peut toutefois très bien fixer sa taille maximale avec la propriété quota (qui inclut les descendants et les snapshots) ou refquota (qui n'inclut aucun descendant). On peut également lui réserver de l'espace (reservation et refreservation). Enfin — et ce peut être intéressant en particulier avec des SGBD — on pourra modifier la taille des enregistrements (recordsize).
- méthode de synchronisation :
sync=standard | always | disabledstandard correspond au mécanisme de writeback par défaut, always traite toutes les écritures comme synchrones (utilisation massive du ZIL s'il existe). disabled nécessite un matériel secours par des batteries (BBU) mais augmente considérablement les performances. À ce propos, il est à noter qu'il ne suffit pas qu'il y ait une BBU pour qu'elle fonctionne. Il s'agit d'un dispositif chimique globalement aussi fiable qu'une batterie de téléphone. sync=disable signifiant qu'en cas d'arrêt brutal votre système de fichiers sera tout simplement mort, la supervision des BBU et des tests de fonctionnement réguliers sont le moindre des préalables.
- et d'autres.
Les nostalgiques pourront créer des systèmes de fichiers insensibles à la casse (casesensitivity=insensitive), ou plus intéressant : s'assurer que tous les noms de fichiers sont écrits en UTF-8 (utf8only=on). La propriété copies placée à 2 ou 3 (1 par défaut) assurera qu'il existe plusieurs copies des données, indépendamment du raid sous-jacent. snapdir=visible permettra de naviguer dans les snapshots à partir d'un dossier .snap à la racine du dataset et jailed/zoned de savoir si le dataset a été délégué à un container de type jail ou zone. Enfin, la commande zfs permet aussi de paramétrer les partages réseaux :
sharesmb=on | off | opts
sharenfs=on | off | opts
shareiscsi=on | off | optsMais soyons francs, on ne choisit pas un FS parce qu'il nous évite l'édition de /etc/exports.
Les captures
Nous avons vu que dans un zpool on peut créer deux types de ressources : des volumes et des datasets. Il en existe une troisième, les snapshots. Un snapshot correspond à l'état figé d'un volume ou un dataset à un instant t. Leur prise est très rapide et aussi simple qu’utile :
- sauvegarde à chaud ;
- rollback après une mise à jour ;
- clonage ;
- rotation des backups ;
- …
zfs snapshot pool/volume@nom_du_snapshotL'espace utilisé sur un zpool par les différents éléments est souvent un peu complexe à déterminer :
zfs list -o space
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
tank 111G 322G 0 151G 0 171G
tank/apache 111G 32K 0 32K 0 0
tank/joris 111G 165G 0 165G 0 0
tank/local 111G 4,44G 0 4,44G 0 0
tank/poudriere 111G 1,60G 0 33K 0 1,60G
...L'usage global est la somme de quatre valeurs :
- l'espace utilisé par les snapshots ;
- l'espace utilisé par le dataset ;
- l'espace réservé ;
- et enfin l'espace utilisé par les sous-volumes.
Pour comprendre le poids des snapshots, prenons un exemple. Créons un dataset et deux fichiers de 20Mio :
zfs create tank/linuxfr
dd if=/dev/zero of=/home/linuxfr/1 bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes transferred in 0.028457 secs (736950437 bytes/sec)
dd if=/dev/zero of=/home/linuxfr/2 bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes transferred in 0.028432 secs (737599308 bytes/sec)Cela nous donne :
zfs list -o space tank/linuxfr
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
tank/linuxfr 111G 40,0M 0 40,0M 0 0Si maintenant on prend un snapshot :
zfs snapshot tank/linuxfr@1
zfs list -o space -t all | egrep 'linuxfr|USED'
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
tank/linuxfr 111G 40,0M 0 40,0M 0 0
tank/linuxfr@1 - 0 - - - -Le snapshot ne fait aucun poids dans la mesure où les données sont les mêmes dans le snapshot et dans le dataset.
Si on supprime mon fichier 1 :
zfs list -o space -t all | egrep 'linuxfr|USED'
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
tank/linuxfr 111G 40,1M 20,0M 20,0M 0 0
tank/linuxfr@1 - 20,0M - - - -
-20 Mio ont basculé du USEDDS vers USEDSNAP. La taille d'un snapshot est égale au différentiel de données entre le dataset et le snapshot. Plus le snapshot sera ancien, plus l'espace qu'il occupe sera significatif.
Maintenant, imaginons qu'on ait détruit le fichier 1. On peut le retrouver simplement :
zfs rollback tank/linuxfr@1Mais dans ce cas, tout autre modification sera perdue. Il est possible de remonter le snapshot ailleurs en faisant un clone :
zfs clone tank/linuxfr@1 tank/linuxfr_rescue
zfs list -t all | grep linuxfr
tank/linuxfr 40,1M 111G 20,0M /home/linuxfr
tank/linuxfr@1 20,0M - 40,0M -
tank/linuxfr_rescue 1K 111G 40,0M /home/linuxfr_rescueOn peut maintenant récupérer notre fichier dans /home/linuxfr_rescue sans écraser /home/linuxfr. Si maintenant on décide de remplacer tank/linuxfr par son clone, il nous faudra promouvoir celui-ci.
Observons :
zfs destroy tank/linuxfr
cannot destroy 'tank/linuxfr': filesystem has children
use '-r' to destroy the following datasets:
tank/linuxfr@1tank/linuxfr ne peut être détruit sans détruire tank/linuxfr@1 :
zfs destroy tank/linuxfr@1
cannot destroy 'tank/linuxfr@1': snapshot has dépendent clones
use '-R' to destroy the following datasets:
tank/linuxfr_rescuetank/linuxfr@1 ne peut être détruit sans détruire tank/linuxfr_rescue :
Promouvons …
zfs promote tank/linuxfr_rescue
zfs list -t all | grep linuxfr
tank/linuxfr 20K 111G 20,0M /home/linuxfr
tank/linuxfr_rescue 40,0M 111G 40,0M /home/linuxfr_rescue
tank/linuxfr_rescue@1 1K - 40,0MLe snapshot tank/linuxfr@1 est devenu tank/linuxfr_rescue@1. En général la suite logique est :
zfs destroy tank/linuxfr
zfs rename tank/linuxfr_rescue tank/linuxfr
zfs list -t all | grep linuxfr
tank/linuxfr 40,0M 111G 40,0M /home/linuxfr
tank/linuxfr@1 1K - 40,0M -Un clone n'est pas un système de fichier indépendant. Il hérite de la même lignée de snapshot que le volume dont il est issu.
Savoir recevoir
Pour dupliquer réellement un volume, il faut utiliser send/receive
zfs snapshot tank/linuxfr@1
zfs send tank/linuxfr@1 | zfs receive tank/linuxfr2
zfs list -t all | grep linuxfr
tank/linuxfr 20,0M 111G 20,0M /home/linuxfr
tank/linuxfr@1 0 - 20,0M -
tank/linuxfr2 20,0M 111G 20,0M /home/linuxfr2
tank/linuxfr2@1 0 - 20,0M -ici contrairement au clone, tank/linuxfr et tank/linuxfr2 sont deux dataset totalement indépendants .
On peut vouloir les garder synchronisés. Pour cela on peut faire des send incrémentaux.
dd if=/dev/zero of=/home/linuxfr/3 bs=1M count=20
zfs snapshot tank/linuxfr@2
zfs send -i tank/linuxfr@1 tank/linuxfr@2 | zfs receive tank/linuxfr2On n'envoie que la différence entre les deux snapshots soit 20 Mio. Pour savoir si un dataset a besoin d'être resynchronisé, on peut regarder la propriété written
zfs get written tank/linuxfr
NAME PROPERTY VALUE SOURCE
tank/linuxfr written 0
dd if=/dev/zero of=/home/linuxfr/4 bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes transferred in 0.028963 secs (724077463 bytes/sec)
zfs get written tank/linuxfr
NAME PROPERTY VALUE SOURCE
tank/linuxfr written 20,0M -
zfs snapshot tank/linuxfr@3
zfs send -v -i tank/linuxfr@2 tank/linuxfr@3 | zfs receive tank/linuxfr2
send from @2 to tank/linuxfr@3 estimated size is 20,0M
total estimated size is 20,0M
TIME SENT SNAPSHOTBien évidemment, vu qu'on passe par un pipe on peut faire des trucs sympas, comme synchroniser une machine distante :
zfs send -v -i tank/linuxfr@2 tank/linuxfr@3 | ssh machine2 zfs receive tank/linuxfrOu dans une version plus élaborée
zfs send -i tank/linuxfr@2 tank/linuxfr@3 | pv -L 1m --quiet | ssh -c blowfish -i .ssh/replication_dsa zfs receive tank/linuxfrEt là, on tient le Graal :) ou presque… En effet, souvent lorsqu'on cherche à répliquer un volume sur une machine distante, c'est que la machine principale va mal. Pour l'heure l'opération peut être laborieuse, puisqu'en cas de plantage il faudra tout reprendre depuis le début. Heureusement la possibilité de reprendre un send / receive interrompu est dans les objectifs du projet OpenZFS.
Réplication et haute dispo
Utiliser Send / Receive pour assurer la disponibilité des données lors du crash d'une machine est une idée tentante ; c'est par exemple ce que fait hybridcluster.com avec une plate-forme certes propriétaire mais largement documentée. Il s'agit de mettre en place un démon monitorant l'état des datasets au travers par exemple de l'interface dtrace et de déclencher la réplication afin de maintenir un jeu de datasets passifs aussi proche que possible de l'original. Il faut toutefois bien comprendre que ce type de réplication est forcément asynchrone et que sur une plate-forme à forte densité d'écriture la perte de données en cas de bascule est inévitable.
Pour l'heure les logiciels gérant la synchronisation de volumes au sein d'un parc sont souvent des scripts shells manquant de robustesse ou d'intelligence. L'un des obstacles à l'écriture de logiciels plus avancés est l'obligation de passer par l’exécution de commandes shell. Il existe bien une libzfs et une libzpool, mais ce sont des bibliothèques privées sans interface fixe. La libzfs_core devrait résoudre se problème.
En pratique la consolidation des données au travers du réseau à base de Send / Receive fonctionne plutôt bien à condition d'en accepter les limites.
Si on cherche une vraie solution de haute disponibilité libre, il faudra se tourner vers les outils classiques tels que les couches de réplication temps réel en mode bloc des systèmes sous-jacents (DRBD pour Linux, HAST, pour FreeBSD) couplé par exemple à du VRRP ou encore un système de fichier distribué comme GlusterFS.
Si par contre on tolère du propriétaire, on pourra faire appel à RSF-1. C'est la solution généralement retenue par les marchands d'appliances.
Tout cela pour dire que finalement ZFS n'est pas un système de fichier distribué et n'a pas la prétention de l'être. Ceci dit, vu ses capacités de redondance et sa flexibilité, on peut parier que la question devrait en exciter plus d'un.
Conclusion
Pour conclure, un peu de poésie dans ce monde de brutes :
wget http://archive.zfsonlinux.org/debian/pool/main/z/zfsonlinux/zfsonlinux_2%7Ewheezy_all.deb
dpkg -i zfsonlinux_2~wheezy_all.deb
apt-get update
apt-get install debian-zfsEt hop ! zfs dans ta Debian :-)
Aller plus loin
- OpenZFS (350 clics)
- ZFS sur wikipedia (511 clics)
- ZFS sur le wiki de FreeBSD (60 clics)
- ZFS on Linux (139 clics)
- Illumos (64 clics)
- Le ZFS Evil Tuning Guide (122 clics)
# Utilisation en production ?
Posté par 0xfg . Évalué à 6.
Est-ce qu'il y a des gens qui utilise ZFS en prod sur des systèmes critiques ? Est-ce que l'on peut considérer ZFS suffisamment stable et mature ?
Au passage, l'article est super bien écrit !
[^] # Re: Utilisation en production ?
Posté par Loïc Blot (site web personnel) . Évalué à 7.
J'utilise personnellement ZFS pour stocker les données de mon infrastructure web sur un serveur en NFS + ZFS, c'est robuste. Le FS a déjà résisté sans perte à une coupure électrique inattendue.
Il y a quelques années on pouvait douter du FS, mais depuis 1 ou 2 ans les différents supporters du FS ont beaucoup amélioré la qualité du code et corrigé énormément de problèmes rencontrés. Je pense qu'on pourrait dire que ZFS est désormais devenu suffisamment mature pour la production
Veepee & UNIX-Experience
[^] # Re: Utilisation en production ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Quand on voit qu'il faut un article aussi long pour décrire le fonctionnement d'un FS. Cela me fait très peur :)
D'ailleurs, le titre avait l'air de parler de hardware. J'imagine qu'il devrait être possible de faire un contrôleur hardware qui automatise une partie des traitements de ZFS.
Dans ce que l'on appelle les "grands systèmes", style GCOS chez Bull, la grosse différence par rapport à un microordinateur, est l'usage de carte d'IO qui s’interroge presque comme une base de donnés, et qui donne des performances qui n'ont rien à voir avec un PC.
"La première sécurité est la liberté"
[^] # Re: Utilisation en production ?
Posté par Zenitram (site web personnel) . Évalué à 10.
Bah, le RAID "Hardware" est surtout du software mis dans un CPU même plus trop dédié + RAM dédié, donc tant qu'à faire autant que ce soit sur le CPU principal et profiter de la mutualisation non?
Le RAID "Hardware" avait une super réputaiton, mais de nos jours je le vois de plus en plus critiqué et je lis de plus en plus "prenez la gestion RAID de Linux".
[^] # Re: Utilisation en production ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Cela a un sens pour les serveurs de fichiers, mais est-ce toujours vrai pour les serveurs qui font plus que ça ?
"La première sécurité est la liberté"
[^] # Re: Utilisation en production ?
Posté par Kaane . Évalué à 4.
Bah, le RAID "Hardware" est surtout du software mis dans un CPU même plus trop dédié + RAM dédié, donc tant qu'à faire autant que ce soit sur le CPU principal et profiter de la mutualisation non?
Le RAID "Hardware" avait une super réputaiton, mais de nos jours je le vois de plus en plus critiqué et je lis de plus en plus "prenez la gestion RAID de Linux".
Ca c'est vrai pour l'entrée de gamme qui prétend faire du raid mais qui délègue 80% du boulot à l'hôte.
Sur de la carte un peu plus costaud ca n'est plus vrai du tout, notamment au niveau des I/Os. Mais bon il faut compter entre 100€ et 200€ du canal pour avoir un produit convenable.
[^] # Re: Utilisation en production ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Je ne pensais pas spécialement aux "adaptateurs", je parlais de CPU et RAM sur la carte.
Ca veut dire pouvoir mettre, allez partons sur un 2U à 12 disques, sur 1200 à 2400 € de plus à mettre en CPU, RAM…
Ce qui n'est pas négligeable (en plus d'être plus généraliste suivant les ressources necessaires à un instant donné, ou juste pourvoir faire du RAID-Z3 ou juste vouloir un vrai Copy On Write)
Est-ce que la carte chère est alors plus performante? a bencher… Je ne suis pas sûr que le RAID Hardware soit plus performant (et souple!) de nos jours, mais plutôt qu'il profite de son aura d'il y a quelques années quand c'était vriament bien plus performant dans tous les cas.
[^] # Re: Utilisation en production ?
Posté par Kaane . Évalué à 7.
Je ne suis pas sûr que le RAID Hardware soit plus performant (et souple!) de nos jours
Sur le SAS rien que l'économie sur les opérations de sync, le cache énorme des cartes haut de gamme et le map des blocks par la carte approtent un gain de perfs assez violent par rapport à tout ce qui peut se faire en software, le tout pour une occupation CPU bien moindre, notamment sur tout ce qui va être mirroring ou fonctionnement dégradé (RAID 6 software avec un disque en panne… Ca pique)
Après au niveau flexibilité c'est clair que pour avoir quelque chose de comparable à la versatilité du RAID soft il faut mettre le prix. Mais généralement quand tu pars sur 6 ou 7000€ de matos pour avoir du raid hard (carte+disques+enclosure/backplane) tu sais ce que tu veux et tu ne t'amuses pas trop à changer la config ou à agrandir/réduire des disques toutes les 48h.
Après si tu veux vraiment la flexibilité ultime tu vas vite partir sur du iSCSI avec des baies dédiées et la question hard/soft ne se pose plus vraiment. FreeNAS qui est la seule alternative software crédible à ce jour est encore loin des perfs et de la fiabilité d'une baie proprio de grande marque. Même en moyenne gamme, pour à peine plus cher qu'un PC monté à la main avec FreeNAS dessus, un Thecus N1x000pro sera généralement meilleur (et plus simple à administrer) et pourtant c'est une LSI 2008 dessus, et c'est pas vraiment une foudre de guerre.
[^] # Re: Utilisation en production ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Si le but est d'avoir un sync rapide, et de la mémoire cache en écriture pléthorique, cela ne doit pas être difficile de mettre 1 Go de ram de cache d'écriture sur un disque dure au lieu de 32 Mo et d'avoir une super capacité pour finir un fsync en cas de coupure d'alimentation.
"La première sécurité est la liberté"
[^] # Re: Utilisation en production ?
Posté par Kaane . Évalué à 7.
Si le but est d'avoir un sync rapide, et de la mémoire cache en écriture pléthorique, cela ne doit pas être difficile de mettre 1 Go de ram de cache d'écriture sur un disque dure au lieu de 32 Mo et d'avoir une super capacité pour finir un fsync en cas de coupure d'alimentation.
C'est pas tout à fait aussi simple que ça. Le disque dur doit en plus posséder une intelligence au niveau bloc (au minimum). Si tu fais du sync brut de fonderie tu vas à la catastrophe, si tu fais du sync en mode pur synchrone tu tues les perfs.
Par exemple tu copies un gros fichier comme copie d'un autre, puis tu modifies le nouveau fichier en changeant un caractère et tu modifies l'ancien fichier en changeant un autre caractère.
Si tu n'as pas d'intelligence au niveau bloc il va se produire un des deux scenarios suivant :
1) Mode synchrone pur
- demande de copie du fichier => "Ouhlà gros fichier,on va syncer plus tard"
- modification du nouveau fichier => "Bon ben on va syncer maintenant, merci de patienter le temps de la copie, pas touche au fichier en attendant"
- modification de l'ancien fichier => "Bon ben on va syncer maintenant, merci de patienter le temps de la copie, pas touche au fichier en attendant"
Conséquence : gros impact sur les I/Os notamment en cas d'accès concurrents. L'OS peut faire des pirouettes pour permettre la modification de l'ancien fichier alors que le nouveau n'est pas encore copié, mais au niveau disque c'est clairement pas top. (Et pourtant c'est ce qui se passe 90% du temps en SATA….)
2) Mode "brut de décoffrage"
- demande de copie du fichier => "Ouhlà gros fichier, on va syncer plus tard"
- modification du nouveau fichier => "Bon ben on va syncer maintenant, merci de patienter le temps de la copie, pas touche au fichier en attendant"
- modification de l'ancien fichier => "Un seul caractère ? Pas de problème gars - on fait ça tout de suite"
Conséquence : impact modéré sur les I/O, mais gros risque de corruption de données si la source du fichier en cours de copie est modifié.
En SAS (et en scsi en général) il va se passer ça (en ultra simplifié hein…):
Au niveau I/O, temps de réponses, opérations à effectuer pour un sync etc. on comprend assez vite que le SAS va booster grave.
Bien entendu il y a en plus des algos qui font que les écritures proches sont faites par lot, la gestion du cache est beaucoup plus puissante que ce qu'exposé dans cet exemple simpliste etc.
En SATA, la nature même du fonctionnement fait que le cache s'essouffle très vite. Il y a eu à une époque des disque SATA avec 256Mo, mais leurs perfs étaient à peine meilleure que les disques avec 32Mo. Honnêtement sauf à ballader à longuer de journée des fichiers qui font la moitié de la taille du cache disque, il n'y a aucun intéret à aller au delà de 64Mo en SATA, et déjà c'est overkill…
[^] # Re: Utilisation en production ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
"il n'y a aucun intéret à aller au delà de 64Mo en SATA, et déjà c'est overkill…"
Je ne comprends pas comment cela peut être un overkill. Si c'était le cas, les caches SSD ne servirait à rien.
Ici, le but est d'utiliser la RAM cache, comme le fait avec un SSD, certain disque hybride. Pour l'instant, c'est difficile à faire sans un gros risque de perte de donné. Mais ce n'est plus le cas, si la RAM peut être sauvé en cas de coupure.
"La première sécurité est la liberté"
[^] # Re: Utilisation en production ?
Posté par Kaane . Évalué à 7.
Je ne comprends pas comment cela peut être un overkill. Si c'était le cas, les caches SSD ne servirait à rien.
Le cache des SSD sert dans le sens ou il est plus rapide que le SSD lui même et permet donc d'avoir de meilleurs temps de réponses quoi qu'il arrive, également les gros cache SSD évitent que les fichiers qui sont modifiés continuellement par l'OS (au hasard /var/log/syslog) ne détruisent la durée de vie du SSD.
L'hybridation SSD/HD sert dans le sens ou le SSD est plus rapide que le HD et que l'on a des Go d'espace de stockage.
Maintenant dans le cas d'un cache classique sur un disque SATA la question est "quelle quantité de cache on peut raisonnablement remplir avant que le principe de fonctionnement du SATA ne nous oblige à faire un sync ?", question qui peut se résumer en SATA à "combien de cache va-t-on remplir avant qu'il y ait besoin de dupliquer un fichier dans le cache ?". Le SATA n'a pas de mapping des blocs, il lui est donc très difficile de faire croire à l'OS qu'il travaille sur le disque dur alors qu'il travaille en fait sur du cache. La conséquence est que le SATA n'est pas adapté du tout à la modification d'un fichier qui est déjà en cache. On peut recréer une autre entrée cache pour remplacer la première mais au moment du sync il faudra écrire les deux entrées l'une par dessus l'autre pour rester cohérent. Sur le coup on va gagner un peu de perfs, mais au sync on va doubler les I/O et là c'est le drame. (Une fois de plus je simplifie, l'OS et le NCQ font que les I/O ne sont pas vraiment doublées mais l'overhead va quand même être important).
La norme SATA fait que les disques ne sont pas très intelligent au niveau du cache, pour accéder à un cache SATA il faut demander exactement le même ségment que celui qui est dans le cache. Ou alors le segement qui est juste avant ou alors le segment qui juste après. Par exemple si dans le cache vous avez le segment xDEF -> xFFE et que vous demandez le morceau xEEA -> xEEC dans 99.9% des cas vous allez entrainer un sync/read plutôt qu'un accès cache. C'est pour ça qu'il vaut mieux parler de buffer disque plutôt que de cache dans le cas du SATA. La clef pour accéder à un segment du buffer va être une commande, ou un lot de commande plus qu'une adresse.
Sur un OS moderne, en utilisation classique avec des disques SATA, la quantité d'infos qu'il va y avoir dans le cache au moment ou ca devient contre productif de continuer à bourrer le cache plutôt que de syncer est très inférieure à 64Mo la plupart du temps. (Avant il y avait pleins de super docs qui montraient ca très bien sur le site SATA-I/O, maintenant la plus petite doc est à 25$ - cool.)
[^] # Re: Utilisation en production ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 0. Dernière modification le 10 février 2014 à 17:04.
Je ne connais pas le protocole SATA, mais le principe d'un cache est que le client n'a pas connaissance de son existence. Donc, la politique du cache est censé dépendre du fabricant du disque.
Je ne comprends pas pourquoi, il serait si difficile de faire un remapping des blocks en cache, et que tout reste cohérent ensuite. En gros, le plateau aurait la même utilité qu'un swap sur disque. J'ai du mal à comprendre la difficulté. Pour moi, un sata c'est des read/write/trim sur des adresses de 512 ou 4k octets, et des demandes de barrières de synchro.
"L'hybridation SSD/HD sert dans le sens ou le SSD est plus rapide que le HD et que l'on a des Go d'espace de stockage."
?! Tu te rend compte que l'usage RAM+batterie revient à l'usage d'un SSD ? Et donc, que tous les avantages associés restent. Ce genre de ssd tourne autour de qq Go de mémoire.
"La première sécurité est la liberté"
[^] # Re: Utilisation en production ?
Posté par Kaane . Évalué à 3.
Je ne comprends pas pourquoi, il serait si difficile de faire un remapping des blocks en cache, et que tout reste cohérent ensuite.
Ca existe, ca s'appelle SCSI. Et c'est vraiment plus complexe que ca en a l'air. Même la version simpliste de l'exemple que j'ai donné fini par poser des problèmes dans certains cas particuliers. Les problèmes principaux sont liés au double double addressage sur un disque dur. A savoir l'adresse du bloc et l'adresse à l'intérieur du bloc du point de vue du disque et l'adresse du bloc et l'adresse à l'intérieur du bloc du point de vue de l'OS.
Pour que le cache soit efficace il faut être capable de mapper l'un sur l'autre très vite pour pouvoir dire facilement et rapidement si un bloc demandé par l'OS est disponible en cache ou pas. La norme SATA a résolu ce problème en utilisant non pas les adresses mais les commandes comme clefs. C'est beaucoup plus simple (et donc beaucoup moins cher) mais c'est loin d'être aussi efficace.
[^] # Re: Utilisation en production ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Je ne comprends toujours pas. Si les contrôleurs Sata ont choisi la méthode bête pour faire un cache, qu'est-ce qui empêche de faire un cache moins bête dans une autre génération de disque ? Une mémoire de tag, c'est pas sorcier. Pour 1go, tu stocks (1024*1024/4) blocs de 4k. Pour des clefs 48 bits, cela te fait un tag de ~2 Mo, cela n'est pas énorme.
Le système peut aussi fonctionner comme une mémoire virtuelle avec une TLB à plusieurs niveau, et le dernier niveau est le plateau. La gestion se fait ainsi avec les adresses et non les commandes.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 10 février 2014 à 17:40.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Utilisation en production ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Je veux bien qu'un code soit plus fin si il a toutes les informations, par rapport à un hardware dédiés forcément plus brutal.
Mais si il y a bien un truc que ZFS ne peut pas faire, c'est garantir que les données sont bien écrites sur le disque (fdone()) sans perdre de performance. C'est impossible à faire sans l'aide du hardware.
Le seul problème d'un gros morceau de RAM, c'est l'amplification d'écriture qui peut devenir problématique. C'est le problème d'un système où tu associes un truc rapide et petit, avec un truc lent mais gros. Le petit sert en premier, mais si il déborde, c'est les performances du gros que l'on voit (moins le transfert du petit dans le gros).
En gros, un gros cache RAM sera très efficace en cas de grande quantité de modification local. Il le sera moins pour tout ce qui est recopie de gros fichier, forcément.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Utilisation en production ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Je ne parlais pas de ça. Tu as 100 IO/s avec un disque, 100 000 io/s en RAM ?
"La première sécurité est la liberté"
[^] # Re: Utilisation en production ?
Posté par Kaane . Évalué à 2.
Je ne comprends toujours pas. Si les contrôleurs Sata ont choisi la méthode bête pour faire un cache, qu'est-ce qui empêche de faire un cache moins bête dans une autre génération de disque ?
Le cout j'imagine principalement.
Une mémoire de tag, c'est pas sorcier. Pour 1go, tu stocks (1024*1024/4) blocs de 4k. Pour des clefs 48 bits, cela te fait un tag de ~2 Mo, cela n'est pas énorme.
C'est pas spécialement la place prise par les données qui pose problème, c'est le suivi et l'indexation des données, notamment lors d'une copie d'un lot de blocs sur un autre avec modification du lot de blocs source par la suite. Il faut également suivre les modifs faites en cache, recoller les morceaux si on demande d'ouvrir plusieurs lots de blocs qui ont des blocs en commun. etc. Et faire le tout suffisament vite et efficacement pour que ce soit interressant au niveau perf. Savoir gérer les problèmes ("tu sais le fichier que tu modifies depuis 10 minutes en cache, et ben en fait je peux pas le sauvegarder, il y a un secteur deffectueux") et pleins d'autres chose.
[^] # Re: Utilisation en production ?
Posté par Arcruxe . Évalué à 2. Dernière modification le 10 février 2014 à 21:26.
Pour info, ZFS s'occupe aussi de cette partie, d'ailleurs quand on donne un disque complet à un zpool et non une partition, il met le scheduler io du noyau sur "noop" pour utiliser le sien à la place.
Il faudrait comparer les performances du scheduler de ZFS et ceux des fabriquants de disques dur sur différents workload pour savoir qui est le plus efficace :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 10 février 2014 à 16:02.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Utilisation en production ?
Posté par Kaane . Évalué à 4.
En résumé, la méthode soft poutre de sa maman ours et surtout est très malléable
Au niveau benchmark, le SATA RAID soft va poutrer de façon monstrueuse le SAS RAID hard. Tout ce qui est interressant dans le SAS RAID hard (accès concurrents, CPU libéré, accès direct en modification, réorganisation dynamique de demandes très variées venant de plusieurs utilisateurs etc.) va disparaitre dans les benchs.
Généralement les benchs sont fait en version mono utilisateur, quasi mono tache et sur un disque vierge de toute fragmentation. Dans la vie réelle ca se passe pas vraiment comme ça.
Lance 6 ou 7 Bonnie ++ en parallèle sur un ordi sur lequel il y a déjà 5 superpi (nb coeur + 1 en fait) qui tournent et là on verra la gueule que fait ZFS comparé à un RAID hardware.
[^] # Re: Utilisation en production ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
La comparaison est valable à budget équivalent. Cela veut dire que le PC en pure raid soft pourrait avoir le double de ram et le cpu de gamme supérieur.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Utilisation en production ?
Posté par Kerro . Évalué à 4.
C'est le cas de NetApp. Et ils ne le cachent pas.
Mais encore une fois, une carte RAID c'est « juste » un processeur, de la mémoire, et un bus d'accès direct aux disques.
[^] # Re: Utilisation en production ?
Posté par Krunch (site web personnel) . Évalué à 2.
Mais est-ce un foudre de guerre ?
http://fr.wiktionary.org/wiki/foudre_de_guerre
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Utilisation en production ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -1.
En gros, une fois que le contrôleur disque a la bonne vitesse (canaux assez gros par rapport à la connexion cpu et la connexion vers les disques), tout le reste peut être faire sur les disques dures : cache énorme, sécurisé par une capacité pour sauver les données sur le disque qui tourne ou sur un ssd. Cela permet de fournir une écriture garantie à très haute vitesse sans bidouille qui peut perdre des données.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 10 février 2014 à 16:55.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Utilisation en production ?
Posté par Jak . Évalué à 1.
J´ai retrouvé ça récemment au sujet des problèmes de RAID 5 et 6 (soit 1 et 2 disques redondants)
http://www.zdnet.com/blog/storage/why-raid-5-stops-working-in-2009/162
http://www.zdnet.com/blog/storage/why-raid-6-stops-working-in-2019/805
ZFS et BTRFS sont probablement des solutions d´avenir comparés aux systèmes RAID.
[^] # Re: Utilisation en production ?
Posté par JJD . Évalué à 10.
D'un autre côté, je ne suis pas sûr que l'on aurait fait plus court pour présenter ext4 + lvm + dm_raid + dm_cache + …
Il faut en effet bien noter que zfs gère toute la pile de stockage : ce n'est pas juste un système de fichiers.
[^] # Re: Utilisation en production ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -3.
C'est pas faux.
"La première sécurité est la liberté"
[^] # Re: Utilisation en production ?
Posté par rictus (site web personnel) . Évalué à -1.
C'est à mon sens ce qui manque un peu à la dépêche : elle est centrée exclusivement sur ZFS, laissant un peu penser qu'il a tout inventé…
La plupart des fonctionnalités de ZFS sont déjà implantées via d'autres mécanismes sous linux (mdadm, lvm …).
L'article gagnerait (et ferait moins parti pris) à comparer les solutions.
[^] # Re: Utilisation en production ?
Posté par Joris Dedieu (site web personnel) . Évalué à 9.
Clairement, ce n'était pas mon but ici. Je voulais mettre un coup de projecteur sue OpenZFS, ZFS On Linux ainsi que l'aspect portable de cette solution. Cela ne signifie en rien que je dénigre md, geom ou lvm mais simplement qu'il n'entraient pas dans le scope de cet article qui est de présenter ZFS comme une alternative viable et portable au RAID proprio.
[^] # Re: Utilisation en production ?
Posté par Joris Dedieu (site web personnel) . Évalué à 10.
J'utilise largement ZFS en production sur tout types de serveurs (BDD, NFS, backup, MAIL, SAN iscsi). Tout ce que j'ai décrit dans l'article est validé en prod.
Les seuls problèmes que j'ai eu depuis 2 ans sont lié à une conception foireuse de l'architecture de stockage sous-jacente. En respectant deux règles :
1) ZFS a besoin que les données soient redondées sur plusieurs disques
2) Ne jamais empiler ZFS avec du raid matériel
je n'ai plus aucun problème.
[^] # Re: Utilisation en production ?
Posté par Kerro . Évalué à 5.
Sur BSD je vois un peu partout que ça roule très bien question fiabilité.
Sur Linux le niveau est-il aussi bon ?
[^] # Re: Utilisation en production ?
Posté par Psychofox (Mastodon) . Évalué à 6.
Oui mais mon expérience en prod se limite à Solaris 10. C'est d'expérience super robuste et pratique. On a à la fois du linux et du solaris chez nous et un resize de FS (en fait un changement de quota sur ZFS) est instantané sur ZFS alors que ça peut prendre 3 plombes sous linux. C'est vraiment agréable. Et ça c'est sans parler des bugs qui empêchent certain ext3 de se redimensionner sur les redhat 5 et qui force un démontage/fsck/resize/remontage.
Et les snapshots + send/receive c'est un bonheur pour de la sauvegarde rapide, bien plus sympa que des ufsdump. Pour cela j'utilise maintenant aussi zfs pour mes données persos. Sous Solaris live upgrade, un mécanisme de duplication d'environnement de boot, est intégré à ZFS. Du coup ça permet de pouvoir rebooter sur un snapshot avec le statut précédent dans l'hypothétique cas ou un passage de patches se passe mal.
[^] # Re: Utilisation en production ?
Posté par lolop (site web personnel) . Évalué à 6.
Le redimensionnement avec XFS est immédiat aussi (contrairement à ext234).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Utilisation en production ?
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 9.
Oui. 1 Po (réparti sur 4 serveurs) dans un centre HPC.
Oui. Mais comme plein de choses, pas sur n'importe quoi (faut du bon matos, bien dimensionné).
Les Bests practices sont de trés bonne qualitay (http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide & http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide).
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: Utilisation en production ?
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 10.
J'ai oublié de préciser un truc qui a son importance (à mes yeux, en tout cas) : "ZFS on Linux" est un projet sponsorisé par le Lawrence Livermore National Laboratory. Avec le Oak Ridge, c'est un peu la crème du dessus du panier du haut de la pyramide du top niveau des Tier0 US dans le monde HPC. Au-dessus, y'a rien.
Et quand ces gars-là te disent qu'une technologie vaut le coup, est intéressante, mérite qu'on se penche dessus, tu les écoutes. Avec attention. Mieux, quand ils annoncent qu'ils investissent du pognon dedans… Tu réfléchis pas longtemps et tu t'y intéresses pour de vrai… Voire, tu passes en prod :o)
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: Utilisation en production ?
Posté par Kerro . Évalué à 1.
Argument d'autorité spotted.
Même les meilleurs font des erreurs.
C'est (entre autres) pourquoi l'argument d'autorité n'est recevable que dans les situations où il est plus économique d'utiliser ce raccourci d'évaluation.
[^] # Re: Utilisation en production ?
Posté par Kwiknclean . Évalué à 1.
Hello,
"Est-ce qu'il y a des gens qui utilise ZFS en prod sur des systèmes critiques ?"
Sur des anciens systèmes Solaris, ZFS n'est pas une nouveauté 2014, c'est déjà le cas depuis de très nombreuses années :)
Sous Linux, Nous avons un client ayant leur 4 SAN sous un socle SuperMicro + Ubuntu Server+ZFS, qui présent du LUN aux ESX ça fait son boulot et ça ne plante pas plus pas moins que les SAN "constructeurs" NetApp and Co, ça ne demande pas non plus, plus de temps exploitation.
[^] # Re: Utilisation en production ?
Posté par Kerro . Évalué à 2.
Tu m'inquiètes. Tu as vu des SAN planter ?
Je n'ai que peu d'expérience dans ce domaine, mais vu le prix des bouzins j'aurais mal aux fesses de les voir se vautrer.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Utilisation en production ?
Posté par Psychofox (Mastodon) . Évalué à 5.
J'ai déjà vu un ingénieur EMC planter un SAN du même constructeur. D'après ce qu'ils nous ont dit après coup c'était lié à un bug qui se manifestait s'ils exécutaient la même commande avec trop peu de temps d'intervalle entre les deux services processor. Le genre de bug qu'ils n'arrivent pas à corriger et pour lequels ils y vont à la louche, du genre, attendons un quart d'heure (même si 1 minute suffirait peut-être mais on n'est pas sûr). Bref effrayant quand on paye un truc un demi-million.
Les-dits SP tournaient à l'époque sur du vieux windows NT soit dit en passant. Je ne sais sur quoi ça tourne, j'ai entre temps changé d'employeur et on n'a pas le même constructeur (mais où j'ai vu une baie NAS perdre 1/4 de ses données suite à une panne hardware).
Bref. Cher, reconnu et performant n'implique pas que ça ne merde jamais.
# BBU
Posté par Zenitram (site web personnel) . Évalué à 4.
A confirmer, mais il semble que chez LSI CacheVault pallie au problème des batterie en remplaçant la chose par une copie sur mémoire Flash lors de la coupure avec le reste d'éléctricité qu'il a en stock.
[^] # Re: BBU
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il s'agit souvent de batterie au plomb, il faut donc bien vérifier son état de fonctionnement chaque année.
C'est d'ailleurs dommage que les PC ne soient pas équipé d'un système qui monitor la tension de base, et gère un "fsync" avant de tout couper. Le problème s'est déjà posé de copie qui continue alors que la RAM du PC était pourris à cause d'une baisse de tension, ce qui a détruit des fichiers.
Il faudrait un truc standard dans les PC pour que la tension puisse rester stable ~5s après la coupure du 220V.
"La première sécurité est la liberté"
[^] # Re: BBU
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 10 février 2014 à 10:00.
Soit je n'ai rien compris, soit justement il n'y a plus de batterie dans ce dont je parle (gras de moi) :
"Interventions planifiées : Aucune pendant tout le cycle de vie du contrôleur"
"Temps de chargement : Le capaciteur se charge en quelques secondes pendant que le système démarre"
Donc je ne comprend pas ta phrase.
[^] # Re: BBU
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
J'imagine qu'il s'agit dans ce cas, d'une super capacité, mais la durée de rétention est assez courte, non ?
"La première sécurité est la liberté"
[^] # Re: BBU
Posté par Zenitram (site web personnel) . Évalué à 2.
Ben… Assez pour qu'ils puissent vendre leur solution, il faut croire. La mémoire Flash, ça va vite.
[^] # Re: BBU
Posté par ChickenKiller . Évalué à 1.
En même temps sur une coupure de jus ….
Sinon ça existe déjà, ça s'appelle un onduleur :-P
[^] # Re: BBU
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Pas exactement, les SGI étaient connu pour en être équipé. L'avantage est de ne pas avoir besoin d'un truc qui fait 220 -> 12V -> 220 avec un rendement faible. Il est possible de mettre des capacités, là ou il faut, pas besoin de gérer une batterie. Le but est juste de couper proprement avec un fsync, sans corruption des mémoires.
"La première sécurité est la liberté"
[^] # Re: BBU
Posté par KiKouN . Évalué à 4.
Un portable ?
[^] # Re: BBU
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
C'est d'ailleurs exactement le principe du ZIL.
[^] # Re: BBU
Posté par Zenitram (site web personnel) . Évalué à 2.
Soit j'ai mal compris, soit ce n'est pas le cas.
ZIL: Mémoire centrale --> SSD (Flash) --> HDD
CacheVault: Mémoire centrale --> Mémoire carte (backup Flash si nécessaire) --> HDD
Donc ZIL est limité à la vitesse du SSD (Flash) alors que CacheVault est limité à la vitesse de la RAM (la vitesse Flash étant que lors d'une coupure), et il me semble que la RAM reste toujours plus rapide que la Flash, donc ZIL est mieux que HDD, mais moins bien que CacheVault.
Ou est-ce que je me trompe?
[^] # Re: BBU
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Tu as peut être raison. J'avais compris que l'écriture sur flash était systématique. Je peux me tromper, je ne connais pas ce produit. J'ai un peu de mal a concevoir l'aspect "si nécessaire".
[^] # Re: BBU
Posté par Zenitram (site web personnel) . Évalué à 2.
Il y a un capaciteur, donc de ce que je comprend de la pub (je n'ai pas encore acheté ce produit), si coupure, la carte a assez d'électricité pour copier en Flash avant de s'éteindre. Donc ça copie si nécessaire (si il y a une coupure), sinon RAM uniquement donc plus rapide que ZIL.
[^] # Re: BBU
Posté par Kioob (site web personnel) . Évalué à 2.
Je confirme que c'est bien le comportement vendu par LSI. OVH par exemple utilise essentiellement ça sur ses serveurs haut de gamme.
La mémoire Flash n'intervient vraiment qu'en cas de coupure électrique, en temps normal tout se passe dans la RAM de la carte RAID.
Sinon coté maintenance il semblerait que ces «condensateurs» aient une durée de vie supérieure à celle des batteries, ainsi qu'une procédure de test beaucoup plus courte (ces cartes RAID intègrent souvent des procédures automatiques de vérification de la batterie / condensateur, durant lesquelles le «WriteBack» est désactivé et les perfs s'écroulent… à planifier judicieusement !).
alf.life
[^] # Re: BBU
Posté par Kerro . Évalué à 3.
Juste une remarque à propos des BBU : les données sont écrites lorsque l'alimentation revient.
Donc il est préférable de rallumer rapidement.
Il est également prudent de rallumer sans relancer l'OS lorsqu'on veut éteindre pour longtemps (ou changer la carte RAID) car l'OS a pu éteindre la machine avant que tout soit écrit (en principe non car le pilote doit faire le nécessaire, ça reste un élément de prudence).
[^] # Re: BBU
Posté par Zenitram (site web personnel) . Évalué à 2.
Justement, je parle que les BBU c'est un peu le siècle dernier, et qu'avec CacheVault tu as environ 3 ans (cf specs) avant de perdre les données, ça laisse de la marge ;-)
En cas de plantage, je conçois, mais sinon j'ose espérer que le pilote ne rend pas la main pendant l'extinction avant d'avoir tout écrit…
# Comparo de RAID logiciels ?
Posté par romu . Évalué à 3.
Bonjour,
Merci pour cet article que je vais lire à tête reposée. Ca me fait penser que si quelqu'un se sent de faire une comparaison de RAID logiciels (MDADM, ZFS, Btrfs, etc), je suis preneur.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
# Une limitation de ZFS embêtante pour l'utilisateur amateur que je suis
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 6.
J'adore ZFS depuis fort longtemps. Je trouve son utilisation fort agréable grâce á des commandes bien définies et claires : zpool pour gérer les "volumes" et zfs pour gérer les systèmes de fichier (en simplifiant).
Ayant un mini serveur avec la possibilité d'y mettre jusqu'à 5 HDD, j'y ai installé FreeBSD et je me suis entrainé à y utiliser et tester ZFS. Il ne m'a pas déçu, mais une fonctionnalité lui manque quand on est amateur : la flexibilité de commencer avec un nombre limité de disques puis d'en ajouter. Il n'est par exemple pas possible de commencer avec 2 disques en mirroir puis de passer à 4 disques en RAIDZ, ou 5 disques en RAIDZ2. Il est toutefois possible avec ZFS de passer de 2 à 4 disques en passant par exemple d'un "RAID1" à un "RAID10".
Dans mon cas j'ai 3 disques disponible. Je peux faire un RAIDZ par exemple. Si je veux l'étendre ensuite, je suis obligé de créer un 2e RAIDZ de 3 disques (un RAID50 ou 5+0 en gros), mais je n'ai pas 6 connecteurs, seulement 5.
Je me suis donc tourné vers Linux+Btrfs. J'aime beaucoup moins les commandes en espace utilisateur qui me permettent de créer, gérer et manipuler ce "système de fichier". Ca semble plus brouillon à mon goût. Mais le fait de pouvoir commencer avec 2 disques en mirroir et de plus tard pouvoir passer à 3 ou 4 disques et de changer la configuration de la redondance m'a séduit. Pour les "amateurs" qui n'ont pas de gros budgets et qui veulent se construire un serveur avec de la récup', btrfs est mieux adapté, plus flexible dans son évolution. Aujourd'hui je pars sur un raid5 avec mes 3 disques. Demain, je pourrais choisir un raid10 ou un raid6 selon mes besoins et le nombre de disque dont je disposerai.
J'ai donc fait le choix de Btrfs.
Par contre, si le budget ou le matériel est là, alors ZFS aurait ma préférence.
[^] # Re: Une limitation de ZFS embêtante pour l'utilisateur amateur que je suis
Posté par Reihar . Évalué à 1.
J'étais passé de 1 à 2 disques lorsque j'ai monté mon NAS. Et je comptais l'étendre à 3 puis à 4 disques. Ce serait embêtant si ce n'était pas possible. En es-tu sûr ?
[^] # Re: Une limitation de ZFS embêtante pour l'utilisateur amateur que je suis
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
Pour l'instant, il existe deux façons d'étendre un zpool.
1) Remplacer des disques par des disques plus grands.
2) Rajouter un second volume RAID stripé avec le premier
# comparaison avec BTRFS
Posté par SaintGermain . Évalué à 8.
Justement je suis en train d'expérimenter un peu ZFS et BTRFS dans un cadre d'utilisation "loisirs" (photos famille, etc.) et je n'arrive pas encore à me décider sur lequel partir.
Le problème c'est que je n'ai pas beaucoup de temps à consacrer à l'administration, donc je fais attention au ratio simplicité/robustesse et les performances et fonctionnalités extra sont relativement secondaires.
Comme je connais bien linux et Debian, je pense rester dans ce cadre. Et le plus simple/économique pour moi était de partir sur du RAID1 avec deux disques.
Dans ce cadre, du coup je vois 2 gros désavantages à ZFS:
- Difficile d'installer sa partition root sous ZFS pour des raisons de licences (i.e. l'installateur de base de Debian ne propose pas l'option, enfin pas pour l'instant). Après on peut choisir un FS différent entre la partition root et la partition home, mais cela devient moins simple (ou alors on fait encore plus simple on ne gère pas la partition root dans le RAID)
- Le support n'est pas intégré de base dans linux (encore ce problème de licence !), j'ai un peu peur que cela casse lors des mises à jour de linux (d'autant que du coup les outils habituels de récupération comme les live-cd et autres n'ont pas le support de ZFS n'ont plus)
En comparaison, l'installation et la maintenance avec BTRFS semble du gâteau (à confirmer sur le long terme, je ne fais que commencer). Donc BTRFS semble plus accessible pour les gens comme moi.
En cherchant sur internet, on voit quand même que BTRFS semble moins stable que ZFS. Et avec ZFS on bénéficie quand même de pas mal d'années de retour d'expérience, donc en cas de soucis c'est relativement facile de trouver quelqu'un ayant eu le même problème (et l'ayant peut-être résolu…).
Une des killer-features de BTRFS pourrait être la déduplication différée (offline) car actuellement la déduplication avec ZFS requiert pas mal de RAM (et un bon SSD ?) pour ne pas voir les performances s'effondrer.
J'ai quand même espoir que BTRFS soit suffisamment stable pour une utilisation basique (RAID1 avec deux disques, pas de subvolume).
L'expérimentation continue…
[^] # Re: comparaison avec BTRFS
Posté par patrick_g (site web personnel) . Évalué à 8.
Pour une comparaison avec Btrfs il faut lire l'excellente série d'articles publiés par LWN :
1) The Btrfs filesystem: An introduction
2) Btrfs: Getting started
3) Btrfs: Working with multiple devices
4) Btrfs: Subvolumes and snapshots
5) Btrfs: Send/receive and ioctl()
[^] # Re: comparaison avec BTRFS
Posté par Psychofox (Mastodon) . Évalué à 2.
Un truc qui m'avait dérangé quand j'avais testé BTRFS il y'a 1 ou 2 ans, c'est qu'il me semblait impossible de faire un snapshot d'un volume racine (enfin pas un subvolume). C'est toujours le cas ? Est-ce qu'on peut imaginer avoir un / en BTRFS et en faire un snapshot avant upgrade ou réinstalle et pouvoir booter sur le snapshot depuis grub ?
[^] # Re: comparaison avec BTRFS
Posté par SaintGermain . Évalué à 1.
Bonne question je vais essayer !
Mais je penque que c'est possible :
It is possible to snapshot only the root volume or a subvolume
Pour le spapshot avant upgrade, je crois qu'il y a un truc : apt-btrfs-snapshot
# ZFS
Posté par Zwordi (site web personnel) . Évalué à 2.
Merci pour cette excellente explication de ZFS. On en entend de plus en plus parler et je pense que pour des situation de test ou autre en attendant une plus grande maturité pourrait être intéressante.
# Et la config matériel nécessaire pour ZFS ?
Posté par coucou78 . Évalué à 2. Dernière modification le 10 février 2014 à 11:23.
… car ce que j'ai cru comprendre, il y a quelques années de cela (eh oui moi aussi ZFS m'avait totalement impressionné !),
que l'on doit parler en giga de RAM pour chaque giga (ou tera ) je ne sais plus) de stockage utile pour avoir des perf. correcte.
Quand est il à ce jour ?
C'est bien la le souci de ZFS … (et c'est peut etre aussi pour cela que Apple le la plus retenu , il devai etre dans snow lleopard et pchittt, nada !)
Note : Oui le raid hard est une plaie, car si crash de la carte raid matériel = obligation de recommander la même pour sauver ses données (backup quand tu nous tiens)
Les raid soft c'est bon. (mdadm pouahhh)
en tout cas un bien bel article !!!
[^] # Re: Et la config matériel nécessaire pour ZFS ?
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
ZFS n'utilise pas spécialement de RAM en soit. Il gère par contre du cache en lecture et des écritures asynchrones.
Si tu ne veux pas utiliser de ram.
Du coup, tu as un FS naïf limité par la vitesse des disques
Merki
[^] # Re: Et la config matériel nécessaire pour ZFS ?
Posté par rakoo (site web personnel) . Évalué à 4.
Il me semble que Linux a son propre cache mémoire pour les I/O disques, par-dessus les systèmes de fichiers donc. Est-ce que ça ne rentre pas en conflit avec le cache ZFS ? Est-ce que les différences de performances (cache noyau + cache FS vs cache noyau seul) sont si importantes que ça ?
[^] # Re: Et la config matériel nécessaire pour ZFS ?
Posté par Arcruxe . Évalué à 1.
Le cache du noyau n'est plus utilisé pour les disques en ZFS si je ne dit pas de bêtise. Pour info, unifier l'ARC de ZFS et le pagecache de Linux fait partie de la todolist du projet ZFS on Linux.
[^] # Re: Et la config matériel nécessaire pour ZFS ?
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 3.
Dans les bests practices, il est dit : (1Go ram + 1Ghz cpu pour 1To stockage). Et c'est vrai.
Si tu veux du stockage performant, faut mettre les moyens. Cela étant dit, une solution matérielle équivalente a une bonne configuration ZFS (sur base SuperMicro, Dell, etc), c'est souvent beaucoup plus cher. Et trés proprio (NetApp, Panasas, IBM).
Proverbe Alien : Sauvez la terre ? Mangez des humains !
# Ou presque ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Un sacré presque alors, s'il n'est pas pris en charge sous Windows. Pour info, le système de fichiers le plus largement pris en charge après les FAT, c'est ISO-9660. Et le second plus largement pris en charge, qui a l'avantage d'être utilisable en lecture et en écriture, c'est UDF.
[^] # Re: Ou presque ?
Posté par fravashyo . Évalué à 3.
UDF a beaucoup de limitations (ne serait-ce que parce qu'il n'est pas géré sous XP et que c'est un FS prévu pour les cdrom), on en avait déjà parlé…
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
# ZFS est réservé au stockage
Posté par MTux . Évalué à 10.
A mon sens ZFS n'est pas comparable à une carte RAID matérielle ni même aux autres systèmes de fichiers.
Déjà, comme mentionné dans le journal mais pas assez mis en avant, ZFS est très gourmand. Limite le système y consacre toutes ses ressources. Pour le pro qui utilise deux Intel Xeon avec 16GB de ram pas de souci, mais pour les autres attention. Celui qui loue un VPS équipé d'un Intel Atom doit rester en UFS.
Ensuite la doc de Oracle (j'ai pas de lien mais cela a été beaucoup discuté sur pas mal de forums) indique un pré requis important : de la mémoire ECC. Ce n'est pas une recommandation, c'est un pré requis. Comme mentionné dans le journal ZFS utilise énormément de cache et part du principe que le serveur ne peut pas tomber en panne (ce qui est plus ou moins le cas dans les vrais datacenter, avec redondance des composants et présence d'un onduleur). Là encore on s'aperçoit qu'on ne peut pas installer sa Fedora sur un périphérique ZFS sur un coup de tête. Il faut une bonne infrastructure.
Pour finir je dirais qu'une carte RAID matérielle conserve des avantages. Cela ne squatte pas les ressources matérielles de l'hôte, c'est totalement transparent, et facile à gérer. Un disque en panne ? Une petite LED en façade indique le disque à remplacer. Cela se fait à chaud et le RAID se reconstruit tout seul. Aucune commande à taper. Pratique quand une équipe de personnes en sous-nombre doit gérer beaucoup de serveurs à la fois. Pratique quand tu dois réparer ton serveur dans l'urgence (la fameuse permanence du 25 Décembre) et que l'expert ZFS n'est pas là.
Sinon excellent article, j'utilise ZFS sur mon NAS perso (sans RAM ECC ni onduleur je suis conscient des risques) et c'est vrai que ça dépote (des transferts à 120 Mo/s sur le réseau). Mais il faut voir que ZFS lui-même c'est presque comme un serveur, il faut le maîtriser, le surveiller, et le faire tourner sur du matériel digne de lui.
[^] # Re: ZFS est réservé au stockage
Posté par Joris Dedieu (site web personnel) . Évalué à 10.
On est bien d'accord. Il faut donner à ZFS des disques autrement dit ni des partitions, ni des volumes raid. Par contre tu peux très bien utiliser tes zvol comme des périphériques de bloc quelconque pour faire ce que tu veux y compris les formater en UFS ou autre.
C'est a nuancer suivant l'usage. ZFS n'utilise que les ressources que tu lui donne. Les recommandations visent des performances optimales. C'est une histoire de compromis et de choix.
Le risque que les erreurs de RAM corrompent les données n'est pas spécifique à ZFS. C'est le cas sur tous les systèmes d'écriture asynchrone y compris sur des logiciels comme des SGBD. Sur du hardware non professionnel tu dois lancer des scrub réguliers pour détecter rapidement ce type de comportements.
Non. Tu dois par contre gérer les options de synchro et de cache en fonction de ce risque.
Ce que tu décris des cartes raid proprio correspond au meilleurs des cas. Quand tu dois te battre avec la cli proprio et identifier un disque qui a disparu c'est une autre paire de manche. Le remplacement d'un disque sous ZFS peut également être totalement automatisé.
zpool tank set autoreplace=on
Merci
Je dirais une carte raid à construire sois même. Il faut choisir les composants en connaissance de cause et bien maîtriser le soft. C'est parfois un investissement plus humain couteux que du matériel proprio avec son support. Par contre si le stockage est au cœur de tes préoccupations tu t'y retrouves rapidement.
[^] # Re: ZFS est réservé au stockage
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"Sur du hardware non professionnel tu dois lancer des scrub réguliers pour détecter rapidement ce type de comportements."
Dans le spatial, le scrubing, c'est une fonctionnalitée d'un contrôleur mémoire qui provoque des lectures sur une mémoire ECC, qui produit une réécriture en cas d'erreur. (pas un vrai ECC mais du reed solomon, car une particule se tape toute une puce en général, donc 8 bits d'un coup pas seulement un bit). Le scrubing implique un code correcteur d'erreur. C'est fait pour détecter une erreur avant qu'une autre arrive, et empêche la correction.
J'imagine que tu parles d'un test type détection de "collage", genre memtest pour vérifier si une puce est défectueuse ou pas. Cela gère bien les puces en panne mais pas les états transitoires.
"La première sécurité est la liberté"
[^] # Re: ZFS est réservé au stockage
Posté par Joris Dedieu (site web personnel) . Évalué à 5. Dernière modification le 10 février 2014 à 15:56.
Non, je parle du zpool scrub qui vérifie et corrige l'intégrité des données sur les disques. Des erreurs relevées à ce niveau, relèvent souvent d'un problème matériel sous-jacent et la nécessité d'un diagnostic hardware approfondie.
[^] # Re: ZFS est réservé au stockage
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Il doit vérifier les hash du contenu. Mais il fait en quoi en cas d'erreur ?
"La première sécurité est la liberté"
[^] # Re: ZFS est réservé au stockage
Posté par peikk0 . Évalué à 2.
Il répare à partir des autres disques, si t'es en mode mirror ou RAIDZ*. Sauf évidemment si par un très un grand hasard les autres disques ont aussi une erreur sur la même donnée…
[^] # Re: ZFS est réservé au stockage
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Et dans ce cas, tu arrêtes tout et tu testes ta mémoire
[^] # Re: ZFS est réservé au stockage
Posté par Arcruxe . Évalué à 1.
Et si jamais ne peut pas réparer (zpool non redondant par exemple), il donne la liste des fichiers touchés pour qu'on puisse les restaurer depuis une backup :)
[^] # Re: ZFS est réservé au stockage
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Cette page https://calomel.org/zfs_raid_speed_capacity.html a l'air de dire qu'il y a une énorme différence de vitesse monocanal entre un chipset de base et une carte LSI. Je peux comprendre que les fake raid soit lent, mais que les chipsets qui ne font que passer les données entre le bus pci et le bus sata, le soit, cela parait dingue.
Si c'est le cas, il faut que les testeur de matos, testent leur SSD sur des vrais cartes, pour voir combien la carte mère fait perdre de performance (/4 selon le teste).
"La première sécurité est la liberté"
[^] # Re: ZFS est réservé au stockage
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Tu as le même ordre de différence entre deux contrôleurs de la même marque. Si tu compares par exemple une areca 1212 et un areca 1882 tu dois être dans le même ordre d'idée.
C'est au passage la même chose pour les contrôleurs réseau.
[^] # Re: ZFS est réservé au stockage
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Et au niveau des chipsets ? C'est pas très connu, ces différences.
"La première sécurité est la liberté"
[^] # Re: ZFS est réservé au stockage
Posté par Kerro . Évalué à 3.
Je trouve effectivement étonnantes les données que tu pointes.
Sur n'importe quel PC basique avec un bête SystemRescueCD la copie de disque à disque se fait à peu près à la vitesse maximale des disques indiquée par le constructeur.
Par exemple sur du Seagate Barracuda 1 To j'ai plus de 200 Mo/s sur un bon premier quart des disques (j'ai 217 sur mon dernier test, le constructeur indique 210) et 176 Mo/s en moyenne sur tout le disque (le constructeur indique 150).
C'est lors d'une copie de disque, donc lectures/écritures séquentielles.
[^] # Re: ZFS est réservé au stockage
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 11 février 2014 à 08:39.
Sur une machine à 6 disques de 4 To, j'ai au final que 70 Mo/s de débit séquentiel avec RAID-Z2 alors que chez moi (sous Windows, donc pas de ZFS, je prend le RAID de la carte) j'ai plus de 800 Mo/s (soit le débit max des disques). Je ne sais pas pourquoi et pas cherché plus (ça me suffit, et pas envie de payer mon admin pour qu'il cherche vu que ça me suffit) la raison, peut-être que c'est "juste" ZFS qui est gourmant et/ou qu'il faut le configurer aux petits oignons.
[^] # Re: ZFS est réservé au stockage
Posté par Kerro . Évalué à 2.
Sur l'exemple donné par Nicolas BOULAY on n'a comme seule différence le chipset (ou du moins on suppose).
31 Mo/s avec le contrôleur SATA de la carte-mère SuperMicro.
130 Mo/s en passant par une MegaRAID.
Pour ma part en « équivalent RAID 6 » j'ai testé un périphérique dm de Linux (donc le bête RAID logiciel) en mode RAID 10 avec 3 copies sur 4 disques (le RAID 10 de Linux n'est pas un vrai RAID 10 : il permet de choisir le nombre de copies, et d'avoir n'importe quel nombre de disques tant que supérieur au nombre de copies. Bref Le RAID 10 avec 3 copie est un RAID 6 amélioré). J'avais plus de 200 ou 250 Mo/s avec des disques qui débitent 150 Mo/s.
Bref, ce test est étrange avec certains résultats aussi faibles.
[^] # Re: ZFS est réservé au stockage
Posté par Zenitram (site web personnel) . Évalué à 1.
Ben… Comme le mien de test : je m'attendais à 400-600 Mo/s, j'ai 5-10x moins. Pourquoi? Mystère…
Bref, ce que je voulais dire, c'est que j'ai testé aussi, et j'ai aussi des résultats faibles (et non explicables, du moins facilement), donc le test n'est pas forcément "étrange".
[^] # Re: ZFS est réservé au stockage
Posté par Kerro . Évalué à 2.
Tu as des notes étranges aussi. Je crois que tu as fait des grincheux :-)
[^] # Re: ZFS est réservé au stockage
Posté par Kwiknclean . Évalué à 2.
Inutile d'être "EXPERT" ZFS pour changer un disque, deux lignes de commande et c'est bouclé, justement ZFS est un peu le genre de FS qui s'affranchit d'une quelconque expertise pour l'exploitation.
En revanche j'espère que le Support DELL est disponible au moment de changer la carte RAID et balancer la reconstruction du RAID avec leur outil pourri du genre "omreport" / "omconfig" / "openmanage" … enfin en fonction de la version du Drac et du serveur ce n'est jamais le même outil la reconstruction n'est pas Auto … bref beau plat de nouilles.
Le nombre de carte RAID que j'ai vu cramer sur des clusters … il y a belle lurette qu'on a abandonné les machines physiques à mon taf (avec raison) >> Full ESX, il reste effectivement quelques XEN sur machines physiques avec des belles cartes RAID, et ce sont ces dernières qui nous emmerdent le plus.
Bha sous Ubuntu m'a fallu 30 minutes sur un coup de tête dans un VM VirtualBox pour tester.
[^] # Re: ZFS est réservé au stockage
Posté par MTux . Évalué à 2.
Je suis pas sûr que ton zpool zfs résiste à 2-3 crashs ce qui est assez fréquent sur du desktop.
[^] # Re: ZFS est réservé au stockage
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2.
Ben j'ai testé ça résiste plutôt bien, et même à des paniques du noyau pas mal de fois.
Perso ça doit faire deux ans que j'utilise du ZFS sur mes postes de travails (FreeBSD).
les pixels au peuple !
[^] # Re: ZFS est réservé au stockage
Posté par Kwiknclean . Évalué à 1.
La VM a eu le droit à plusieurs arrêts plutôt brutaux, et je n'ai pas observé de soucis pour redémarrer, cela dit je zpool n'est constitué que d'un seul disque …
[^] # Re: ZFS est réservé au stockage
Posté par Kwiknclean . Évalué à 2.
De toutes façons on hésite très rarement sur des choix entre du ZFS ou du RAID matériel.
Mais plutôt entre de l'archi ZFS ou du SAN Constructeur (Hitachi, Emc …).
Le raid matériel c'est "pratiquement" mort avec la virtu (et c'est tant mieux).
Certes il y a du raid matériel sur ton EMC, mais bon t'en fais pas que le support EMC (ou de ton intégrateur) et le suivi des baies, c'est autre chose que la hotline Dell.
# Question de néophyte
Posté par reynum (site web personnel) . Évalué à 1. Dernière modification le 10 février 2014 à 20:02.
Merci pour cet article plutôt complet et très intéressant.
Petite question : Il me semble que le successeur de ZFS sera BTRFS mais disposera t il de toutes ces fonctionnalités (quand il sera stabilisé) ?edit la réponse à ma question est ci-dessus
kentoc'h mervel eget bezan saotred
[^] # Re: Question de néophyte
Posté par KiKouN . Évalué à 5.
Cela dit en passant, la question n'est pas exacte. Btrfs n'est pas le successeur de ZFS mais le concurrent.
# ashift
Posté par Arcruxe . Évalué à 2.
Attention, en plus d'à la création du pool (zpool create), il faut aussi l'utiliser avec zpool add quand on ajoute un top-level vdev au pool, sinon le nouveau top-level vdev aura la valeur par défaut (9).
# ZFS Le King !
Posté par Kwiknclean . Évalué à 2.
Factuellement,
Depuis que j'y ai goûte il y a un an et que je l'ai "installé" pour gérer mes datas sur mon microserver HP, couplé à une Ubuntu Server + ZFS + LxC ( j'attends encore de voir si je migre vers FreeBSD / Jails / ZFS avec le support from-scratch de ZFS qui rend l'OS pleinement modulable et dumpable), donc depuis que j'y ai coûté, j'ai à chaque fois un sentiment de régression de retour en arrière, lorsqu'il faut bidouiller du MDADM/LVM/EXT4/DRBD … j'ai vraiment l'impression d'utiliser des outils "deprecated" …
On se demande clairement pourquoi ce FS n'est pas un "standard" de fait vu ce que propose la concurrence à côté.
Me concernant LVM, DRBD et tous ces trucs de bricoleurs, c'est TERMINé.
Bon en revanche faut beaucoup, beaucoup de RAM, mais BEAUCOUP.
[^] # Re: ZFS Le King !
Posté par rakoo (site web personnel) . Évalué à 6.
C'est pas standard dans Linux parce que sa licence l'interdit d’être inclus dans le noyau, et que les performances en espace utilisateur ne permettent (permettaient ?) pas de l'utiliser en remplacement d'un FS plus "standard". D’où le développement de btrfs.
[^] # Re: ZFS Le King !
Posté par Zenitram (site web personnel) . Évalué à 4.
Par exemple, sa licence pourrie volontairement non compatible avec Linux.
Et c'est une autre raison ;-).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ZFS Le King !
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2.
C'est aussi valable pour btrfs, la licence pourrie. Du moins pour un standard.
Je dis ça…
les pixels au peuple !
# soucis...
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2.
Ben sous FreeBSD j'ai quand même des soucis sous de l'i386 avec que 2 Go de RAM.
(un vieux laptop). La machine freeze comme quoi le disque est trop lent à répondre (?).
Je n'ai pas eu le temps d'investiguer plus avant.
Je dirais que hors amd64 avec mini 4 Go, ZFS c'est pas vraiment ça. Mais sinon c'est très bien.
les pixels au peuple !
[^] # Re: soucis...
Posté par Zenitram (site web personnel) . Évalué à 4.
Sun (Oracle) dit clairement qu'il faut du 64-bit sinon ils ne promettent rien.
Après, quelle idée de jouer avec un FS moderne sur une machine 32-bit, pourquoi pas 16 bit pendant qu'on y est ;-).
[^] # Re: soucis...
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
C'est quoi ton message exactement ? Ci c'est des truc comme "ad0 … timeout …", il s'agit d'un problème hardware remonté par le driver.
Faire marcher du ZFS sur FreeBSD i386 n'est pas une mince affaire. ce n'est clairement pas prévu pour. Tu peux suivre https://wiki.freebsd.org/ZFSTuningGuide#i386
[^] # Re: soucis...
Posté par Kwiknclean . Évalué à 1.
Hello, tous mes tests ont été effectués sous des OS 64Bits avec à chaque fois entre 1 et 2Go pas plus, dont deux fois sous deux VM VirtualBox … Sans jamais aucun soucis de perf, ha oui sans X évidemment, en mode server, ssh et basta.
Il faut faire attention en revanche à désactiver ou ne pas activer les options exotiques comme la déduplication ou la compression par contre. Parce que dans ce cas en revoir les perfs et la ram :)
Machine de production N54L HP :
(mon N54L qui n'est pas spécialement un foudre de guerre : 2 Go Ram ECC , Turion Dual Core …) :
Mon seul et unique Zpool qu'est pas très gros certes et qui n'a (encore pour l'instant …) qu'un seul disque, mais il y a du DUMP et du Rollback d'effectué.
D'autant plus que j'host des LxC un Varnish-proxy et un nginx/php/mysql avec une base qui commence à être conséquente, en revanche ça commence un peu à swaper dés que l'on fait mumuse avec les snaps et tout … investissement SSD je te vois venir … Et passer à 8Go de Ram pour la machine ne serait pas un luxe surtout si je me mets à acheter du disque.
Sur mes VM VirtualBox de mon pc de bureau :
- VM FreeBSD 10.0 :
Le découpage des slices du zpool, explique à lui seul pourquoi je veux migrer vers cet OS :D et ce nativement à l’installe sans bidouilles ni tuning exotiques, enfin niquel pour un PRA.
Bon en revanche c'est une machine qui ne fait rien du tout.
Sous Ubuntu Server 12.0.4 encore sous VirtualBox :
Cette machine est en fait ma "pre-prod" une VM VirtualBox qui fait du ZFS … si si … avec des conteneurs LxC oui oui : ) 1200Go de Ram sous VirtualBox, Un Coeur CPU.
Encore une fois une machine à genou.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.