Faut-il suivre les best practices VMware ?

Depuis quelques mois maintenant, notre direction informatique est en effervescence. L’arrivée des fameux “GHT”, que le monde de la santé connait bien, n’est pas étrangère à cet état de fait. Cela m’a conduit à plusieurs reprise d’apporter des conseils (dans la mesure de mes moyens évidemment ^^) et/ou des éclairages sur des choix de nouveaux investissements, des avis ou des bilans sur des infrastructures existantes, voire présenter nos propres choix internes et les valoriser.

A ces occasions, viennent régulièrement sur la table des échanges autour de l’optimisation des environnements virtualisés : “combien de VMs par host”, “combien de VM par datastore”, “taille des datastores”, “doit-on tuner ESXi ou tout laisser par défaut” etc etc.. Ces questions sont difficiles car, comme tout architecte ayant pas mal “bourlingué”, pour moi, la réponse simple est toujours “ça dépend”. Certains pensent, à tord à mon avis, qu’une production bien “tunée” un jour, va le rester pendant 4/5 ans. L’expérience nous a montré à mainte reprises chez nous, que ce n’était jamais le cas et le maître mot ici reste le suivi et l’adaptation.

Vous le savez sans doute si vous me suivez régulièrement, j’essaye toujours de creuser a minima chaque technologie dans laquelle nous investissons pour avoir une idée précise de son potentiel et réagir le plus vite possible à des changements non anticipés (qui sont toujours au coin de la rue …). Cela passe par une lecture plus ou moins assidue des guides et “best practices” associés mais aussi à travailler un peu certaines variables d’ajustement potentielles, à la lumière de ces lectures.

Aujourd’hui, je souhaitais refaire un petit focus sur quelques unes des questions, souvent considérées comme fondamentales, qui reviennent le plus souvent autour de VMware vSphere et vous donner mon analyse et ma vision sur celles-ci. Je n’ai pas la prétention d’avoir évidemment raison quel que soit l’environnement et qu’il faille appliquer à la lettre mes recommandations, mais ce petit bilan est tout de même étayé par plus de 15 ans de virtualisation maintenant, doublé d’échanges réguliers et fructueux avec de nombreux ingénieurs brillants de partenaires intégrateurs, voire de VMware elle-même (lors de mes participations aux VMworld notamment).

Allons-y !

Préambule

Je tiens d’abord à vous préciser que dans le reste de ce billet, je parle exclusivement d’environnements virtualisés généralistes, de type “serveurs”, soit, en gros, une production éclectique, hébergeant des VM variées, tant orientées base de données, que transactionnelles ou même webservice. Le maître mot ici est “non prévisibilité” et “qualité de service équitable”. Cela signifie dans la pratique que des VM de 12 vCPU et 48 Go de RAM cohabiterons avec d’autres de 1 vCPU et 1 Go, le tout partageant des ressources stockage données et une capacité de compute adaptée.

Par conséquent, certaines des recommandations que je pourrai développer ici ne s’appliqueront certainement pas systématiquement à d’autres environnement beaucoup plus spécifiques comme le VDI ou le HPC, pour ne citer que ces deux là.

Combien de VM par datastore

S’il on exclut le monde de l’hyperconvergé, une des questions – légitime – qui se pose souvent est le nombre de VM moyen par datastore vmfs. Ah ! Cette question … Vous voulez que je vous dise simplement, avec mes mots, en 2018 ? Partant du principe qu’aujourd’hui, la plupart des investissements en stockage primaire se fait sur des AFA (allez, disons 90%), la réponse est : ne vous posez pas cette question ! Oui je sais, c’est violent, mais, sérieusement, aucune raison pour vous de vraiment vous soucier du nombre de VM par datastore a priori. L’important est de distribuer au mieux vos workloads entre tous vos datastores et d’en suivre les profils d’IOps au quotidien.

Un peu d’histoire : un premier problème limitant initialement le nombre de VM par datastore date en fait d’avant l’arrivée de VAAI (voir ici). Avant ce jeux d’API VMware – dont la v1.0 est arrivée avec vSphere 4.0 si je me rappelle bien – lorsque vous démarriez une VM, l’ESXi en charge devait obtenir, pendant un certain temps, l’accès exclusif au datastore pour mettre à jour les meta-data de celui-ci. Le résultat était un lock d’une durée assez longue, de l’ensemble des I/O de tous les hosts partageant ce datastore. Depuis VAAI (supporté par 99% des baies de stockage aujourd’hui), cette interruption ne concerne plus que les quelques blocks contenant précisément les méta-data, tous les autres restant complètement libre à la lecture et l’écriture. Le problème se posait vraiment lorsque vous deviez démarrer beaucoup de machines simultanément, ces interruptions pouvaient être rédhibitoires et ralentir beaucoup votre production (imaginez en cas de déclenchement d’un PRA …).

Deuxièmement, il y a encore 5/10 ans, nos bonnes vieilles baies SAN n’avaient pas le potentiel d’I/O qu’on les AFA aujourd’hui et il fallait faire attention à la contention/congestion d’IOps sur chaque LUN. Plus vous aviez de VM à tourner sur une LUN, plus le nombre d’IOps simultanées était mécaniquement important. Il fallait donc être vigilant à ne pas provoquer de saturation des LUN queues. Maintenant, pour des productions généralistes, la question ne se pose qu’exceptionnellement.

Au final, est-ce que la règle, appliquée par certains depuis plus de 10 ans de ne jamais dépasser 15/16 VM par datastore, sinon le monde va s’écrouler et les trompettes de l’apocalypse vont sonner illico, est-elle caduque ? Clairement j’ai envie de dire : OUI. Notre expérience, qui ne saurait valoir règle évidemment, nous montre qu’une consolidation de 25/30 VM par datastore est tout à fait viable et ne pose aucun souci au quotidien pour l’immense majorité des productions généralistes. Tout est en fait affaire d’équilibre, et il y a des outils pour ça : Storage I/O control et Storage DRS en particulier.

Comme il faut bien partir d’un postulat, j’ai tendance à privilégier d’abord la taille. Aujourd’hui, la moyenne de ce qu’on peut rencontrer se situe plutôt autour de 4 To. Sachant que chaque VM faire rarement en dessous de 100 Go (merci Windows ^^), cela vous donne un ratio théorique max de 40 VM hébergées. Dans la pratique, on tournera donc plutôt autour de 30 VMs, bingo.

Consommation maximum par datastore

La aussi, on a tout entendu ou presque. Quel taux de remplissage maximum un datastore vmfs peut-il raisonnablement supporter ? La réponse est simple : tant qu’il n’est pas plein, tout va bien ^^. Bon, il s’agit de détailler un peu mon propos évidemment. On nous a rebattu les oreilles depuis longtemps sur la nécessité de maintenir un espace libre minimum “de bon fonctionnement” sur beaucoups de système. Les datastores vmfs de VMware n’échappent pas à la règle. Ceci dit, ils se bornent à donner un pourcentage “acceptable” de remplissage depuis des années. Hors, en 10 ans, les vmfs sont passés de quelques centaines de gigas à quelques téras, quand dans le même temps, l’évolution de la consommation d’espace des VM n’a pas suivi cette multiplication par 10, mais plutôt par 2/3. Alors, quoi ? doit-on conserver encore ces fameux 20% de libre pour des performances optimales ?

Clairement, non, et là encore tout est affaire d’équilibre. Hormis les snapshots pendant les phases de sauvegarde, la place disponible reste avant tout une réserve pour de soudaines extensions sur les disques en thin provisionning ou les opérations de suspend éventuellement. Il faut bien voir que la où 20% représentait 100 Go pour un datastore de 500 Go, il représente aujourd’hui pas loin de 800 Go pour un disque de 4 To. Au final, sur nos productions aujourd’hui, dans la majorité des cas, quelques centaines de Giga disponibles sont un bon compromis entre place “perdue” et optimisation de la consommation sur les datastore, soit une dizaine de % au total.

En outre, désormais, la plupart des LUN sont créés en mode thin provisionning sur les baies, et mécaniquement, tant que celui-ci n’est pas rempli, l’espace non consommé reste disponible pour les autres. Dans la pratique, donc, si vous tenez à maintenir par principe 20% de marge sur vos datastores, ce n’est pas si gênant que cela : rajouter un datastore de plus et vous maximiserez la consolidation… et même, tiens, vous diminuerez mécaniquement le nombre de VMs par datastore, elle est pas belle la vie !

Même les experts en parlent !

Je n’aime pas trop utiliser l’argument d’autorité, mais malgré tout, j’ai retrouvé deux billets d’experts renommés dont on ne peut, a priori, contester ni la notoriété ni les compétences sur ces sujets, qui parlaient déjà de ces questions en ayant un message somme toute assez proche du mien :
– Duncan Epping évoquand, sans s’en cacher, des taux de consolidation de 40 VMs par datastore, en 2011 ! Voir ici.
– Chad Sakac et ses recommandations sur VMFS. A lire ici.

Arrêtez avec les vCPUs !!

Pour de compléter ces réflexions avec la partie vCPU, je ne peux que trop vous conseiller de lire aussi mon coup de gueule sur le délire des recommandations du nombre de vCPU de certains fournisseurs de solutions logicielles. A l’époque, ça m’avait vraiment énervé, vous le verrez, mais surtout cela reprend aussi les best practices de VMware, donc quitte à les appliquer, faites le aussi sur le dimensionnement des VMs ;) … ha, tiens, bizarrement, j’en voit au fond qui quittent la salle discrètement … ^^

Pour enfoncer le clou, sachez, en plus, que pour les applications anciennes ne tirant aucunement partie du SMP, rajouter beaucoup de vCPUs inutiles peut même nuire à la performance, car certains OS Invités ont quelque fois tendance à déplacer le process en question d’un coeur à l’autre et provoquer, coté ESXi proprement dit, une perte de localité au niveau du cache L2/L3, réduisant du même coup la performance de ladite application.

Voici les deux extraits du manuel des best practices VMware vSphere 6.5 qui matérialise ces règles :
“Allocate to each virtual machine only as much virtual hardware as that virtual machine requires. Provisioning a virtual machine with more resources than it requires can, in some cases, reduce the performance of that virtual machine as well as other virtual machines sharing the same host.”
“The guest operating system’s scheduler might migrate a single-threaded workload amongst multiple vCPUs, thereby losing cache locality.”

Pour le coup, vous voyez, j’ai tendance à essayer de respecter au mieux ces règles, car elle sont toutes reliées à une sorte de “bon sens” en matière de mutualisation et d’optimisation, gage d’un meilleur ROI.

Focus sur ESXi

Si l’on parle beaucoup du stockage quand il s’agit de définir une nouvelle infrastructure, le dimensionnement des hyperviseurs est également un sujet plus qu’important évidemment. La aussi, l’équilibre est de mise, mais il repose sur des hypothèses plus nombreuses, notamment autour de la qualité de service et des réserves de puissance pour les stretched clusters, par exemple.

De mon point de vue, ce qui impact le plus les performances en environnement stressé c’est le manque de mémoire (utilisation du swap hyperviseur, balooning, “dense mode” etc) et je privilégie donc la surcapacité en RAM, d’autant que pour des stretched clusters, la règles est souvent le “2×100%” chez nous. Cela signifie que le cahier des charges en matière de plan de secours nous impose de pouvoir absorber l’ensemble de la charge sur seulement la moitiés de nos capacités nominales. Autant dire qu’au quotidien, on se fait violence pour ne jamais dépasser les 45/50% de charge mémoire et CPU.

Ce qui est assez curieux au final, c’est que la plupart du temps, les personnes que je rencontrent sont assez d’accord avec ces principes Hyperviseur simple, mais restent frileux quand il s’agit de densifier le nombre de VM par datastore. Pourtant la logique est la même, encore une fois : équilibre et supervision au quotidien. En somme, quel que soit l’environnement, le problème n’est pas le nombre de VM mais bien les seuils de indicateurs importants comme la contention CPU et, par VM, le CPU Ready par exemple. Sur les datastores, c’est la même chose, pas de saturation et d’IO Wait, latence restant dans les limites d’un fonctionnement dynamique.

Et coté guest ?

La, je ne fais que reprendre, pour le coup, les fondamentaux :
– maintenez autant que faire se peut vos VMware Tools à jour
– Désactivez ABSOLUMENT les screensavers et les serveurs X Window qui ne servent à rien !
– Ne lancez pas vos scan antivirus en même temps, ni, dans la mesure du possible, vos backups “guest”, tentez plutôt de les faire de manière itératif en respectant des fenêtres imposées
– pour les applications I/O intensives créez autant de cartes SCSI virtuelles que de vmdk (multiples queues au sein du guest pour maximiser les perfs, dans la mesure où votre storage en dessous suit évidemment ^^)

De plus, voici quelques rappels concernant la partie réseau :
– Toute activité réseau se traduit forcément en CPU consommé coté Hyperviseur : pensez-y lorsque vous taillez vos ESXi, l’overhead réseau peut être non négligeable
– Les infos réseau de synchro des cartes invités ne sont pas fiables ! Même si votre bonne vieille carte PCNet n’affiche que 10 Mbit/s, ESXi traitera toujours les flux à la vitesse maximum de ses capacités et de la connectivité des cartes physiques, si les flux sortent de la machine.

Le cas de vMotion/svMotion

La aussi, le déplacement de VM avec ou sans son stockage sont des opérations intensives en CPU, évidemment, gardez en sous le pied pour minimiser les temps de vMotion. Si vous êtes très riches et que vous avez des cartes réseau de 40 Gbit/s (wow !), multipliez les interfaces vmotion (au moins 3) pour être en mesure d’exploiter toute la bande passante disponible.

Par défaut, ESXi est capable de gérer 4 flux vMotion/svMotion simultanément. Personnellement, je préfère “prendre mon temps” pour limiter le stress inutile et je limite cela à 2. Maintenant, si vous avez 10.000 VMs à déplacer et les ressources réseau pour le faire, vous pouvez bien entendu augmenter raisonnablement cette limite.

Quelques petits rappels sur le comportement de Storage vMotion :
– Si vous déplacez une vm d’un datastore à un autre au situés sur une même baie, c’est que du bonheur, ESXi ordonnera directement à la baie, via VAAI, de faire la copie toute seule, limitant du même coup CPU et consommation sur les liens SAN.
– Si l’ESXi source voit aussi directement le datastore de destination, la copie se fera uniquement à travers les liens SAN et non par le réseau, synonyme, là encore de moindre consommation CPU et Réseau.

Et vous ? Vous faites comment ?

Au final, comme toujours, il est urgent de prendre un peu de distance avec les fameux best-practices. Ils sont clairement un guide général qui vous garantira une seule chose : si vous appelez le support, celui-ci ne pourra pas vous répondre, avant de discuter de votre problème : “respectez les bonnes pratiques” ^^. Disons plus sérieusement qu’ils sont en tout cas une base de départ que vous pouvez appliquer pour une toute nouvelle infrastructure destinée à accueillir une production existante ; pour autant, ne soyez pas esclave, ni même inquiet si d’aventure vous deviez faire quelques aménagements. Une production n’est pas statique, elle évolue du mois au mois, évoluez avec elle et profitez des avancées technologiques des nouvelles versions.

Je tiens à rappeler ici que mes recommandations sont avant tout issues de notre expérience de la production de notre institutions (1700 VMs aujourd’hui), complétée par tous les articles, billets et autres documentations que j’ai pu lire sur ces sujets depuis plusieurs années déjà, le tout ayant été affiné par des discussion fructueuses avec d’autres collègues et intégrateurs.

Je ne saurais que trop vous encourager, à ce stade, à discuter mes analyses, dans les commentaires, que vous soyez d’accord avec moi ou au contraire (plus intéressant encore !) complètement en désaccord. En tout état de cause, j’espère que ces quelques généralités vous aideront, de votre coté, à progresser éventuellement, prendre du recul certainement et surtout vous permettre d’améliorer encore vos taux de consolidation sans mettre en péril vos environnements. Safety First !

Et, allez, je suis bon prince, je vous donne un lien vers la bible, quand même, à lire absolument… pour connaître la loi ^^
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/Perf_Best_Practices_vSphere65.pdf

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.