Quelles sont les implications en termes de performances de l'exécution de VM sur un hôte ZFS?

J'envisage de migrer de ext3 vers ZFS pour le stockage de données sur mon hôte Debian Linux, en utilisant ZFS sur Linux . Une caractéristique de ZFS que je veux vraiment est ses garanties d'intégrité des données. La possibilité de développer trivialement le stockage à mesure que mes besoins de stockage augmentent est également quelque chose que j'attends avec impatience.

Cependant, j'exécute également quelques machines virtuelles sur le même hôte. (Bien que normalement, dans mon cas, une seule machine virtuelle s'exécute sur l'hôte à la fois.)

Compte tenu de la somme de contrôle des données de ZFS et du comportement de copie sur écriture, ainsi que du fait que les images de disque de machine virtuelle sont des fichiers relativement volumineux (le fichier d'image de disque de ma machine virtuelle principale se trouve actuellement à 31 Go), quelles sont les implications en termes de performances à l'intérieur de l'invité VM de telles une migration? Quelles mesures puis-je prendre pour réduire l’impact négatif possible sur les performances?

Je peux vivre avec moins de garanties d'intégrité des données sur les images de disque VM si nécessaire (je ne fais rien de vraiment critique à l'intérieur des VM) et je peux facilement les séparer du reste du système de fichiers, mais ce serait bien si je ne pas besoin (même sélectivement) de désactiver à peu près la fonctionnalité qui me donne le plus envie de migrer vers un autre système de fichiers.

Le matériel est assez costaud pour un système de classe poste de travail, mais ne tiendra pas grand-chose à un serveur haut de gamme (32 Go de RAM avec rarement> 10 Go en cours d'utilisation, processeur 6 cœurs 3,3 GHz, actuellement 2,6 To utilisable l'espace disque selon dfet un total d'environ 1,1 To libre; la migration vers ZFS ajoutera probablement un peu plus d'espace libre ) et je ne prévois pas d'exécuter la déduplication des données (car l'activation de la déduplication n'ajouterait pas grand-chose dans ma situation). Le plan est de commencer avec une configuration JBOD (évidemment avec de bonnes sauvegardes) mais je pourrai éventuellement passer à une configuration miroir bidirectionnelle si les conditions le justifient.

Étant donné que ZFS fonctionne au niveau du bloc, la taille des fichiers ne fait aucune différence. ZFS nécessite plus de mémoire et de CPU mais n'est pas intrinsèquement beaucoup plus lent en tant que système de fichiers. Cependant, vous devez être conscient que RAIDZ n'est pas équivalent en vitesse à RAID5. RAID10 est bien où la vitesse est une priorité.

ZFS sur un matériel décent (c'est-à-dire buff) sera probablement plus rapide que les autres systèmes de fichiers, vous voudrez probablement créer un ZIL sur un emplacement rapide (c'est-à-dire SSD). Il s'agit essentiellement d'un emplacement pour mettre en cache les écritures (enfin, plus comme un journal dans ext3 / 4). Cela permet à la boîte de dialogue d'écriture d'être écrite sur le disque avant que les broches réelles n'aient les données.

Vous pouvez également créer un ARC L2 sur SSD pour le cache de lecture. C'est fantastique dans un environnement de machine virtuelle où vous pouvez mettre les disques physiques à genoux en démarrant plusieurs machines virtuelles en même temps.

Les lecteurs vont dans les VDEV, les VDEV vont dans les zpools (veuillez utiliser des disques entiers à la fois). S'il s'agit d'un système plus petit, vous voudrez peut-être avoir un seul zpool et (si vous n'êtes pas trop préoccupé par la perte de données) un seul VDEV. Les VDEV sont l'endroit où vous sélectionnez le niveau RAID (bien que vous puissiez également MIROIR les VDEV si vous avez suffisamment de disques). Le disque le plus lent d'un VDEV détermine la vitesse de l'ensemble du VDEV.

ZFS concerne l'intégrité des données - la raison pour laquelle de nombreux outils traditionnels pour la maintenance du système de fichiers n'existent pas (comme fsck) est le problème qu'ils résolvent ne peut pas exister sur un système de fichiers ZFS.

OMI, le plus gros inconvénient de ZFS est que si vos systèmes de fichiers approchent à 100% (par exemple 75% +), cela devient TRÈS lent. N'y allez pas.

31 Go n'est vraiment pas gros du tout ...

Quoi qu'il en soit, selon le système de fichiers que vous utilisez actuellement, vous pouvez trouver que ZFS est légèrement plus lent, mais compte tenu de vos spécifications matérielles, il peut être négligeable.

De toute évidence, ZFS utilisera une bonne partie de la RAM pour la mise en cache, ce qui peut rendre vos machines virtuelles plus «rapides» en utilisation générale (lorsqu'il ne fait pas de lecture ou d'écriture intensives). Je ne sais pas comment ZFS est réglé sur Linux, mais vous devrez peut- être limiter son ARC, si possible, pour l'empêcher de fonctionner avec toute votre RAM (car vous voudrez un morceau décent restant pour votre système hôte et VM).

J'activerais la compression (le conseil de nos jours est de l'activer sauf si vous avez une bonne raison de ne pas le faire). N'oubliez pas que cela doit être fait avant de mettre des données sur le système de fichiers. La plupart des gens sont surpris de constater que c'est en fait plus rapide avec elle, car les algorithmes de compression s'exécuteront généralement plus vite que les disques IO. Je doute que cela cause beaucoup de problèmes de performances avec votre processeur 6 cœurs. Je ne m'attendais pas à ce que les machines virtuelles compressent beaucoup, mais j'ai réussi à transformer ~ 470 Go de données de machines virtuelles en 304 Go uniquement avec le paramètre de compression par défaut.

Ne vous embêtez pas avec la déduplication, elle reviendra juste vous hanter plus tard et vous passerez des semaines à mélanger les données pour essayer de vous en débarrasser.

Si vous rencontrez des problèmes de performances, la réponse évidente consiste à ajouter un SSD en tant que ZIL / L2ARC ou même les deux. Il n'est pas idéal d'utiliser un seul appareil pour les deux, mais cela améliorera très probablement les performances sur un pool contenant un petit nombre de disques / vdev.

Pour ajouter: j'essaierais vraiment de commencer avec une configuration redondante si possible (idéalement des miroirs), ou de convertir en miroirs à partir d'une bande dès que possible. Bien que ZFS totalisera toutes les données et détectera les erreurs à la volée (ou lors d'un scrub), il ne pourra rien y faire (sans utiliser copies = 2 qui doublera l'utilisation du disque). Il vous restera juste à vous dire qu'il y a des erreurs dans les fichiers (probablement vos images de disque VM) que vous ne pourrez pas faire beaucoup sans supprimer et recréer ces fichiers.

Selon vos cas d'utilisation et vos machines virtuelles, je considérerais ce qui suit. Laissez le système d'exploitation hôte s'occuper des fichiers que vous stockez sur les volumes ZFS.

Si possible, créez juste un LUN pour chaque VM, contenant uniquement le système d'exploitation et les fichiers binaires nécessaires. Et présentez le stace de stockage pour les données individuelles sous forme de partages via NFS, samba ou iSCSI (ou zvols comme mentionné dans les commentaires). ZFS est capable de garder une trace de chaque fichier avec une somme de contrôle et des temps d'accès ect. Bien sûr, si la vitesse n'est pas si importante, vous pouvez également activer la compression sur certaines banques de données. L'avantage serait une couche manquante d'un autre système de fichiers. Si vous créez un LUN pour le deuxième disque dur virtuel et créez un système de fichiers NTFS sur celui-ci, ZFS doit gérer un gros blob binaire et ne connaît aucun contenu ou fichier, et ne peut donc pas profiter du cache ZIL ou ARC dans de la même manière que les fichiers d'avion.

Mentionnant les ACL, ZFS est capable d'utiliser les ACL via NFSv4 ou Samba (si activé). Je dois admettre que j'utilise ZFS sur FreeBSD, et je ne peux pas garantir comment activer les listes de contrôle d'accès Sambas sur les volumes ZFS. Mais je suis sûr que cela ne devrait pas être un gros problème.

La déduplication en combinaison avec un cache de lecture est un gros avantage pour économiser de l'espace et améliorer les lectures massives (tempête de démarrage) car toutes les machines virtuelles commencent à lire les mêmes blocs.

Il en va de même pour les instantanés ZFS pour les machines virtuelles et les banques de données. Vous pouvez créer un script shell simple, pour figer la machine virtuelle, prendre un instantané de la machine virtuelle et du magasin de données et continuer à travailler, ou simplement le magasin de données seul, et cloner la machine virtuelle pour présenter l'instantané de l'original et tester certaines choses.

Les possibilités sont infinies avec ZFS;)

EDIT: J'espère que je l'ai expliqué un peu mieux maintenant

EDIT2: Opinion personnelle: pensez à utiliser un RAIDZ2 (RAID6) car vous pouvez résister à une double panne de disque! S'il ne vous reste qu'un seul disque de rechange, ce ne sera jamais un problème, mais deux pannes de disque devraient suffire pour une analyse rapide. Je viens de poster mon script pour surveiller l'état du disque ici