Opinion

Dégradation des performances des VM : et si le stockage était innocent?

Le stockage a été identifié comme cause de la dégradation des performances de vos VM. Pourtant, il se pourrait que le fautif soit votre hyperviseur.

Jon Toigo
par
Publié le: 10 août 2015

Les fournisseurs et leurs évangélistes ont fait couler beaucoup d’encre pour vanter les mérites de diverses solutions « préférentielles » visant à accélérer des workloads virtualisées devenues trop lentes. En vérité, tout ce débat a pris un tournant assez étrange qui est quasiment passé inaperçu et dont la presse spécialisée n’a pas dit un mot.

Si, comme moi, vous aspirez à obtenir des analyses de vos problèmes informatiques, en vous reposant sur des faits, cet article est pour vous. Nous tenterons ici d’aborder le stockage dans les environnements de serveurs virtuels sans faire d’amalgames, créer de confusion, ni établir d’une manière ou d’une autre de faux liens de causalité entre des points de données disparates.

Bien au-delà du simple outil de banc d’essai qu’elle constituait, la virtualisation des serveurs est rapidement devenue à la mode grâce à la consolidation des serveurs via une capacité de locataires multiples. Et tout aussi rapidement avons-nous commencé à entendre parler des effets néfastes du stockage hérité.

Le stockage, nous a-t-on répété encore et encore, est directement responsable de la dégradation des performances des workloads, une fois celles-ci virtualisées et instanciées dans les environnements d’hyperviseur.

A l’origine, la mise au banc du stockage des données se focalisait en grande partie sur les lacunes connues des produits et des topologies de stockage de l’époque. Pendant longtemps, les fournisseurs de solutions de stockage incriminés ont insisté sur le déploiement de leurs batteries de disques via des contrôleurs propriétaires ; ceux-ci hébergeant une fonctionnalité logicielle tout aussi propriétaire, et conçue à la fois pour rendre les consommateurs captifs, tenir la concurrence à l’écart et fournir toutes sortes de capacités inégalées.

Ajoutez à cela la réticence des acteurs du secteur à travailler ensemble, dans le cadre d’une approche de gestion commune – qui aurait permis d’administrer, de faire évoluer et de configurer l’infrastructure de manière globale, plutôt que chacun dans son coin – et vous avez tous les ingrédients pour concocter une infrastructure bancale et coûteuse.

Evidemment, difficile de contester les points ci-dessus.

La situation est devenue si mauvaise au début des années 2000 que les analystes encourageaient carrément leurs clients à faire appel à un seul fournisseur pour tous leurs besoins en stockage, dans l’espoir que l’homogénéité permettrait une gestion cohérente ; élément central, avec la gestion des données, de toute stratégie de maîtrise des coûts.

Par conséquent, nous conviendrons tous qu’un stockage ingérable constituait alors la cause fondamentale d’un grand nombre de problèmes informatiques. Cette cause se traduisait par une sur-allocation et une sous-exploitation des ressources, entraînant le besoin d’augmenter la capacité et, par voie de conséquence, les dépenses en capital (Capex). Et, parallèlement, pour gérer le matériel et les interconnexions, elle exigeait davantage de personnel informatique avec des compétences spécialisées en architecture et en administration du stockage, entraînant une perte de contrôle des dépenses d’exploitation (Opex).

Faut-il vraiment incriminer le stockage ?

Même si nous sommes d’accord sur le fait que ces caractéristiques du stockage étaient indésirables et devaient être corrigées, elles n’expliquaient pas le problème de lenteur dont souffraient les machines virtuelles (VM).

Pourtant, VMware et les autres fournisseurs d’hyperviseurs insistaient pour établir une corrélation et un lien de causalité fallacieux entre le problème des performances des machines virtuelles et le stockage propriétaire.

Différentes approches ont résulté de cette stratégie, notamment les très vantées API d’intégration VAAI (VMware vStorage APIs for Array Integration) de VMware, en 2006, et même, plus récemment, son offre de « stockage à définition logicielle », Virtual SAN, qui continue de s’attaquer au problème de la lenteur des VM en agissant sur les lacunes du stockage.

Dans certains cas, l’exécution d’une application peut effectivement se voir ralentie par la latence du stockage ; latence liée aux débits et aux vitesses des périphériques, appareillages et réseaux de stockage qui connectent cette application aux serveurs. Ce phénomène est bien compris et on y remédie généralement en combinant mise en cache et parallélisme ; la première est utilisée pour collecter les écritures dans une couche de stockage rapide, dissimulant les opérations de stockage plus lentes à l’application, tandis que le second augmente le nombre d’actionneurs intervenant sur une tâche (notamment le traitement des E/S), et ce afin d’en faire plus, en moins de temps.

Aujourd’hui, nous commençons à essayer différentes stratégies, après avoir constaté que les E/S des applications rencontrent, quelque part sur le chemin du périphérique de stockage, un blocage lié à l’assemblage de logiciels (API, langages de commande et protocoles) et de matériels (adaptateurs de bus hôte, câbles, ports de commutateur et connexions de périphériques) qui relie l’application aux données qu’elle stocke.

La simple présence d’une file d’attente d’E/S plus longue que prévue témoigne d’un problème sur ce parcours ; elle correspond au grand nombre d’opérations d’écriture en attente côté périphérique de stockage.

Seulement voilà : dans la plupart des cas de dégradation des performances des VM que j’ai rencontrés chez des clients et dans nos laboratoires, la longueur des files d’attente de stockage était assez négligeable. Autrement dit, le problème de lenteur des VM ne peut logiquement pas être attribué à la latence du stockage.

Dans le même temps, dans la plupart des situations, la cadence des cycles processeur sur le serveur hébergeant ces VM trop lentes a tendance à être extraordinairement élevée. Lorsque les processeurs surchauffent à ce point, cela indique généralement qu’ils s’efforcent de résoudre un problème présent côté application, à l’intérieur de la VM, ou au niveau du logiciel de l’hyperviseur lui-même.

En bref, le blocage se situe au-dessus de la couche du parcours des E/S de stockage.

Votre hyperviseur pourrait bien être le goulet d’étranglement

Aussi, le vilain stockage propriétaire hérité n’est peut-être pas celui qu’il faut blâmer pour le ralentissement de vos VM. Le problème vient probablement de votre hyperviseur ou de votre application virtualisée.

D’où la question de savoir pour quelle raison vous devriez débrancher tous vos périphériques de stockage existants – à savoir une infrastructure à laquelle, le plus souvent, vous avez consacré une énergie et un budget considérables pour la consolider dans un SAN ou la déployer avec soin sous la forme de serveurs de fichiers NAS sur votre réseau – et ce uniquement pour les remplacer par des JBOD à connexion directe exploités par le kit logiciel de contrôle le plus récent de votre hyperviseur.

L’effet mixeur des E/S est réel. Lorsque vous empilez un grand nombre de VMs et les laissez purement et simplement, sans supervision, mélanger des E/S aléatoires pour obtenir un monceau incohérent d’écritures qui, à court terme, épuisera vos cartes Flash et encombrera votre disque, il y a de fortes chances pour que les performances des VM se dégradent.

Là encore, ce n’est pas le stockage en lui-même qui pose problème, mais votre stratégie d’hyperviseur. En supposant que vous vouliez conserver votre hyperviseur, vous pouvez envisager un moyen plus efficace d’organiser et d’écrire les données ; un moyen qui ne vous obligera pas à changer l’infrastructure matérielle de stockage sous-jacente : par exemple, l’approche de structuration par fichiers journaux d’un fournisseur tel que StarWind Software, le contrôleur logiciel performant de PernixData ou le super-contrôleur de DataCore Software.

Maintenant, si vous décidez de vous débarrasser de votre infrastructure de stockage existante pour la remplacer par une approche côté serveur, cela ne tient qu’à vous. Mais analysez clairement les raisons de votre décision.

Lors de mes recherches, j’ai trouvé peu d’informations indiquant que le remplacement d’un système de stockage existant par un DAS améliorerait un tant soit peu les performances des machines virtuelles.

Dans votre propre intérêt, et avant de mettre en place une stratégie de correction, effectuez quelques mesures simples, disponibles au niveau de tous les systèmes d’exploitation, afin d’examiner l’activité des processeurs et la longueur de la file d’attente.

Pour approfondir sur Virtualisation du stockage