Performance Freenas ESXi ISCSI 10Gbit

[Haiku]

Bonjour

Cela fait un certain temps que je me pose la question des performances sur le stockage suivant car il ne me semble pas avoir les performances en lien avec la configuration.

Super micro + expandeur sas 24 baie
LSI 9211-8i
CPU E3-1230 v3 @ 3.30GHz
32GB
12 x SSD 850 EVO 1To (11 * RaidZ2 + 1 spare)
2 cartes bi port 10Gbits sur 2 switch 10Gbits Dlink
MTU 9000

Ci-joint les performances moyenne que j obtiens entre freenas et ESXi en ISCSI en multipathing (cristaldiskmark avec 981.5 mbits)
Ci-joint les performances moyenne que j obtiens entre freenas et ESXI en ISCSI en multipathing en modifiant la talle des blocks (cristaldiskmark avec 6 copie d ecran)
Ci-joint les performances moyenne que j obtiens entre freenas et Windows en ISCSI SANS multipathing (cristaldiskmark avec 1145.9 mbits)


La config est standard
La LSI n'a pas de cache et est configuré avec le bios pour du stockage software
Le freenas est installé sur un raid1 par la carte interne raid et sur 2 SSD separés

Voici la liste des tests realisés

En local sur le freenas (en production)
dd if=/dev/zero of=test2.dat bs=4k count=2000000 => 817 555 495 bytes/sec
dd if=test2.dat of=test1.dat bs=4k count=2000000 => 110 048 055 bytes/sec (Problème de réglage on est plus a 400mbit en general)
dd if=test2.dat of=/dev/null bs=4k count=2000000 => 130 687 897 bytes/sec (idem probleme de reglage on est sense est plus haut)

La suppression des log -> aucun effet, tjrs les meme performance
test sur du raid 10 -> aucun effet, tjrs les meme performance
Un certain nombre de tunning -> quelques effets mais tres aleatoire et pas forcement benefique
Activation du round robin sur ESXi a un IOPS => bénéfice sur le séquentiel
Activation des MTU 9000 => Tres peu d effet
J ai aussi teste le controleur paravirtuel sur esxi avec des bons résultats sur une VM mais qui ont evolué a la baisse ensuite


Du coup, j avoue ne plus trop savoir quoi chercher

Avez vous une suggestion ? Merci

 

[Pitfrr]

Bon au début quand j'ai vu un réseau à 10Gbps et un volume avec 12 SSD.... je me suis dit qu'on jouait pas dans la même cour d'école! ;-) Donc que mon aide serait plutôt limitée...
Mais je serai quand même curieux de comprends aussi ces performances. ;-)

Si j'ai bien compris FreeNAS sert de stockage pour des VM et ce stockage est passé en iSCSI (entre FreeNAS et ESXi)?

Déjà, par rapport aux tests que tu as effectué en local sur FreeNAS, les performances sont en effet bien en deça de ce qui serait attendu pour une config pareille!

En comparaison, dans mon cas, j'ai des résultats d'un ordre de grandeur supérieur: 1 891 716 381 bytes/sec en lecture et écriture.
J'ai un volume en RAIDz2 avec 6 disques mécaniques en 5400rpm. Mais.... je me demande si la RAM ne vient pas jouer au cache et fausse les résultats?
Mais je dirai que peu importe, des ordres de grandeur d'un centaine de MBytes sont surprenantes dans ton cas.

Ca donne vraiment l'impression que le goulot d'étranglement vient des disques durs!? Car même si iSCSI fait fortement chuter les performances avec FreeNAS (je n'ai pas d'experience là-dedans), d'après les tests que tu as réalisés, c'est pas encore iSCSI le problème puisque les tests sont réalisés sur FreeNAS (et j'imagine qu'il n'y a pas d'activité sur le volume).
Tu as fais des tests avec iperf pour voir ce que donnaient les performances réseau (juste pour éliminer ça)?

Je pense à plusieurs petites choses:
- Vérifier le taux de remplissage du volume FreeNAS (s'il est trop plein (>80% en gros), les performances peuvent diminuer, je crois qu'avec iSCSI c'est encore plus sensible)
- Vérifier la fragmentation du volume FreeNAS (s'il est trop fragmenté (j'ai pas de valeur à donner là), les performances peuvent diminuer)
- Dans FreeNAS (dans l'onglet Reporting) quel est le % du ARC hit ratio? (entre 90 et 100% pour des performances optimales mais là encore en iSCSI je pense que le ARC hit ratio n'est pas très élevé)
- Lors d'un SCRUB quelle est la vitesse de ce dernier?

Mais au delà de ça je sèche.
Peut-être un problème de compatibilité matérielle?
Ou de défaillance (pas "totale") matérielle (un des disques...)?

Si tu arrives à avancer sur ce sujet, n'hésite pas à donner un retour, ça serait intéressant de savoir!

 

[Haiku]

Je pense à plusieurs petites choses:
- Vérifier le taux de remplissage du volume FreeNAS (s'il est trop plein (>80% en gros), les performances peuvent diminuer, je crois qu'avec iSCSI c'est encore plus sensible)
C est bon 50 %

- Vérifier la fragmentation du volume FreeNAS (s'il est trop fragmenté (j'ai pas de valeur à donner là), les performances peuvent diminuer)
Bon aussi

- Dans FreeNAS (dans l'onglet Reporting) quel est le % du ARC hit ratio? (entre 90 et 100% pour des performances optimales mais là encore en iSCSI je pense que le ARC hit ratio n'est pas très élevé)
Ci joint les copies d ecran

- Lors d'un SCRUB quelle est la vitesse de ce dernier?
Comment je peux verifier cette info ? Tu parles de la vitesse du scrub ou de la vitesse du freenas en scrub ?

 

[Haiku]

Et voila le Iperf
En la carte réseau a du mal a fournir ...

 

[Pitfrr]

Pour la vitesse du SCRUB, lorsque celui-ci est en cours, en ligne de commande, un zpool status indique la vitesse du SCRUB genre:
[...] scrub in progress [...] 4T scanned out of 8T at 102M/s, 10h32m to go [...]

Sinon dans l'onglet Reporting/Disk, on peut voir aussi lors du SCRUB la vitesse des disques (graphes Disk I/O) ça donne une idée.

Pour ma part lors d'un SCRUB je suis à des vitesses de 275-300MB/s et dans les graphes, les disques en I/O sont aux alentours de 80MB/s.

Je ne m'y connais pas bien dans l'interprétation des graphes ARC mais le hit ratio et size semblent cohérent, en tout cas je ne vois rien qui saute au yeux (mais encore une fois mon expérience est limitée à un système qui n'utilise pas iSCSI et pour un simple utilisateur! :p Dans le cas de iSCSI, est-ce que passer à 64Go de RAM ne serait pas utile?).

Bon bref, tout ça ne donne pas plus d'indications...
Je conseillerai d'aller poser la questions dans la partie anglophone du forum (si personne d'autre ne se manifeste ici), je sais que d'autres membres sont plus expérimentés pour une utilisation avec iSCSI et avec des SSD.

Concernant iperf, c'est intéressant de voir les différences entre les tailles de buffer, je n'aurai pas pensé. Et en effet, arriver à des vitesse de 170-180Mbits/s sur une liaison 10Gb... :-O
Il peut aussi être intéressant d'exécuter les tests dans les deux sens (c'est à dire iperf -s sur chaque machine). Pour ma part, j'ai constaté qu'entre mon NAS en production et celui de back-up, les résultats n'étaient pas symétriques (dans un cas, je sature le lien à 1Gb, dans l'autre j'atteins péniblement 10Mb!).

 

[Haiku]

Pour les performance de réseau en 4k j ai ma petite idée. Je pense que cela vient des temps de réponse du réseau qui dans mon cas sont de 0.150ms

or 1000ms (1s) / 0.150 = en gros 6500 i/o réseau qui en 4k donne 26mo/s soit x 8 = 200mbits/s

On retombe sur les données d iperf

Mon analyse n est qu une supposition. Qu en penses tu ?

 

[Pitfrr]

Ca semble en tout cas bien cohérent et ça correspond avec les chiffres! ;-)

Mais... comment connais-tu le temps de réponse du réseau? (je demande parce que moi j'en ai aucune idée! après comme toujours, un seul utilisateur, un petit réseau local domestique qui m'envoie mes données à 100MB/s ça me suffit! ;-)) je ne fais pas la chasse aux IOs)

 

[Haiku]

Et bien sur une moyenne de ping

root@UDAF37NAS2:~ # ping 10.0.1.246
PING 10.0.1.246 (10.0.1.246): 56 data bytes
64 bytes from 10.0.1.246: icmp_seq=0 ttl=64 time=0.149 ms
64 bytes from 10.0.1.246: icmp_seq=1 ttl=64 time=0.141 ms
64 bytes from 10.0.1.246: icmp_seq=2 ttl=64 time=0.131 ms
64 bytes from 10.0.1.246: icmp_seq=3 ttl=64 time=0.176 ms
64 bytes from 10.0.1.246: icmp_seq=4 ttl=64 time=0.180 ms
^C
--- 10.0.1.246 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.131/0.155/0.180/0.019 ms

--

Du coup pour completer mon analyse précédente, un reseau infiny band repond autour de 0.15micro seconde, du fait a même perf, je pense qu'il y a beaucoup plus d IO

 

[Pitfrr]

Ben maintenant que tu le dis, ça semble tellement logique! ;-)
J'aurai pas pensé à utiliser les valeurs du ping j'aurai jugé peu fiable mais je me trompe peut-être puisqu'avec les calculs que tu as fait, on retombien sur les valeurs de iperf.

 

[Haiku]

Voila mes dernieres perfs avec le freenas sans VM

 

[Pitfrr]

Si je comprends bien: là c'est les performances en lecture/écriture entre le NAS et une machine sur le réseau?

Ah ben là déjà c'est mieux... 1Go/s en lecture et 1,6Go/s en écriture (bon c'est étonnant que l'écriture soit plus rapide que la lecture mais passons... :-O) ça fait du >8Gb/s pour un lien à 10Gb ça semble bien.

Donc le goulot d'étranglement viendrait effecticement du partage iSCSI?
(mais je n'explique pas les faibles performances en local des tests avec dd?? sauf si y'avait de l'activité côté iSCSI sur les VM...)

Alors pour améliorer les performances en iSCSI (comme toujours je suis pas bien calé):
- Maximiser la RAM, 32Go c'est peut-être un peu limite surtout avec un volume en SSD et un connexion 10Gb.
- Essayer différents types de volumes (mirroir, RAIDz1 ou RAIDz2 qui n'offrent pas les mêmes iOPs et entre RAIDz1 et RAIDz2, je sais plus lequel est mieux en terme d'iOPS je crois RAIDz1? Bon après on tombe dans le cas "il est déconseillé de faire du RAIDz1 avec des disques de grande capacité" mais est-ce valable avec des SSD également? Et "grande capacité" étant pour des disques >1To, on est juste à la limite... :-O).
- Voir même scinder le volume: actuellement c'est 11 disques en RAIDz2, alors pourquoi pas essayer 2x 6 disques en RAIDz2? Ca permet d'avoir plus d'iOPs.
- Ajouter un SLOG et là je conseille de bien se documenter avant (dans la partie anglophone) parce que semble-t-il c'est pas du tout cuit!

 

[Haiku]

mais je n'explique pas les faibles performances en local des tests avec dd?? sauf si y'avait de l'activité côté iSCSI sur les VM...

En bien explication

En local sur le freenas (en production)
dd if=/dev/zero of=test2.dat bs=4k count=2000000 => 817 555 495 bytes/sec
12 disques qui écrivent des 0 avec en gros 50mo/s en block de 4k => environ 600mo/s => on est un peu au dessus avec le cache

Pour le plaisir en 1M
dd if=/dev/zero of=test2.dat bs=1M count=80000
83886080000 bytes transferred in 14.490551 secs (5 789 019 147 bytes/sec)

 

[Pitfrr]

Ah oui... fichue taille de blocs! ;-)
Et que ce soit SSD ou HDD les petites tailles de bloc ils aiment pas!

Alors je n'y avais pas trop prêté attention car mon expérience m'avait amené à penser que la taille des blocs avait peu d'influence. Je m'explique:

Avec la commande:
dd if=/dev/zero of=test.dat bs=nn

J'avais remarqué que j'obtenais des résultats indépendants selon la taille des blocs.
Donc par exemple, pour une taille de bloc de 1B, 1kB ou 1MB, j'ai 1MB/s et lorsque j'ai une valeur de bs=2 (indépendamment B, kB ou MB) j'ai mon maximum en débit (ici 10MB/s). Et ensuite pour les valeurs suivantes, le débit retombe à nouveau (Valeurs dans le tableau ci-dessous non réelles juste pour l'explication).

en B en kB en MB
bs=1 1 1 1
bs=2 10 10 10
bs=4 1 1 1
bs=8 1 1 1
bs=16 1 1 1
bs=32 1 1 1
bs=64 1 1 1
bs=128 1 1 1
bs=256 1 1 1
bs=512 1 1 1


Alors c'est pas aussi net que dans mon exemple ici mais l'unité du bloc (B, kB ou MB) une fois qu'on avait trouvé la valeur (disons 2) ne changeait pas (significativement) le résultat.
Donc je suis venu à croire que la taille du bloc n'avait pas trop d'importance qu'il fallait surtout trouver la bonne valeur/nombre de blocs.

Un détail (qui a peut-être son importance?) je n'envoyai pas le résultat de dd dans un fichier comme ici mais directement sur un disque dur (/dev/dan)... Au niveau performances, cela fait une différence, mais au niveau taille de blocs? Faudrait que je refasse des tests pour comparer tiens, ça serait intéressant (mais pas ce soir j'ai pas le courage! ).

 

[Haiku]

merci pour cette info

 

[wahidovic123]

mais je n'explique pas les faibles performances en local des tests avec dd?? sauf si y'avait de l'activité côté iSCSI sur les VM...

En bien explication

En local sur le freenas (en production)
dd if=/dev/zero of=test2.dat bs=4k count=2000000 => 817 555 495 bytes/sec
12 disques qui écrivent des 0 avec en gros 50mo/s en block de 4k => environ 600mo/s => on est un peu au dessus avec le cache

Pour le plaisir en 1M
dd if=/dev/zero of=test2.dat bs=1M count=80000
83886080000 bytes transferred in 14.490551 secs (5 789 019 147 bytes/sec)

Tutuapp 9apps Showbox
que ce que tu veut dire pour le plaisir 1 m ?
j'ai pas comprs exactement pourquoi 1M ,

 

[Haiku]

Taille de bloc de 1 mb