dimanche 27 septembre 2009

Saga : Controverse au sujet du post 'un petit bench pour la route'., 3eme Partie

Update :

Entre deux troubleshouts réseaux, je me suis cloné une petite infra VMware view 3.12.
Le provisionning de 300 clones liés à pris environ .... 5 secondes :) et a généré 50K iops.

Commentaire posté par BEND78 :

"Vous obtenez donc dans les 4Gb/s par VM... ce qui donne 20Gb/s pour l'ensemble des 5 VMs !
Très impressionnant ces disques SSD...
Néanmoins un test "iometer" pourrait être plus parlant pour voir les gains sur les accès aléatoires. "

Mon cher BEND78, je pense qu'il va vous falloir raisonner autrement qu'avec les stockages traditionnels en voyant comment fonctionne un Pillar Data. Un disque SATA traditionnel est très performant en I/Os séquentielles mais pas aléatoires. Un disque FC, c'est rigoureusement l'inverse. L'architecture Pillar permet de transformer toutes les I/Os aléatoires en I/Os séquentielles. Autrement dit, séquentielles ou aléatoires, les performances I/Os sont rigoureusement les mêmes ! Sinon, je n'aime pas IOMETER car il faut faire un bench manuellement ligne par ligne alors qu'ATTO permet de voir les résultats comparatifs de manière globale. Toutefois, je me plie à la démonstration avec IOMETER en prenant la première ligne venue 8K, sans optimisation particulière du point de vue des blocs utilisés par le stripping en l'occurrence sans m'occuper des profils applicatifs optimisés proposés par Pillar :

8k, 100% random 50% R/W


Résultat


8k, 100% séquentielle 50% R/W


C'est la même chose !

On note un léger overhead CPU lié à la génération des blocs disque eux-mêmes.
Donc : un système Pillar Data est prédictif, réagit de la même manière en accès aléatoire ou séquentiel. Vous comprenez donc que ATTO, qui ne traite que du séquentiel, permet de connaitre les performances du stockage dans tous les modes. Le SSD apporte de la bande passante supplémentaire ainsi que de l'équillibrage des lectures et des écritures sans hardware spécialisé dédié. En résumé : on peut intégrer des briques SSD et en tirer immédiatement le meilleur parti.

PS : pour le second message, j'ai forwardé à Pillar Data et j'attends la réponse que je publierai. Merci pour vos remarques pertinentes.

4 commentaires:

BEND78 a dit…

Bonjour DS45,
Je suis tout à fait d'accord avec vous sur le fait que IOMeter n'est pas un outil simple...

Par contre on ne retrouve pas du tout les mêmes chiffres entre IOMeter et ATTO:

Avec les blocs de 8Ko, ATTO affiche 62Mo/s en ecriture et 158Mo/s en lecture. Pourquoi iometer affiche t-il 20Mo/s ?

Bonne journée,
BEND78

dunestudio45 - DS45 a dit…

Parce que qu'avec ATTO on peut lancer plusieurs demandes d'accès simultanés, par défaut 4.

BEND78 a dit…

Concernant la méthode d'accès physique, Pillar semble d'après vos explications utiliser une technique à la WAFL/ZFS...
Vous avez parfaitement raison de mettre en avant l'avantage que ca procure sur des disques économiques, mais pensez-vous que cette optimisation puisse être utile avec des disques SSD qui sont rapide sur tout les tableaux ?

(au sujet d'ATTO, 4x20Mo/s = 80Mo/s alors comment ATTO peut-il montrer 158Mo/s en lecture dans ses conditions ?)

dunestudio45 - DS45 a dit…

Concernant la méthode d'accès physique, Pillar semble d'après vos explications utiliser une technique à la WAFL/ZFS...
-> non

Vous avez parfaitement raison de mettre en avant l'avantage que ca procure sur des disques économiques, mais pensez-vous que cette optimisation puisse être utile avec des disques SSD qui sont rapide sur tout les tableaux ?

-> oui, peut-être y -a-t-il des temps d'accès différents sur les l'ensemble des SSD, d'autre part, PILLAR propose aussi d'intégrer des briques SSD en tant que classe de service PREMIUM

(au sujet d'ATTO, 4x20Mo/s = 80Mo/s alors comment ATTO peut-il montrer 158Mo/s en lecture dans ses conditions ?)

-> 48Go de cache dans le slammer ( de base :) ), pourquoi aller chercher ailleurs ce qui est déjà local ???

Au demeurant, je pense que vous pouvez prendre le problème dans tous les sens ca va être difficile de trouver un défaut sur ce matériel.

Mike Workman a participé chez IBM à la conception du disque dur Winchester 3.5 ou microdrive tel que celui que vous utilisez probablement dans votre PC ou dans votre protable. Si vous pensez pouvoir lui expliquer qu'il s'est trompé, je veux bien voir ça ....