La version 0.6.3 de ZOL (ZFS On Linux) vient fraîchement d'être mise à disposition. Bien que n'ayant que peu communiqué (sur la liste de discussion en tout cas), depuis la dernière version sortie en août 2013, les développeurs du projet n'ont pas chômé puisqu'il y a eu près de 200 corrections de bugs et de nombreuses fonctionnalités ajoutées au projet avec notamment : la compatibilité pour les noyaux Linux <= 3.14, la comptabilité avec les ACL POSIX et un nouvel outil de supervision dédié le ZED daemon.
Fonctionnalités clés :
- Compatible avec les noyaux Linux jusqu'à la version 3.14.
- Meilleure gestion du ralentissement en écriture pour maintenir les performances lors d'un forte charge.
- Cache plus intelligent pour améliorer le taux d'accès à certains niveaux de charges.
- Gestion des ACL type Posix.
- Gestion des attributs immutable : les ajouts seuls sur les fichiers.
- Possibilité de monter les systèmes de fichiers avec mise à jour à chaud.
- Intégration SELinux à travers quatre nouveaux ensembles de propriétés.
- Support de systemd.
- Apparition du ZFS Event Daemon (ZED) pour gérer et surveiller.
- Gestion des architectures arch64 et sparc64.
- Beaucoup d'amélioration de performances.
- Plus de 200 bug corrigés.
Aller plus loin
- ZFS On Linux (546 clics)
- ZFS Illuminos Projet (117 clics)
- ZFS On Debian GNU/Linux [How To] (162 clics)
- ZFS On Linux COPYRIGHT (53 clics)
# Compatibilité avec le noyau Linux
Posté par windu.2b . Évalué à 5.
Entre le premier paragraphe, qui parle des
noyaux Linux >= 3.14et la liste des fonctionnalités-clés, qui parle des noyaux,jusqu'à la version 3.14, il y a un problème !Qui a raison ? Et, dans tous les cas, peut-on savoir ce qui causait une telle limite ?
[^] # Re: Compatibilité avec le noyau Linux
Posté par FRLinux (site web personnel) . Évalué à 1.
Les points de l'annonce viennent du mail de la liste de diffusion annoncant la sortie de 0.6.3 [1] et stipule tres clairement "Compatible with kernels up to Linux 3.14". Donc jusqu'au kernel 3.14, apres a mon avis faut prendre une version git.
[1] https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-announce/Lj7xHtRVOM4
[^] # Re: Compatibilité avec le noyau Linux
Posté par Kwiknclean . Évalué à 2.
Oui tout à fait erreur, d’interprétation de ma part et c'est apparemment passé à la trappe lors de la relecture il s'agit des noyo <= 3.14 et pas l'inverse ;).
Soi dit en passant l'intégration avec Systemd qui fait aussi partie des nouveautés.
[^] # Re: Compatibilité avec le noyau Linux
Posté par NeoX . Évalué à 3.
c'est corrigé
# En prod
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Cela donne quoi ? Quelqu'un l'utilise sur des gros volumes via des baies SAN montés en JBOD par exemple ?
[^] # Re: En prod
Posté par Kwiknclean . Évalué à 6. Dernière modification le 15 juin 2014 à 13:42.
Un de nos clients s'en sert pour présenter du NFS à des ESX sur une infra supermicro + Ubuntu 12.04 + ZFS 0.6.2 avec environ 5 ou 6T de data et une bonne 20aine de VM.
Avec un disque SSD pour le cache et 32 Go de RAM et des disques SATA (basses perfs donc) de type Western Digital Raid (on doit changer à peu près un disque tout les deux à trois mois) : Ça fonctionne correctement.
On se sert des snapshots pour la sauvegarde restauration, ce qui est plutôt efficace (bien plus que de s'emmerder avec un soft de sauvegarde type Netbackup).
Le seul soucis que l'on a vient apparemment du hardware supermicro qui n'est pas VMWare Certified, du coup en cas d'appel vers le support ce dernier nous rit un peu au nez … à part ça, ça fait son boulot.
En revanche je ne saurais dire si les perfs auraient été équivalentes/supérieurs avec du stockage proprio type EMC / NetApp … à un tarif autrement différent. Le soucis étant que pour le coup avec cette solution y a peu d'outils pour monitorer/bencher produire du reporting du graphe, latence NFS, Fibre .. peut être que ZED change un peu la donne.
Pour la prod je pense que c'est OK depuis la 0.6.1 (fin des RC), le fait que nous soyons encore en numéro < 1 ne signifie pas que le projet est Beta mais que la Roadmap de développement est ambitieuse (faire plus que ce que proposait nativement ZFS sour Solaris).
Au fait Illuminos participe également au développement ZFS sous FreeBSD qui est (si je ne m'abuse), le FS par défaut sur la 10.0 qui est tout sauf une distribution "not production ready".
Voir premier chapitre.
On me demanderait de monter du projet stockage, je réfléchirai à plusieurs fois avant d'acheter du EMC/NetApp/Hitachi …
[^] # Re: En prod
Posté par Loïc Blot (site web personnel) . Évalué à 3.
Hello,
Ce n'est pas le FS par défaut sous FreeBSD 10.0, mais il est intégré dans l'installeur, et permet de lancer un système hébergé complètement sur du ZFS (auparavant il fallait faire ca en shell depuis l'installeur).
ZFS a un potentiel et un nombre d'OS libres autour de lui assez conséquent (BSD, Solaris, Linux), il pourrait facilement écraser BTRFS vu la communauté derrière
Veepee & UNIX-Experience
[^] # Re: En prod
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
On trouve des serveurs supermicro avec 36 disques (voir même 72 mais je n'aime pas). Avec des disques de 4To, on est très au dessus des chiffres que tu donnes. Est-il raisonnable de mettre du ZFS sous GNU/Linux la dessus ?
Je sais très bien que les BSD ont un meilleur support de ZFS (par licence) mais ZFS sous Linux est-il près pour la prod ?
[^] # Re: En prod
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 16 juin 2014 à 08:22.
Tu voulais dire "P"? T c'est pour TéraOctet, et 6 To c'est 4 disques d'aujourd'hui en RAIDZ2, soit rien pour savoir si "ça marche". Bref on stocke ça en 1U, la "baie" est vide avec ça :)
Si un FS ne sait pas gérer 6 To de nos jours, ça serait un peu génant ;-).
Pas que le retour soit ininteressant, mais si T c'est pour TéraOctet, il faut bien être conscient que 6 To c'est du pas grand chose en 2014, ça se loue pour moins de 100€/mois chez certains hébergeurs.
Après, ça tu ne le fais pas pour 6 To de data non plus ;-).
Ca serait interessant d'avoir des retours pour du SAN genre au mini 36 disques de 4 To dans un serveur SuperMicro 4U (120 To utiles) ou une baie à taille qui commence à être sympa (genre 1 Po) et quelques centaines d'instances de VM pour voir comment ça se passe dans un environnement qui se charge un peu. Les retours que j'ai tendance à lire sur ce genre de matos parlent plus de BSD que de Linux.
Pour combien de disques utilisés? Ca serait combien, pour la même charge, de disque pour des disques "Entreprise"? Un chiffre comme ça ne dit pas si c'est cormal ou pas.
[^] # Re: En prod
Posté par Kwiknclean . Évalué à 5.
La question n'est pas sur la taille de la volumétrie, mais la capacité de disponibilité de cette dernière.
6To de data (utile) à 100€/euros par mois, je veux bien mais avec quelles genre de sécurités ? Quel Niveau de RAID ? Redondance, Double, triple, avec réplication topologie Fabric (la ton DSI vient de transpirer à cause du tarif), Alimentation redondée ? Combien de disques de Spare ? Quel Niveau de service pour le changement d'un disque ? Réactivé sous 4H lors du claquage d'un disque ? A mon avis rien de tout ça, un disque ou deux en Raid 1 et c'est tout : 6To de Stockage avec tout ça, c'est lourd même en 2014 …
Il y a une petite différence entre de la volumétrie "NAS" qui est sensée garantir une très haute disponibilité, limite, paranoïaque et du stockage disque lambda sur une machine physique sans sauvegarde (et la sauvegarde ça pèse lourd en UO), si tu veux de la perf oublie le SAN, achète un Dell R715 avec une dizaine de disques SAS 15K (ou SSD si t'as du fric) et laisse le bon vieux LVM / EXT4 et la carte RAID Dell (si t'es confiant) s'occuper de tout ça, prévoit quand même un bon budget sauvegarde, les perfs exploseront n'importe quelle solution SAN.
Je ne suis pas inquiet concernant la capacité de ZFS à s'occuper de PetaOctet de fichiers (Jusqu'a Zeta comme son nom l'indique).
Concernant l'infra de notre client cité en exemple, c'est clairement du lowcost (Déjà Supermicro Bon ça fait un peu rire …) avec du disque SATA et ses fabuleux 10 i/o secondes …, on ne fait pas de RAIDZ , mais du pool Mirroring façon RAID10, pour ne pas charger le CPU avec le calcul de la parité, pas non plus de compression (du moins je ne crois) au fait la / les baies (car c'est répliqué sur nos deux salles via Gigabit ou FC je ne sais plus), pour "uniquement" 20To Utiles, (et non pas 6 comme indiqué) c'est pas lourd, mais faut bien la servir H24, puis le client à pas besoin de 50 Peta de stockages non plus, tout le monde n' a pas l'infra d'Orange, ou Total ;) Pis si le client avait eu des sous, il aurait acheté un FAS2240 en SAS 15K mais là on change encore de grille tarifaire … ;)
Sinon faut quand même faire attention à bien tuner ta conf ZFS, car en cas de "low memory" la Ubuntu va se charger elle même de libérer de l'espace en mémoire et elle ne se prive pas, elle purge, que ça soit les daemons de supervision ou le daemon d'export NFS .. elle purge …
Tout ces disques pour "uniquement" 21 To ..
Je ne mets pas les autres mountpoint de l’agrégat ZFS pour des raisons évidentes ;)
Bha oui il a tout mangé le cochon de ZFS …
[^] # Re: En prod
Posté par Olivier Jeannet . Évalué à 4.
J'ai un ami qui se sert de ZFS à la fois sous Linux et sous OpenSolaris. Son usage le plus avancé est avec une version spéciale d'OpenSolaris qui tient sur 200 ou 400 Mo et qui permet d'héberger des VM Xen/KVM. Il fait du miroir (via ZFS) et du RAID entre 2 baies de disques, chacune contenant 48 disques de 2 To, et le tout est caché (via ZFS) par des disques SSD grand public (comme ils ne servent qu'en cache de lecture on peut prendre un modèle moins robuste qu'un SSD entreprise).
Il est un utilisateur enthousiaste de ZFS et de ses fonctions, dont le contrôle d'intégrité des données (vital selon lui pour des volumes de dizaines de To, des erreurs sont détectées), les snapshots, et la possibilité d'envoyer en temps réel un shapshot vers un autre ZFS (parfait pour la synchronisation entre 2 baies).
[^] # Re: En prod
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
On ne doute pas de ZFS sous BSD et Solaris (et dérivées), ni de son intérêt, mais on aimerait un retour d'expérience sous GNU/Linux sur une grosse configuration. C'est quand même le titre principal du billet.
[^] # Re: En prod
Posté par AceSlash . Évalué à 7.
Nous utilisons ZOL en prod depuis environs 6 mois. Au niveau volume pour donner une idée nous avons 7 serveurs différents avec:
Bon certes ce ne sont pas des volumes gigantesque mais cela nous donne tout de même une bonne idée du comportement. À noter que j'utilise zfs depuis des années sous Solaris, donc je connais un peu :)
Pour moi ZOL est tout à fait utilisable en production, les performances sont bonnes, on a parfois des gains conséquents dans certains cas notamment grâce à la compression (diminution de la quantité de données lu sur le disque). Les snapshot sont évidemment une fonctionnalité toujours aussi utile, à noter que l'on peut envoyer un volume vers un autre serveur si on a besoin de synchroniser ou de déplacer des données (on peut envoyer des snapshot de façon incrémental aussi, si l'on a pas vraiment besoin d'un système de fichier clusterisé, c'est très efficace pour des backups réguliers sur plusieurs machines).
Enfin sans refaire la liste des fonctionnalités, je trouve que les performances sont excellentes tant que l'on règle un minimum les volumes selon les besoins (pour les bases de données par exemple, il faut penser à régler le recordsize, 8K pour postgres et 16K pour mysql avec un primarycache en metadata).
Il faut aussi penser à diminuer la mémoire alloué à l'ARC si l'on souhaite utiliser le serveur pour autre chose que du stockage pur.
Ce qui me manquait le plus était la gestion des ACL posix, là j'ai mis à jour un serveur en 0.6.3 et je vais tester cette fonctionnalité, à noter que lorsque l'on met à jour depuis la 0.6.2, il faut prévoir un reboot après (les volumes restent accessibles normalement mais les outils zpool et zfs ne voient plus le pool, ce qui bloque toutes les opérations de maintenance/monitoring et les zfs send/receive).
Après niveau prod, j'ai changé plusieurs fois des disques sans problèmes même si sur ce point, j'ai l'impression que c'est un peu long, dernier exemple sur un des pool de 32.5TB en RAIDZ2 avec des disques SATA 3TB avec un pool utilisé avec 19/32.5 au moment du rebuild :
resilvered 1.54T in 79h12m with 0 errors on Fri May 16 00:15:42 2014
Après il faut relativiser car le pool est utilisé pendant le rebuild.
Si vous avez des questions plus précises, je ferai de mon mieux pour y répondre.
[^] # Re: En prod
Posté par Kwiknclean . Évalué à 1.
He .. le titre principal du billet c'est simplement l'annonce de la nouvelle version de ZOL … je peux me tromper toutefois, je ne suis que le contributeur.
[^] # Re: En prod
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 2.
Ça marche. Et plutôt bien.
Mon application courante est "serveur de /home NFS". J'ai 5~6 serveurs (sur base dell r720xd + MD1200) pour ~ 500 users, dans une configuration HPC.
Ma plus grosse machine est un r720xd 48T + 2x MD3060e : 528To bruts sur 132 disques. Avec le raidz je reviens à ~400To utilisable. Ça juste fonctionne trés bien.
Perso, on m'offrirai deux barils d'Omo-ext4, Dash-xfs ou Paic-lvm, je n'échangerais pas contre mon Bonux-zfs.
Proverbe Alien : Sauvez la terre ? Mangez des humains !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.