UPDATE le 21/03/14 : Julien Giraud de NetApp a souhaité préciser quelques points concernant ce post et il me semble légitime de vous les soumettre.
"Je viens de tomber sur le sujet NetApp FAS2240 sur votre blog. Très intéressant et je vous remercie d’avoir posté ces informations J
"Je viens de tomber sur le sujet NetApp FAS2240 sur votre blog. Très intéressant et je vous remercie d’avoir posté ces informations J
Cependant il y aurait quelques corrections à apporter à certains points qui ne sont pas exacts :
- Les contrôleurs NetApp fonctionnent en mode actif/actif et non en mode actif/standby et ils se protègent l’un l’autre, le failover étant beaucoup plus rapide que 90 secondes dans la pratique (peut-être l’avez-vous testé ?)
- La carte fille additionnelle peut être de type FC8Gb ou 10GbE, mais elle ne permet pas d’utiliser le protocole FCoE
- La RAM du contrôleur est de 6GB par contrôleur et non de 2GB
Sur la partie tests, celui qui représenterait le plus une infrastructure réelle VMware dans la pratique, est celui basé sur les blocks de 8K en 100% lectures aléatoires (qui représente aussi très bien le fonctionnement d’une base de donnée par exemple)
Les 2 autres tests quant à eux, ne sont pas vraiment représentatifs d’infrastructures habituelles, 512 octets tiennent dans la mémoire cache des contrôleurs d’où les résultats impressionnants, et les sessions de lectures aléatoires sur blocks de 1M ne représentent pas le fonctionnement d’applications normales, ni d’utilisateurs en service de fichiers.
Je vous serai infiniment reconnaissant de bien vouloir apporter ces quelques modifications, cela éviterait que de futurs acquéreurs ne partent avec des idées trop bonnes ou trop mauvaises sur cette solution J
Merci encore pour ce post sur notre technologie et bonne continuation.
Julien Giraud
System Engineer
NetApp "
Autant sur les points traitant des aspects techniques, je n'ai rien à ajouter face au spécialiste de la machine, autant sur les aspects mesure de performance je préciserais :
- Sur la partie tests, celui qui représenterait le plus une infrastructure réelle VMware dans la pratique, est celui basé sur les blocks de 8K en 100% lectures aléatoires (qui représente aussi très bien le fonctionnement d’une base de donnée par exemple)
=> De part ma propre expérience, une infrastructure VMware n'utilise pas dans la pratique 8k mais plutôt 20 à 32k et normalement on réalise aussi des écritures (swap, snapshot vmware, blocs de données ...)
Les 2 autres tests quant à eux, ne sont pas vraiment représentatifs d’infrastructures habituelles, 512 octets tiennent dans la mémoire cache des contrôleurs d’où les résultats impressionnants, et les sessions de lectures aléatoires sur blocks de 1M ne représentent pas le fonctionnement d’applications normales, ni d’utilisateurs en service de fichiers.
=> Les deux autres tests sont au contraire très significatif des performances intrinsèques de la machine : Plus les tailles de blocs sont grandes, moins on génère d'IO et inversement.
Je choisis 512 octets car c'est la taille référence des blocs physiques utilisée sur les disques mécaniques (si l'on a pris soin d'aligner correctement ses partitions). Les buffers sont vidés à leur vitesse nominale.
Notez que j'utilise 4K pour les SSD ... Il ne s'agit pas de connaitre le nombre d'IOPS maxi que peut sortir la configuration disques mais bien de connaître la puissance de traitement de la tête NAS. Là encore, près de 28000 IOPS est plus que respectable.
La taille d'1Mo permet elle de connaitre la bande passante maximale disponible avec le lien concerné. Il est entendu qu'en FC on obtient aisément des débits plus importants. 400Mo/s par port en FC4, 800Mo par port sur du FC8, 1,6Go/s par port sur du FC 16. En ISCSI, on peut atteindre du 110-120 Mo/s et jusqu'à 175Mo/s par port avec une carte ISCSI Offload et des jumbo frame.
Je recommande d'ailleurs de réaliser systématiquement ce type de tesst lors de la mise en oeuvre d'une configuration avant sa mise en production de manière à bien connaître quelles en sont les limites et surtout savoir à quel moment on approche de la saturation. En résumé : gouverner c'est prévoir.
-----------
La baie de stockage FAS 2240 est aujourd'hui l'entrée de gamme de NetAPP en OS 64 bits. La machine se présente sous la forme d’un tiroir 2u disposant de 24 emplacements pour disque SAS 2.5 pouces ici de provenance Hitachi 10k et d’une volumétrie unitaire de 450 Go. l'OS Data ONTAP utilisé ici est la toute dernière version r8.2.2.
La connectique vers les DS additionnels s’opère au travers
de liens SAS 6Gb/s. Par défaut il est aujourd’hui recommandé de boucler les
deux cartes l’une sur l’autre afin de d’autoriser la reprise des disques gérés
par le second contrôleur lors d’un reboot de ce dernier qui serait plus
performant que l’interconnect.
La connectique externe repose sur 4 ports gigabit dédiés au trafic ISCSI/NFS/CIFS, un slot permet d’accueillir une carte fille optionnelle de type FC ou FCOE. Un port 100mb/s est affecté au management out-of-band. La machine a été configurée avec deux ports LACP dédiés vFiler CIFS et 2 ports LACP pour les vFilers NFS.
Les contrôleurs sont de type actifs / standby avec failover (90 secondes) sachant que fonctionnellement, la machine supporte le mode cluster Data ONTAP 8 (out –of-box). Douze disques ont été affectés en RAID-DP au contrôleur 1- on parle d'agrégat-, les douze autres au contrôleur 2 toujours en RAID-DP. La volumétrie utile est de 2x3To et l’équilibrage de charge est à la discrétion de l'administrateur.
Chaque carte CPU dispose d’un XEON 5660 2.23Ghz, de 2Go de
ram OS et 2 Go dédiés au cache sauvegardés 72h par batterie
Les tests réalisés en protocoles ISCSI et CIFS donnent
sensiblement le même résultat.
On arrive à saturation du Gigabit Ethernet et j'ai noté un gain de plus de 15 Mo/s en écriture par rapport à l'ancienne génération FAS 2040.
J'ai été impitoyable en utilisant 64 sessions avec successivement des blocs de 512 octets représentant la taille des blocs physiques du disque mécanique autorisant le maximum d'IOPS possible, puis 8k Windows like et enfin 1Mo VMware like le tout en 100% écriture 100% random ...
64 sessions - 512 octets - 100% écriture - 100 % aléatoire :
27975 IOPS avec une latence de 2.2ms Vraiment remarquable !
27975 IOPS avec une latence de 2.2ms Vraiment remarquable !
64 sessions - 8k - 100% écriture - 100 % aléatoire : 10028 IOPS
avec une latence de 18 ms : Correct
64 sessions - 1Mo - 100% écriture - 100 % aléatoire avec une latence de 1441 ms :(
En résumé, cette petite machine orientée PME est réellement bluffante pour faire office de serveur de fichiers mutualisé. Si l'on souhaite y adjoindre la consolidation de machines Virtuelle vSphere, il faudra veiller à ne pas trop charger la mule. Pour autant, elle reste un excellent choix et m'a réellement séduit par sa richesse fonctionnelle.