Ci-dessous, les différences entre deux révisions de la page.
wiki:divers:coin_geek:benchmark_nfs [2018/09/18 01:42] shatoon [Un mot sur la synchronisation?] |
wiki:divers:coin_geek:benchmark_nfs [2020/06/27 18:16] |
||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
- | ======= benchmark : OpenIndiana versus FreeNas ======= | ||
- | 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 [[wiki: | ||
- | |||
- | ===== Définition de nos besoins ===== | ||
- | |||
- | 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 : | ||
- | - Les benchmarks **ZFS** classiques ne nous intéressent au final qu' | ||
- | - Nous chercherons à diminuer le temps d' | ||
- | - Enfin, nous devons tenir compte que nous avons (à l' | ||
- | - Nous souhaitons aussi de plus évaluer les pertes de performances liées à des écritures synchrones sur du NFS. | ||
- | - Nous souhaitons aussi constater l' | ||
- | - De même nous nous pencherons sur l' | ||
- | - Enfin, nous verrons l' | ||
- | |||
- | ===== Quels OS tester ? ===== | ||
- | |||
- | Nous n' | ||
- | |||
- | Nexenta a été mis hors course car il n' | ||
- | |||
- | 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 [[wiki: | ||
- | |||
- | ===== Protocole de test ===== | ||
- | |||
- | ==== Quels programmes de tests ==== | ||
- | |||
- | === iozone === | ||
- | |||
- | Nous cherchons donc à obtenir les latences, et ce pour différentes tailles de fichiers, et tailles de blocks d' | ||
- | |||
- | Nous allons pour celà utiliser un petit programme Linux, '' | ||
- | |||
- | '' | ||
- | |||
- | Je vous laisse vous reporter à la documentation. | ||
- | |||
- | === ioping === | ||
- | |||
- | '' | ||
- | |||
- | ==== Pertinence de l' | ||
- | |||
- | Des tests préliminaires avec '' | ||
- | |||
- | - Les valeurs des résultats varient d'à peu près 10% d'une machine à l' | ||
- | - La tendance et l' | ||
- | - Entre deux tests réalisés sur une même machine, les valeurs présentent en moyenne un écart de 3% | ||
- | - Et au pire de 10% | ||
- | - 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: | ||
- | - On se fiera aux tendances des résultats et non à une mesure en particulier | ||
- | - On retiendra qu'un écart inférieur à 3% n'est pas significatif | ||
- | |||
- | ==== Le protocole de test en lui même ==== | ||
- | |||
- | On mesurera pour chacun des deux systèmes d' | ||
- | |||
- | - les débits et latences en écritures asynchrones | ||
- | - les débits et latences en écritures synchrones (pour le choix des options **ZFS**) | ||
- | |||
- | Nous réaliserons ces mesures : | ||
- | |||
- | - Avec le NAS à vide | ||
- | - Avec le NAS stressé par une tierce machine, à l'aide de : | ||
- | |||
- | dd if=/ | ||
- | |||
- | Et avec pour certaines de ces mesures, la compression activée sur le NAS... | ||
- | |||
- | ===== Un petit mot sur le matériel ===== | ||
- | |||
- | 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(tm) Processor 250) | ||
- | |||
- | ==== Un mot sur la constitution des pools ==== | ||
- | |||
- | 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. | ||
- | |||
- | ====== Les résultats ====== | ||
- | |||
- | ==== Benchmark FreeNas / OpenIndiana ==== | ||
- | |||
- | 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, | ||
- | * OpenIndiana et FreeNas sont équivalents en lecture aléatoire. | ||
- | * OpenIndiana est très légèrement moins bon pour les écritures synchrones. | ||
- | |||
- | ==== Et la compression dans tous ça? ==== | ||
- | |||
- | 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 : | ||
- | |||
- | ^ Algorithme de compression ^ fichiers texts ^ fichiers gz ^ | ||
- | | ** lz4 ** | 3.64 | 1.14 | | ||
- | | **lzjb** | 2.46 | 1.10 | | ||
- | |||
- | Le fait que la compression ne fasse pas perdre de performance vient du fait que nos processeurs sont clairement " | ||
- | |||
- | ==== Un mot sur la synchronisation? | ||
- | |||
- | La synchronisation du dataset s' | ||
- | 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' | ||
- | |||
- | {{: | ||
- | |||
- | {{: | ||
- | |||
- | {{: | ||
- | |||
- | 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' | ||
- | |||
- | {{: | ||
- | |||
- | {{: | ||
- | |||
- | {{: | ||
- | |||
- | {{: | ||
- | |||
- | ==== Un petit tour sur la dedup ==== | ||
- | |||
- | 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, | ||
- | |||
- | {{: | ||
- | |||
- | {{: | ||
- | |||
- | {{: | ||
- | |||
- | ==== Un échec : les stress tests ==== | ||
- | |||
- | J'ai tenté deux méthodes de stress tests : | ||
- | |||
- | * un '' | ||
- | Il s' | ||
- | |||
- | * 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. | ||
- | |||
- | ==== RaidZ versus RaidZ2 ==== | ||
- | |||
- | Étrangement, | ||
- | |||
- | ==== Intéret du NAS ==== | ||
- | |||
- | 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' | ||
- | |||
- | {{: | ||
- | |||
- | {{: | ||
- | |||
- | {{: | ||
- | |||
- | {{: | ||
- | |||
- | 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... | ||
- | |||
- | {{: | ||
- | |||
- | {{: | ||
- | |||
- | {{: | ||
- | |||
- | {{: | ||
- | |||
- | ===== Et en cas de soucis ? ===== | ||
- | |||
- | 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" | ||
- | |||
- | ===== Conclusion ===== | ||
- | |||
- | En conclusion : | ||
- | |||
- | * OpenIndiana permettra de meilleurs résultats que FreeNas en terme d' | ||
- | * 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. | ||
- | |||
- | ==== Quelques statistiques amusantes ==== | ||
- | |||
- | * Mes tests ont générés 2.2To d' | ||
- | |||
- | ==== Limite des tests effectués ==== | ||
- | |||
- | * Les réécritures et relectures ne permettent pas réellement de tenir compte de l' | ||
- | * Les stress tests ne se sont pas montés pertinents. | ||
- | |||
- | ==== Conclusion à postériori, | ||
- | |||
- | Cette section sera renseignée une fois la migration de NAS menée à bien. | ||
- | |||
- | ==== Liens complémentaires ==== | ||
- | |||
- | * Annexes : tous mes [[http:// | ||
- | * Un [[http:// | ||
- | * Le [[https:// | ||
- | * Un [[https:// | ||
- | * Si vous lisez des benchmarks extérieures, | ||
- | * Un des [[http:// | ||
- | |||
- | --- // |