Je voulais vous relater un peu ce qui s'est dit dans Groupe de Discussion sur le stockage animé par Chad Sakac (VP VMware @ EMC) en mode "Expert généraliste en stockage" comme il se qualifie lui-même, je dirais presque agnostique, parce que franchement on a vécu un grand moment. On a tous laissé nos préjugés, nos préférences aux vestiaires et son questionnaire publié sur son blog nous a servi de fil rouge pour dresser un état des lieux de la manière d'utiliser le stockage dans le monde vSphere. Pour donner un peu d'intéractivité, le questionnaire était repris en séance et les 24 personnes présentes y répondaient au moyen d'une télécommande.
Dans la population présente 70% étaient des partenaires VMware avec un profil technique sachant que pour ma part j'appartenais à la catégorie mioritaire des 12,5% d'utilisateurs finaux.
J'ai pu retenir les choses suivantes :
- A la question quel principal type de protocole de stockage utilisez-vous ?
On a eu droit à : 75% de FC, le ISCSI représente 12,5%, NFS 8,3% FCOE 4,2% ...
Oui, je fais partie de cette minorité de fous early adopters, "very very very early days" comme il nous dira, qui ont consolidé il y a un an les IOs des serveurs avec du FCOE sur Nexus, mais avant je faisais du ISCSI ! Cependant, Chad nous indique que ça ne reflète pas le marché car il ya un plus fort taux sur le marché de ISCSI et NFS du fait de leur simplicité de mise en oeuvre et de leur faible coût de déploiement.
- Utilisez-vous VMFS et NFS ensemble ou l'un des deux ?
La réponse a été 62,5% de VMFS, 4,2% NFS et 33,3% VMFS+NFS
L'assistance pense que NFS est inapproprié pour de larges déploiements au-delà de 2-300 VMs.
Chad nous rappelle quelques principes de base :
* Le métrique Mb/s c'est la bande passante (bandwith)
* Le métrique IOPs c'est le débit (throughput)
La majorité des IOs sont de petites tailles variant de 4k à 8k. Or, il est très difficile de saturer un lien avec de petits blocs mais il est très facile de le faire avec de gros blocs. En résumé, NFS n'est pas si inapproprié, cependant son gros désavantage réside dans lla résilience des communications lors d'un failover par exemple à cause d'une panne de port ou de switch. A un instant t, on utilise un seul lien Ethernet à la fois [NDR : même en trunk. J'ajouterai que la qualité des commutateurs utilisés influe pas mal aussi sinon à quoi ça servirait que Cisco y fasse des Catalyst 6513 ???? Je vous renvoie à l'un des posts sur le SelfMadeNas pour illustrer la problématique de perf]
Les futures versions de vSphere auront des avancées en matière de support de NFS [NDR il eu fallu faire boire Chad après la session pour avoir + d'infos ...]. NFS4 introduira notamment le support de multi-sessions par connexions autorisant l'accès à un share par plusieurs chemins simultanés.
- Qu'est-ce qui est le plus frustrant pour vous aujourd'hui ?
J'ai pu retenir les choses suivantes :
- A la question quel principal type de protocole de stockage utilisez-vous ?
On a eu droit à : 75% de FC, le ISCSI représente 12,5%, NFS 8,3% FCOE 4,2% ...
Oui, je fais partie de cette minorité de fous early adopters, "very very very early days" comme il nous dira, qui ont consolidé il y a un an les IOs des serveurs avec du FCOE sur Nexus, mais avant je faisais du ISCSI ! Cependant, Chad nous indique que ça ne reflète pas le marché car il ya un plus fort taux sur le marché de ISCSI et NFS du fait de leur simplicité de mise en oeuvre et de leur faible coût de déploiement.
- Utilisez-vous VMFS et NFS ensemble ou l'un des deux ?
La réponse a été 62,5% de VMFS, 4,2% NFS et 33,3% VMFS+NFS
L'assistance pense que NFS est inapproprié pour de larges déploiements au-delà de 2-300 VMs.
Chad nous rappelle quelques principes de base :
* Le métrique Mb/s c'est la bande passante (bandwith)
* Le métrique IOPs c'est le débit (throughput)
La majorité des IOs sont de petites tailles variant de 4k à 8k. Or, il est très difficile de saturer un lien avec de petits blocs mais il est très facile de le faire avec de gros blocs. En résumé, NFS n'est pas si inapproprié, cependant son gros désavantage réside dans lla résilience des communications lors d'un failover par exemple à cause d'une panne de port ou de switch. A un instant t, on utilise un seul lien Ethernet à la fois [NDR : même en trunk. J'ajouterai que la qualité des commutateurs utilisés influe pas mal aussi sinon à quoi ça servirait que Cisco y fasse des Catalyst 6513 ???? Je vous renvoie à l'un des posts sur le SelfMadeNas pour illustrer la problématique de perf]
Les futures versions de vSphere auront des avancées en matière de support de NFS [NDR il eu fallu faire boire Chad après la session pour avoir + d'infos ...]. NFS4 introduira notamment le support de multi-sessions par connexions autorisant l'accès à un share par plusieurs chemins simultanés.
- Qu'est-ce qui est le plus frustrant pour vous aujourd'hui ?
La majorité des gens savent que leurs stockages ont des tonnes de fonctionnalités ... qu'ils n'utilisent pas : "so sad but so true" comme dit Chad :) Les gens achètent des machines terriblement sophisitiquées qu'ils n'utilisent que comme de simples JBODs ... [NDR : après on se demande pourquoi j'ai du Pillar Data moi].
Les gens continuent à utiliser leurs systèmes de stockages avec de la virtualisation comme ils le feraient avec de "simples" serveurs physiques. C'est d'autant plus vrai qu'il est frustrant de constater que l'on comble les lacunes ou les erreurs logicielles en ajoutant encore du hardware. Par exemple le problème posé par une requête SQL mal écrite sur Oracle mènera à ajouter du hardware plutôt que de revoir le coeur du problème en optimisant le code. [NDR : ceci étant, comme nous venons de le vivre au boulot, importer les 100Go de données Oracle de la compta en 2 minutes sur un LUN SSD pour recréer une base c'est plus sympa que d'y passer 3 heures]
Les gens continuent à utiliser leurs systèmes de stockages avec de la virtualisation comme ils le feraient avec de "simples" serveurs physiques. C'est d'autant plus vrai qu'il est frustrant de constater que l'on comble les lacunes ou les erreurs logicielles en ajoutant encore du hardware. Par exemple le problème posé par une requête SQL mal écrite sur Oracle mènera à ajouter du hardware plutôt que de revoir le coeur du problème en optimisant le code. [NDR : ceci étant, comme nous venons de le vivre au boulot, importer les 100Go de données Oracle de la compta en 2 minutes sur un LUN SSD pour recréer une base c'est plus sympa que d'y passer 3 heures]
Drôle aussi le passage sur les plug-ins ou Chad nous explique que la tâche première a été de permettre aux gars qui géraient les serveurs de voir le stockage mais de ne surtout rien modifier jusqu'à ce qu'il puisse être mis en place des règles strictes donnant accès à des fonctions limitant l'étendue des dégâts potentiels que ces inconscients d'administrateurs pourraient causer.
Le truc à la mode d'aujourd'hui c'est la dédup suivie de près par le thin provisionning.
Une dernière phrase clé : "Cost of the storage may blocks the virtualization project" à méditer !
Il faudrait pouvoir faire régulièrement ce type de session ou l'on ressort plus intelligent qu'en y entrant, vraiment trop fort ce gars !
Le truc à la mode d'aujourd'hui c'est la dédup suivie de près par le thin provisionning.
Une dernière phrase clé : "Cost of the storage may blocks the virtualization project" à méditer !
Il faudrait pouvoir faire régulièrement ce type de session ou l'on ressort plus intelligent qu'en y entrant, vraiment trop fort ce gars !
Aucun commentaire:
Enregistrer un commentaire