Et si la meilleure des cartes RAID était libre ?

96
10
fév.
2014
Technologie

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     0

On 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     0

Un disque peut également être configuré en HotSpare pour remplacer à la volée un disque défaillant :

zpool add tank spare ada12

Il 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 ashift

Commandes 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 pool

On peut ensuite le réimporter :

zpool import pool

Si on a sauvegardé le cachefile :

zpool import pool -c /path/to/cachefile

Maintenance

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      0

zpool 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 rpool

Le 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 ada1

Pour 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 ada13

Il 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/var

On peut ensuite créer des sous volumes :

for i in log spool tmp empty lib; do
    zfs create tank/var/$i
done

Enfin, 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/isos

Pour un volume, il suffit de spécifier la propriété volumesize :

zfs create -V 8G tank/swap

Le volume est alors accessible dans /dev/zvol/tank/swap :

mkswap /dev/zvol/tank/swap
swapon /dev/zvol/tank/swap

On peut aussi faire du thin-provisionning :

zfs create -s -V 100G tank/vm-01-data
zfs set shareiscsi=on tank/vm-01-data

Comme 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 | metadata

Le 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 | disabled

standard 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 | opts

Mais 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_snapshot

L'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          0

Si 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@1

Mais 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_rescue

On 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@1

tank/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_rescue

tank/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,0M

Le 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/linuxfr2

On 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   SNAPSHOT

Bien é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/linuxfr

Ou 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/linuxfr

Et 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-zfs

Et hop ! zfs dans ta Debian :-)

  • # Utilisation en production ?

    Posté par (page perso) . É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 (page perso) . É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

      CNRS & UNIX-Experience

      • [^] # Re: Utilisation en production ?

        Posté par . É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 (page perso) . Évalué à 10.

          D'ailleurs, le titre avait l'air de parler de hardware.

          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 . É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 . É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 (page perso) . Évalué à 2.

              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.

              Je ne pensais pas spécialement aux "adaptateurs", je parlais de CPU et RAM sur la carte.

              Mais bon il faut compter entre 100€ et 200€ du canal pour avoir un produit convenable.

              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 . É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 . É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 . É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…):

                    • demande de copie du fichier => "Les blocks Xxxx,Xxxy,….Xzzz sont faux, à la place utiliser les blocks Yxxx,Yxxy,….Yzzz en lecture"+" Planifier copie des blocs Yxxx,Yxxy,….Yzzz vers Xxxx,Xxxy,….Xzzz"
                    • Modification du nouveau fichier => "Le bloc Xzxy est faux à la place utiliser cache Xaab" + "Anuler copie du bloc Yzxy vers bloc Xzxy"+"Planifier copie du bloc cache Xaab vers bloc Xzxy"
                    • Modification de l'ancien fichier => "mettre en cache dans Xaad le bloc Yzyy" + "Le bloc Yzyy est faux à la place utiliser bloc cache Xaac" + "Le bloc Xzyy est faux à la place utiliser bloc cache Xaad"+"Planifier copie du bloc cache Xaac vers le bloc Yzyy"+"Annuler copie bloc Yzyy vers Xzyy"+"Planifier copie du bloc cache Xaad vers Xzyy"

                    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 . É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 . É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 . Évalué à 0. Dernière modification le 10/02/14 à 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 . É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 . É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é"

                              • [^] # Re: Utilisation en production ?

                                Posté par (page perso) . Évalué à 3. Dernière modification le 10/02/14 à 17:40.

                                Toutes ces caches n'ont plus aucun sens dans le cadre de ZFS/Btrfs. Ceux-ci font tout le nécessaire eux-mêmes. Il vaut d'ailleurs mieux les désactiver totalement. Quand, on écrit sur un disque, on veut juste que cela soit écrit et que le fs global soit cohérent (CoW).

                                Les données sont écrites en batch (snapshot par snapshot, pour garantir la cohérence en permanence) de façon contiguë via CoW, extents.

                                https://calomel.org/zfs_raid_speed_capacity.html

                                ZFS prefers to be in full control of the drives without any interference from drive controllers or caching mechanisms. In order to get the most performance out of ZFS and the LSI card we need to allow direct access to the drives by disabling raid card cache.

                                • [^] # Re: Utilisation en production ?

                                  Posté par . É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é"

                                  • [^] # Re: Utilisation en production ?

                                    Posté par (page perso) . Évalué à 5.

                                    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.

                                    Normal, c'est au disque de garantir que quand tu demandes d'écrire, il écrit !

                                    Ce que zfs/btrf garantissent, c'est que ce qu'ils écrivent est cohérent. Il faut voir cela comme un succession de commit de snapshot. En cas, de crash au milieu d'un commit, tu as toujours le dernier au redémarrage. Le commit de snapshot est atomique !

                                    Quand ce type de fs écrit, il écrit toujours à un emplacement différent (CoW) ce qui signifie que tant qu'il n'a pas fini totalement son opération, il y a toujours les anciennes données. C'est vraiment à la toute dernière opération qu'il dit : éh oh ! Voila le nouveau commit, tu peux changer le pointeur de dernier commit vers celui-là, stp !

                                    Bref, au niveau perfs, pas beaucoup d'impact. Au niveau cohérence, sûreté de tes données, c'est Byzance !

                              • [^] # Re: Utilisation en production ?

                                Posté par . É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 . Évalué à 2. Dernière modification le 10/02/14 à 21:26.

                      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.

                      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 :)

                • [^] # Re: Utilisation en production ?

                  Posté par (page perso) . Évalué à 3. Dernière modification le 10/02/14 à 16:02.

                  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 apportent 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)

                  Pour mettre des chiffres en balance, pour zfs voici des chiffres intéressants : https://calomel.org/zfs_raid_speed_capacity.html . En résumé, la méthode soft poutre de sa maman ours et surtout est très malléable. En ajoutant la compression, tu obtiens des perfs de mamouth, par exemple, compression 2 parités :

                  lz4 7x 2TB raid7, raidz3 7.1 terabytes ( w=507MB/s , rw=436MB/s , r=1532MB/s )

                  Our suggestion is to enabled compression on all arrays because the amount of throughput you gain outweighs the CPU usage and you get to compress data which can save space.

                  • [^] # Re: Utilisation en production ?

                    Posté par . É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 . É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é"

                    • [^] # Re: Utilisation en production ?

                      Posté par (page perso) . Évalué à 3.

                      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.

                      Les systèmes de fichiers de type zfs/btrfs font globalement cela à un niveau différent et de façon, bien plus efficace et robuste dans les cas pratiques :

                      • Les données sont écrites par extents (et donc, il y a réorganisation des demandes) et les données sont écrites de façon contiguës. Les accès concurrents sont donc très bon, la quantité de RAM est le facteur déterminant pour la réorg. mais c'est la même chose pour le hard, excepté que l'ajout de mémoire sur le hard c'est très gruiiik généralement ;
                      • Le CoW garanti, la cohérence des données au niveau FS contrairement au RAID Hard qui le fait au niveau du bloc. On a donc un sécurité plus élevée ;
                      • Les usages, niveau CPU, sont à prendre en compte mais pas du tout un problème majeur, càd on a un usage raisonnable et mettre plus de RAM, cpu a un effet immédiat à moindre coût (A mettre en opposition à la difficulté de le faire en hard) ;
                      • Les restaurations sont beaucoup plus efficaces du fait de la connaissance du fs. Seuls les blocs utilisés sont restaurés ;

                      Je ne serais vraiment pas étonné que la plus part des grosses bababasses de stockage soient, sous le capot, basées sur du software mais dans une blackbox qui empêche de s'en rendre compte.

                      • [^] # Re: Utilisation en production ?

                        Posté par (page perso) . Évalué à 4.

                        Je ne serais vraiment pas étonné que la plus part des grosses bababasses de stockage soient, sous le capot, basées sur du software mais dans une blackbox qui empêche de s'en rendre compte.

                        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 (page perso) . Évalué à 2.

                  c'est pas vraiment une foudre de guerre.

                  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.

          • [^] # Re: Utilisation en production ?

            Posté par (page perso) . Évalué à 10.

            Sommaire

            Le RAID "Hardware" avait une super réputation, 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".

            Le raid hardware a toujours été critiqué mais à une époque pas si lointaine, c'était les seules systèmes viables (Avant l'inclusion massive dans les OSes « grand public »). Aujourd'hui, il y a le choix. pour résumer, avoir, un RAID hard était mieux que rien (Probabilité de perte de donnée réduite). Le raid hardware a toujours eu pas mal de problèmes, les principaux étant :

            • format propriétaire. Cela implique si ton contrôleur grille, il faut trouver un qui supporte le format en question. Générale, c'est carte identique et dans la même version/firmware ;
            • hardware peu testé et implémentation multiples. Il s'agit de cartes très spécialisées, le ratio utilisateur par carte/firmware est très petit (Surtout en comparaison aux versions inclues dans les OSes). L'histoire a montré de très nombreux problème de bug ;
            • les RAID hard n'ont pas connaissance de FS sous-jacent. En cas de failure, les temps de reconstructions peuvent être prohibitifs : les blocs non-utilisés sont également restaurés ;
            • les écritures sont trop souvent sans les garanties d'atomicité et trop souvent en place (Pas de CoW—Copy-on-write). Cela implique que une écriture qui se passe mal (crash) peu laisser le RAID dans un état instable ;
            • clarté des offres. Il est très compliqué de savoir si tel ou tel carte fourni les garanties nécessaires pour pallier aux faiblesses courantes

            Historiquement, le RAID hardware offrait une certaine facilité et une probabilité d'échec réduite et c'est toujours le cas par rapport à rien du tout. Mais aujourd'hui, cette probabilité n'est plus suffisante malgré que cela soit toujours mieux que rien ! Pourquoi la probabilité de problèmes non réparables a grimpé en flèche ? C'est une combinaison de facteurs :

            • la probabilité d'erreur par bit ne s'est pas fondamentalement améliorée ;
            • la qualité des implémentations n'est pas meilleurs ;
            • l'implémentation devient plus complexe avec l'augmentation du nombre de disques de parité ;
            • la taille des disques est bien plus grande ;
            • les temps de restaurations ont grandi.

            Les raid software corrigent la majorité des deux listes précédentes sans aucune dégradation de performance, tout au contraire et offre un paquet d'atouts supplémentaires presque gratuitement.

            Dans les atouts supplémentaires, probablement, que le plus important est l'intégration avec les gestionnaires de volume et les systèmes de fichiers, ce qui nous amène :

            • le CoW ;
            • les snapshots ;
            • les temps de reconstruction réduit ;
            • les ajouts a chaud de volume et d'espace aux fs ;
            • une variété importante dans les choix techniques : choix des algos de détection d'erreur, choix des algo de codage ;
            • des structures de données unifiées (Pour comprendre, l'avantage, je vous invite à lire BTRFS: The Linux B-tree Filesystem)

            post scriptum

            Pour ceux, qui ont des doutes au sujet de la performance des processeurs à créer l'encodage voici un petit rappel théorique des encodages courants (Bon ok, je l'avoue, c'est juste pour le plaisir d'utiliser mon script greasemonkey /o\). Qui mettra en évidence, le fait que c'est totalement à la portée de n'importe quel processeur actuel. Nous passerons sur la réplication qui n'est pas très intéressante.

            (Tout en espérant que je n'ai pas laissé passer trop de coquille /o\ et que les nazi de formel à outrance ne seront pas trop outrés de caractère informel voire carrément faux de ce que j'expose ;-)

            un disque de redondance (Perte de un disque toléré)

            Supposons que nous ayons, n disques de donnée et un pour la redondance. Le disque de redondance est aisément calculé par un xor (\oplus) des autres disques. Pourquoi le \oplus est-il intéressant ? Il possède une propriété très intéressante, il est sont propre inverse ! C'est-à-dire

             a \oplus a = 0 avec 0 étant un élément absorbant unique tel que a \oplus 0 = a = 0 \oplus a

            Wait ! Wait ! Inverse donne zéro ? Oui, il s'agit de l'inverse au sens algébrique. Il faut voir \oplus comme une addition, un peu spéciale. Pour l'addition classique, l'inverse (Appelé communément opposé) de 1 est -1, 2 + (-2) = 0, et en règle générale, n + (-n) = 0. Dans notre cas, l'inverse est l'élément lui-même.

            Soient d_i pour i \in [1,n], les données à encoder (des octets, par exemple, mais cela peut-être n'importe quelle unité), ces données seront réparties respectivement sur les n premiers disques. Le dernier disque sera calculé par calculé par :

            d_{n+1} = d_1 \oplus d_2 \oplus \ldots \oplus d_n

            Pour restaurer, un disque perdu d_j, le processus est symétrique, il suffit de faire un \oplus de données restantes. Pour le montrer, partons de la formule précédente. De part, la propriété des inverses additifs du \oplus, nous obtenons,

            d_1 \oplus d_2 \oplus \ldots \oplus d_n \oplus d_{n+1} = 0

            et par la même propriété,

            d_j = d_1 \oplus \ldots \oplus d_{j-1} \oplus d_{j+1} \oplus\ldots \oplus d_{n+1}

            Voilà, pour une tolérance de l'échec d'un disque :/

            Forme matricielle

            Avant de passer à plus de disque de redondance, nous allons représenter en version matricielle le cas à un disque unique. Cela nous donnera l'intuition pour le cas général. La version matricielle est, tadam :

            \begin{pmatrix}<br/>
1      & 0      & \ldots & 0 \\<br/>
0      & 1      & \ldots & 0 \\<br/>
\vdots & \vdots & \ddots & 0 \\<br/>
0      & 0      & \ldots & 1 \\<br/>
1      & 1      & \ldots & 1<br/>
\end{pmatrix} \begin{pmatrix} d_1 \\ d_2 \\ \vdots \\ d_n \end{pmatrix} = \begin{pmatrix} d_1 \\ d_2 \\ \vdots \\ d_n \\ d_{n+1} = d_1 \oplus d_2 \oplus \ldots \oplus d_n \end{pmatrix}

            Nous voyons immédiatement que la matrice n+1 \times n est composée de 2 parties distinctes I, la matrice identité et une ligne de 1. Par conséquent, la matrice peut être représentée simplement par \left( \frac{I}{\mathbb{1}} \right). La matrice unité conserve les données à l'identique et la ligne de 1 effectue les XOR's.

            On appelle ce type de code, un code systématique du fait de la préservation du code initial.

            Une propriété importante de cette matrice est que la suppression de n'importe quelle ligne, nous donne une matrice inversible (pour rappel, déterminant différent de zéro, à démontre en devoir, hint : placer la ligne de 1, si elle n'est pas la supprimée, à la place de la ligne supprimée et développer… ;-). C'est cette propriété qui nous donne la capacité de de calculer les données initiales à partir des lignes disponibles.

            Prenons, soit A une matrice n+1 \times n et A_i la matrice carrée n \times n composée des lignes de A moins la ième ligne, Si nous perdons la donnée d_i, nous pouvons tout restaurer par

            \begin{pmatrix} d_1 \\ d_2 \\ \vdots \\ d_n \end{pmatrix} = A_i^{-1} \begin{pmatrix} d_1 \\ \vdots \\ d_{i-1} \\ d_{i+1} \\ \vdots \\ d_{n+1} \end{pmatrix}

            Le cas général n disques + k redondances

            Vous l'aurez sûrement deviné, tout l'art, est dans la création de matrices A de dimension n+k \times n tel qu'il soit possible de supprimer k lignes arbitraires, tout en étant capable de restaurer l'affaire. C'est à dire la matrice A_{i_1, i_2, \ldots, i_k} avec k lignes supprimée de A est encore inversible.

            Cela tombe bien de telles matrices existent et sont bien maîtrisées. On peut par exemple citer les matrices de Vandermonde ou de cauchy.

            La complexité de ces processus

            Pour l'encodage, La complexité dépend de la multiplication de matrice par un vecteur, c'est à dire de l'ordre de (n+k) n^2 (Il existe des meilleurs mais très peu pratique pour les tailles de n et k qui nous intéressent).

            Pour le décodage, on doit inverser une matrice et multiplier par un vecteur de taille n. L'inverse d'une matrice de Vandermonde se fait aisément n^2 (il est possible pour les matrice de Vandermonde d'effectuer la multiplication par l'inverse en sub-quadratique mais ce n'est pas pratique dans la vraie vie—càd pas dans la tête de mathématiciens).

            Le XOR est une opération extrêmement rapide. J'ai omis de le mentionner pour simplifier la discussion mais il faut également une multiplication spéciale \otimes. En réalité, il faut un champ fini (S, \oplus,  \otimes) ou S est un ensemble munis de nos 2 opérations. Cette multiplication peut-être aisément calculée efficacement avec une table de logarithme pour des petits champs finis (2⁸ ou 2¹⁶) : log ab = log a + log b. Les processeurs modernes fournissent la multiplication sans report pour les champs plus grands.

            Bibliographie

        • [^] # Re: Utilisation en production ?

          Posté par . Évalué à 10.

          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'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 . Évalué à -3.

            C'est pas faux.

            "La première sécurité est la liberté"

          • [^] # Re: Utilisation en production ?

            Posté par (page perso) . É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 (page perso) . Évalué à 9.

              L'article gagnerait (et ferait moins parti pris) à comparer les solutions.

              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 (page perso) . É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 (page perso) . Évalué à 5.

        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.

        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 . É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 (page perso) . Évalué à 9.

      Est-ce qu'il y a des gens qui utilise ZFS en prod sur des systèmes critiques ?
      

      Oui. 1 Po (réparti sur 4 serveurs) dans un centre HPC.

      Est-ce que l'on peut considérer ZFS suffisamment stable et mature ?
      

      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).

      • [^] # Re: Utilisation en production ?

        Posté par (page perso) . Évalué à 10.

        ZFS en prod sur des systèmes critiques ?
        

        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)

        • [^] # Re: Utilisation en production ?

          Posté par (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 2.

        ça ne plante pas plus pas moins que les SAN "constructeurs" NetApp and Co

        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.

        • [^] # Re: Utilisation en production ?

          Posté par (page perso) . Évalué à 5.

          Je vois des trucs extrêmement chers planter tous les jours… Prix et qualité ne semblent pas du tout corrélé.

        • [^] # Re: Utilisation en production ?

          Posté par . É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 (page perso) . Évalué à 4.

    À 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.

    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 . É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 (page perso) . Évalué à 2. Dernière modification le 10/02/14 à 10:00.

        Il s'agit souvent de batterie au plomb

        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 . É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 (page perso) . É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 . É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 . É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 . Évalué à 4.

        Il faudrait un truc standard dans les PC pour que la tension puisse rester stable ~5s après la coupure du 220V.

        Un portable ?

    • [^] # Re: BBU

      Posté par (page perso) . Évalué à 3.

      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.

      C'est d'ailleurs exactement le principe du ZIL.

      • [^] # Re: BBU

        Posté par (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 2.

        Juste une remarque à propos des BBU : les données sont écrites lorsque l'alimentation revient.
        Donc il est préférable de rallumer rapidement.

        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 ;-)

        car l'OS a pu éteindre la machine avant que tout soit écrit

        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 . É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.

    • [^] # Re: Comparo de RAID logiciels ?

      Posté par (page perso) . Évalué à 4.

      En fait, zfs et btrfs sont comparables. MDADM n'a pas comparable. Ce dernier ne fourni que le RAID au niveau des blocs (Ce n'est pas un FS). Les deux premiers sont des systèmes de fichiers all-in-one avec la gestion du raids, des volumes, checksums, compression, snapshots, et pleins de goodies.

      La zfs et btrfs fournissent globalement les mêmes fonctionnalités et ont les mêmes buts. La différence principale c'est que zfs est prêt pour la prod !

      Sinon au niveau technique, btrfs est original dans le fait que tout est basé sur des b-trees qui supportent le CoW.

      Pour plus de détails p.5 .

  • # Une limitation de ZFS embêtante pour l'utilisateur amateur que je suis

    Posté par (page perso) . É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.

  • # comparaison avec BTRFS

    Posté par . É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…

  • # ZFS

    Posté par (page perso) . É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 . Évalué à 2. Dernière modification le 10/02/14 à 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 (page perso) . Évalué à 6.

      Quand est il à ce jour ?

      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.

      zfs set tank sync=always
      zfs set tank primarycache=none
      

      Du coup, tu as un FS naïf limité par la vitesse des disques

      en tout cas un bien bel article !!!

      Merki

      • [^] # Re: Et la config matériel nécessaire pour ZFS ?

        Posté par (page perso) . Évalué à 4.

        Du coup, tu as un FS naïf limité par la vitesse des disques

        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 . É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 (page perso) . Évalué à 3.

      Quand est il à ce jour ?
      

      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).

  • # Ou presque ?

    Posté par (page perso) . Évalué à 7.

    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).

    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 (page perso) . É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 . É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 (page perso) . Évalué à 10.

      A mon sens ZFS n'est pas comparable à une carte RAID matérielle ni même aux autres systèmes de fichiers.

      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.

      Limite le système y consacre toutes ses ressources.

      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.

      indique un pré requis important : de la mémoire ECC. Ce n'est pas une recommandation, c'est un pré requis

      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.

      part du principe que le serveur ne peut pas tomber en panne

      Non. Tu dois par contre gérer les options de synchro et de cache en fonction de ce risque.

      c'est totalement transparent, et facile à gérer.

      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

      Sinon excellent article,

      Merci

      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

      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 . É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 (page perso) . Évalué à 5. Dernière modification le 10/02/14 à 15:56.

          J'imagine que tu parles d'un test type détection de "collage",

          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 . É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 (page perso) . É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 (page perso) . Évalué à 3.

                Sauf évidemment si par un très un grand hasard les autres disques ont aussi une erreur sur la même donnée…

                Et dans ce cas, tu arrêtes tout et tu testes ta mémoire

              • [^] # Re: ZFS est réservé au stockage

                Posté par . É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 . É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).

        1x 2TB a single drive - 1.8 terabytes - Western Digital Black 2TB (WD2002FAEX)
        
         Asus Sabertooth 990FX sata6 onboard ( w= 39MB/s , rw= 25MB/s , r= 91MB/s )
         SuperMicro X9SRE sata3 onboard      ( w= 31MB/s , rw= 22MB/s , r= 89MB/s )
         LSI MegaRAID 9265-8i sata6 "JBOD"   ( w=130MB/s , rw= 66MB/s , r=150MB/s )
        
        1x 256GB a single drive - 232 gigabytes - Samsung 840 PRO 256GB (MZ-7PD256BW)
         Asus Sabertooth 990FX sata6 onboard ( w=242MB/s , rw=158MB/s , r=533MB/s )
         LSI MegaRAID 9265-8i sata6 "JBOD"   ( w=438MB/s , rw=233MB/s , r=514MB/s )
        

        "La première sécurité est la liberté"

        • [^] # Re: ZFS est réservé au stockage

          Posté par (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 1. Dernière modification le 11/02/14 à 08:39.

            Je trouve effectivement étonnantes les données que tu pointes.

            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 (page perso) . É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 (page perso) . Évalué à 1.

                Bref, ce test est étrange avec certains résultats aussi faibles

                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 (page perso) . Évalué à 2.

      "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à."

      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.

      "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."

      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 . Évalué à 2.

        Bha sous Ubuntu m'a fallu 30 minutes sur un coup de tête dans un VM VirtualBox pour tester.

        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 (page perso) . É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.

          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 (page perso) . É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 (page perso) . É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 . Évalué à 1. Dernière modification le 10/02/14 à 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

    Je ne suis pas un politicien ! J'ai un avenir à créer, pas un passé à défendre !

    • [^] # Re: Question de néophyte

      Posté par . É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 . Évalué à 2.

    Et l'option -o ashift=12 à la commande zpool sous Linux.

    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 (page perso) . É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 (page perso) . Évalué à 6.

      On se demande clairement pourquoi ce FS n'est pas un "standard"

      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 (page perso) . Évalué à 4.

      On se demande clairement pourquoi ce FS n'est pas un "standard" de fait vu ce que propose la concurrence à côté.

      Par exemple, sa licence pourrie volontairement non compatible avec Linux.

      Bon en revanche faut beaucoup, beaucoup de RAM, mais BEAUCOUP.

      Et c'est une autre raison ;-).

      • [^] # Re: ZFS Le King !

        Posté par (page perso) . Évalué à 2.

        Bon en revanche faut beaucoup, beaucoup de RAM, mais BEAUCOUP.
        Et c'est une autre raison ;-).

        De nos jours, on a vite beaucoup de RAM… Chez moi par exemple, ma RAM passe son temp à être vide :

        KiB Mem: 7658908 total, 1585704 used, 6073204 free, 58548 buffers

      • [^] # Re: ZFS Le King !

        Posté par (page perso) . Évalué à 2.

        Par exemple, sa licence pourrie volontairement non compatible avec Linux.

        C'est aussi valable pour btrfs, la licence pourrie. Du moins pour un standard.

        Je dis ça…

        les pixels au peuple !

  • # soucis...

    Posté par (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 2.

      La machine freeze comme quoi le disque est trop lent à répondre (?).

      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 (page perso) . É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 …) :

      System information as of Sun Feb 16 17:39:59 CET 2014
      
        System load:  0.0                Processes:             247
        Usage of /:   0.7% of 227.02GB   Users logged in:       1
        Memory usage: 64%                IP address for br0:  
      

      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é.

      NAME                                      USED  AVAIL  REFER  MOUNTPOINT
      zpool-1                                  7,31G   221G    33K  /zpool-1
      zpool-1/data                               30K   221G    30K  /zpool-1/data
      zpool-1/home                             57,8M   221G  57,3M  /home
      zpool-1/home@25-11-2013                   213K      -  40,5M  -
      zpool-1/home@20-12-2013                   136K      -  40,5M  -
      zpool-1/home@31-01-2014                   138K      -  40,5M  -
      zpool-1/server                           7,25G   221G    30K  /zpool-1/server
      zpool-1/server/lxc_conteneur             7,25G   221G  6,14G  /var/lib/lxc/
      zpool-1/server/lxc_conteneur@20-12-2013   293M      -  4,69G  -
      zpool-1/server/lxc_conteneur@07-02-2014   189M      -  6,13G  -
      zpool-1/zfs-dump                           32K   221G    32K  /zpool-1/zfs-dump  
      

      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.

         mathieu@cube-box:~$ free
                       total       used       free     shared    buffers     cached
          Mem:       1921224    1523652     397572          0      32028     264356
          -/+ buffers/cache:    1227268     693956
          Swap:      1961980       1064    1960916
      

      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.

      [mathieu@freebsd ~]$ zfs list -t all
      NAME                         USED  AVAIL  REFER  MOUNTPOINT
      zroot                       5.88G  6.80G   144K  none
      zroot/ROOT                  2.27G  6.80G   144K  none
      zroot/ROOT/default          2.27G  6.80G  2.27G  /
      zroot/tmp                    200K  6.80G   200K  /tmp
      zroot/usr                   3.31G  6.80G   144K  /usr
      zroot/usr/home               129M  6.80G  45.3M  /usr/home
      zroot/usr/home@31-01-2014    144K      -  43.9M  -
      zroot/usr/home@now          83.3M      -   127M  -
      zroot/usr/jails             2.36G  6.80G  2.36G  /usr/jails
      zroot/usr/jails@jails-now     88K      -   144K  -
      zroot/usr/jails@snapshot-2    88K      -   144K  -
      zroot/usr/ports              837M  6.80G   837M  /usr/ports
      zroot/usr/src                144K  6.80G   144K  /usr/src
      zroot/var                    306M  6.80G   305M  /var
      zroot/var/crash              148K  6.80G   148K  /var/crash
      zroot/var/log                380K  6.80G   380K  /var/log
      zroot/var/mail               152K  6.80G   152K  /var/mail
      zroot/var/tmp                152K  6.80G   152K  /var/tmp
      

      Bon en revanche c'est une machine qui ne fait rien du tout.

      last pid:  1408;  load averages:  0.39,  0.38,  0.21               up 0+00:06:19  16:55:15
      29 processes:  1 running, 28 sleeping
      CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
      Mem: 15M Active, 18M Inact, 56M Wired, 892M Free
      ARC: 33M Total, 11M MFU, 21M MRU, 16K Anon, 263K Header, 1319K Other
      Swap: 2048M Total, 2048M Free
      

      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.

      Welcome to Ubuntu 12.04.3 LTS (GNU/Linux 3.8.0-29-generic x86_64)
      
       * Documentation:  https://help.ubuntu.com/
      
        System information as of Sun Feb 16 18:00:19 CET 2014
      
        System load:  0.04              Users logged in:       1
        Usage of /:   25.1% of 8.45GB   IP address for br0:    192.168.0.14
        Memory usage: 9%                IP address for br1:    192.168.56.101
        Swap usage:   0%                IP address for lxcbr0: 10.0.3.1
        Processes:    237
      
      
      mathieu@ubuntu-serveur:~$ sudo zfs list -t all
      [sudo] password for mathieu:
      NAME                           USED  AVAIL  REFER  MOUNTPOINT
      zpool-1                       2,55G  7,24G   822M  /zpool-1
      zpool-1/data                  1008M  7,24G  1008M  /zpool-1/data
      zpool-1/data/photos             30K  7,24G    30K  /zpool-1/data/photos
      zpool-1/etc                     30K  7,24G    30K  /zpool-1/etc
      zpool-1/home                  35,2M  7,24G  35,1M  /home
      zpool-1/home@24-11-2013        139K      -  35,1M  -
      zpool-1/lxc_conteneur           30K  7,24G    30K  /zpool-1/lxc_conteneur
      zpool-1/restau                  30K  7,24G    30K  /zpool-1/restau
      zpool-1/test                    30K  7,24G    30K  /zpool-1/test
      zpool-1/www                    740M  7,24G   664M  /var/www
      

      Encore une fois une machine à genou.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.