Au début novembre 2013, nous avons déployé nos deux nouveaux NAS, Charybde et Scylla. Nous stockons les disques de nos machines virtuelles sur nos NAS.Il s'agit donc d'un de nos équipements les plus sensibles.

Nous avons souhaité garder ZFS. Nous avions par ailleurs rencontré des problèmes de drivers NFS, et avons du vivre avec des latences de l'ordre de 100ms en moyenne. Autant dire qu'une partie des limitations rencontrées nous semblaient matérielles (d'où l'achat de nouvelles machines), mais nous pensons aussi qu'il y a moyen de s'en tirer à meilleur compte en jouant aussi sur l'aspect logiciel.

Nous stockons les disques de nos machines virtuelles sur le NAS via NFS, comme dit précédemment. Il en découle déjà un certain nombre de points :

1. Les benchmarks ZFS classiques ne nous intéressent au final qu'assez peu, étant donné qu'elles ne prennent pas en compte la couche NFS.
2. Nous chercherons à diminuer le temps d'accès disque des machines virtuelles afin d'augmenter les performances. Nous jouerons donc sur la latence sur du NFS.
3. Enfin, nous devons tenir compte que nous avons (à l'heure actuelle) 70 machines virtuelles en production réparties sur 3 machines physiques. Nous essayerons donc de voir quelles sont les performances lorsque le NAS sera “stressé”.
4. Nous souhaitons aussi de plus évaluer les pertes de performances liées à des écritures synchrones sur du NFS.
5. Nous souhaitons aussi constater l'impact (bon ou mauvais) de certain features de ZFS tels que la compression sur les performances.
6. De même nous nous pencherons sur l'influence de la déduplication.
7. Enfin, nous verrons l'importance de la manière de constituer notre pool.

Nous n'avons retenus que certains OS. Tout d'abord, nous recherchions si possible quelque chose de libre.

Nexenta a été mis hors course car il n'était pas capable de gérer le controlleur SAS du NAS.

ZFS sous Linux a été écarté pour cause de mauvaises performances ZFS (tous les benchmark ZFS le situent en dessous)

Notre choix s'est donc porté sur FreeNas (l'implémentation de FreeNas se montre plus robuste que celle de FreeBSD…) et OpenIndiana.

Nous cherchons donc à obtenir les latences, et ce pour différentes tailles de fichiers, et tailles de blocks d'écriture.

Nous allons pour celà utiliser un petit programme Linux, iozone que nous lancerons sur nos points de montage NFS afin de mesurer leurs performances.

iozone est très simple d'utilisation et permet d'exporter le résultat sous un format Excel (donc lisible depuis Libre Office). On peut ainsi faire très simplement de beaux graphismes. Il possède de plus un mode automatique qui balaye l'ensemble des valeurs permises.

Je vous laisse vous reporter à la documentation.

ioping n'est pas aussi bien automatisé que iozone mais il permet de faire des tests sur des fichiers plus petits.

Des tests préliminaires avec iozone sur des disques en local montrent que :

1. Les valeurs des résultats varient d'à peu près 10% d'une machine à l'autre
2. La tendance et l'allure des résultats dépend fortement d'un machine à l'autre
3. Entre deux tests réalisés sur une même machine, les valeurs présentent en moyenne un écart de 3%
4. Et au pire de 10%
5. Néanmoins les tendances restent les mêmes sur la même machine.

On en conclut que les mesures doivent êtres effectuée avec toujours la même machine, et qu'il faudra retenir que:

1. On se fiera aux tendances des résultats et non à une mesure en particulier
2. On retiendra qu'un écart inférieur à 3% n'est pas significatif

On mesurera pour chacun des deux systèmes d'exploitation :

1. les débits et latences en écritures asynchrones
2. les débits et latences en écritures synchrones (pour le choix des options ZFS)

Nous réaliserons ces mesures :

1. Avec le NAS à vide
2. Avec le NAS stressé par une tierce machine, à l'aide de :

  dd if=/dev/urandom of=plip bs=1 count=10000000000

Et avec pour certaines de ces mesures, la compression activée sur le NAS…

Nous utilisons deux serveurs identiques pour nos tests :

Ce sont des Dells R515, muni de 32GB de RAM, avec un link aggrégation de 4 liens Gigabits. Ils ont de plus comme processeurs un AMD Opteron™ 4386, 8c, 3.1 Ghz…

La machine de test et celle de stress sont des SUNs: 4Go de RAM, 2 coeurs, à 2.3 Ghz (AMD Opteron™ Processor 250)

Nous avons deux disques sytèmes de 500GB. Le pool sera en raidZ. Il est constitué de 7 disques Western Digital caaviar black de 2 To. Deux samsung PRO de 128GB sont utilisés en log, mirroré, et un en cache.

Voila les résultats tant attendus !!! Les graphiques suivants représentent les latencess pour réaliser une opération. En abscisse se trouve la taille du fichier, en ordonnée la latence en microsecondes.

Pour les lectures séquentielles :

Pour les écritures séquentielles :

Pour les lectures aléatoires :

Pour les écritures aléatoires :

Avec la synchronisation : écritures séquentielles :

Avec la synchronisation NFS sur un dataset non synchronisé : écritures aléatoires :

En écritures séquentielles :

En écriture aléatoires :

Voici donc les conclusions que nous pouvons en tirer :

• OpenIndiana et FreeNas sont équivalent pour les lectures séquentielles sur de petits fichiers
• OpenIndiana est moins bon que FreeNas sur les lectures séquentielles de grands fichiers
• OpenIndiana est bien meilleur en écritures séquentielles et aléatoires, asynchrones.
• OpenIndiana et FreeNas sont équivalents en lecture aléatoire.
• OpenIndiana est très légèrement moins bon pour les écritures synchrones.

Nous avons réalisé des tests de performances pour deux algorithmes de compressions utilisés potentiellement par ZFS : lz4 et lzjb.

Les performances sont équivalentes avec celles obtenues synchronisation désactivée (je vous laisse regarder les tableaux Excel en annexe pour vous en persuader).

Voici les taux de compressions obtenus :

Le fait que la compression ne fasse pas perdre de performance vient du fait que nos processeurs sont clairement “over-kills”. On n'observe néanmoins pas de réelles améliorations de stats comme on peut le lire par endroit.

La synchronisation du dataset s'avère fatale pour les petits fichiers (opérations synchrones sur un système de fichier gérant les opérations synchrones). En effet, les pertes en écriture pure sont énormes : les latences sont entre 10 fois (pour les gros fichiers) et 20 fois (pour les petits) plus élevées que pour des opérations asynchrones sur un système de fichier asynchrone. Les performances en écriture sont encore plus dégradées (facteur 100 par endroit) Les performances en lecture ne sont pas affectées.

Quelques graphes illustreront mon propos. Je vous laisse chercher les autres dans les annexes.

Faire des opérations asynchrones sur un système de fichier gérant les opérations synchrones n'a pas d'effet sur les performances en écriture. De même quand le NAS est stressé,les écritures faites pour le stresser sont asynchrones, donc logiquement nous obtenons les mêmes résultats.

Faire des opérations synchrones sur un système de fichier ZFS asynchrone over NFS crée une perte de performance conséquente mais moins dramatique que dans le premier cas : les latences ne sont augmentées que d'un facteur 2 à 6 dans le cas d’écritures séquentielles. Dans le cas d'écritures aléatoires les latences sont strictement les mêmes.

Les mesures de latences avec la dedup sont à mettre en adéquation avec le taux de déduplication.

La première mesure consistait à tester les performances d'un système de fichier dédupliqué et vide. Le taux de déduplication est donc de 1.

La deuxième vague consiste à tester les performances du même système, mais cette fois si stressé. Au début des mesures, le taux de déduplication est de 3.96… A la fin il est de 4.4. La consommation de mémoire a augmentée de 50% (on en utilise 16 GB).

La troisième vague consiste à remplir autant que possible les disques du NAS et de recommencer les mesures suivants. J'y ai écrit 410GB.

Les performances avec Dedup sont les mêmes que sans. Cela vient du fait que de la RAM était encore disponible en très grande quantité Pour l'ARC. Il faut prévoir en moyenne 5GB de RAM par TB de données. A titre indicatif sur 410GB de données dédupliquées, j'utilisais 75% de la RAM dont un bon quart pour la table de Dedup.

J'ai tenté deux méthodes de stress tests :

• un dd if=/dev/urandom of=file/over/nfs

Il s'avère beaucoup trop régulier et ne reproduit pas le comportement du cluster

• une copie d'une racine linux en boucle sur 8 coeurs :

Le NAS monte à 20% de CPU sur du NFS mais il n'y a semble t il aucune influence sur les performances …

Je dois reconnaître avoir abandonné le sujet.

Étrangement, j'ai obtenu des performances étrangement similaires entre raidZ et raidZ2. Je vous laisse vous reporter aux annexes.

Les intérêts du NAS sont surtout fonctionnels :

• Centraliser le stockage, afin de :
  • Faciliter la gestion
  • Réduire les couts matériels.
• Bénéficier des features ZFS

On est en droit de se demander quels sont les inconvénients de tels choix fonctionnels en terme de performances. Pour cela, j'ai comparé les performance d'OpenIndiana avec celles d'un disque SAS en local.

On constate quand même un baisse de performances liée à ce choix, même si à priori cela ne semble pas critique.

Voici les benchmarks du NAS versus mon disque SATA, à titre informatif…

J'ai comparé les débits en scrub (annalyse des pools) et en resilvering (réparation des pools).

En scrub, OpenIndiana est à 25 Mo/s et FreeNas 30 Mo/s… Si notre pool est plein ça prend un peu plus de 12 h dans les deux cas.

En resilvering les débits sont équivalents.

Les performances demandées par un resilvering “à pleine vitesse” sous OpenIndiana sont de 15% de CPU et 700 Mo de Ram. Les disques sont néanmoins pas mal sollicités. Du genre 12 Mo/s de lecture sur chaque disque du pool en lecture et 12Mo/s en écriture sur le disque resilveré. Prévoir des pertes de performances…

En conclusion :

• OpenIndiana permettra de meilleurs résultats que FreeNas en terme d'écriture, même si il y a un prix à payer sur les grosses écritures séquentielles. Nous privilégierons donc cette solution.
• La dedup ne sera pas activée pour cause de manque de RAM
• La compression peut être activée sans soucis, et peut permettre de gagner un bon facteur de compression
• La synchronisation est à désactiver sur les datasets, sous peine d'une perte drastique de performance
• Les stress tests ne se sont pas montrés concluant. Il faudra une étude à postériori pour obtenir la tenue de la charge. On en profitera pour comparer les performances avec celles de Hulk.

• Mes tests ont générés 2.2To d'écriture sur les NAS et 0.6 To de lecture…

• Les réécritures et relectures ne permettent pas réellement de tenir compte de l'effet du cache log et l2arc, sûrement à cause d'un nombre d'opérations successives sur les mêmes fichiers trop petit (tout est disponible en annexe).
• Les stress tests ne se sont pas montés pertinents.

Cette section sera renseignée une fois la migration de NAS menée à bien.

• Annexes : tous mes fichiers générés lors des stress tests
• Un PDF très explicite concernant iozone
• Le PAD comportant l'ensemble des commandes saisies lors des tests (accessible seulement par les membres de MiNET…).
• Un autre test très intéressant, notamment sur la compression.
• Si vous lisez des benchmarks extérieurs, faites attention à la date du test. FreeNas s'est clairement amélioré entre 2010 et 2012…
• Un des tests qui nous a poussé à tester FreeNAS

— Benoit Tellier 2014/01/25 17:02