Éducation vSphere - Quels sont les inconvénients de configurer les VM avec *trop* de RAM ?

La gestion de la mémoire vSphere est assez décente, bien que les termes utilisés causent souvent beaucoup de confusion.

En général, il convient d'éviter la surallocation de mémoire car cela crée précisément ce type de problème. Cependant, il y a des moments où cela ne peut être évité, donc mieux vaut prévenir que guérir!

Quels sont les inconvénients de la surallocation et de la surconfiguration des ressources (notamment la RAM) dans les environnements vSphere?

Le principal inconvénient de la surallocation des ressources est que en cas de contention, vos hôtes seraient contraints de gonfler, de passer à la mémoire virtuelle ou de planifier/dédupliquer intelligemment en arrière-plan pour donner à chaque VM la RAM dont elle a besoin.

Pour le gonflement, vSphere gonflera une "bulle" de RAM dans une VM choisie, puis donnera cette RAM gonflée à l'invité qui en a besoin. Ce n'est pas vraiment "mauvais" - les VM se volent mutuellement de la RAM, donc il n'y a pas de swapping sur le disque - mais cela pourrait entraîner des alertes incorrectes et des métriques faussées si elles reposent sur l'analyse de l'utilisation de la RAM de la VM, car la RAM ne sera pas marquée comme "gonflée", seulement qu'elle est "utilisée" par le système d'exploitation.

L'autre fonctionnalité que vSphere peut utiliser est le partage transparent des pages (TPS) - qui est essentiellement une déduplication de la RAM. Vshere analysera périodiquement toute la RAM allouée, recherchant des pages dupliquées. Lorsqu'il en trouve, il dédupliquera et libérera les pages dupliquées.

Jetez un coup d'œil au livre blanc sur la gestion de la mémoire de vSphere (PDF) - spécifiquement "La récupération de mémoire dans ESXi" (page 8) - si vous avez besoin d'une explication plus approfondie.

En supposant que les VM peuvent fonctionner avec moins de RAM, peut-on dire qu'il y a un surdépassement de configurer des machines virtuelles avec plus de RAM que nécessaire?

Il n'y a pas de surdépassement visible - vous pouvez allouer 100 Go de RAM sur un hôte avec 16 Go (cependant, cela ne signifie pas que vous le devriez, pour les raisons ci-dessus).

La mémoire totale utilisée par l'ensemble de vos VM est la courbe "Active" affichée dans vos graphiques. Bien sûr, vous ne devriez jamais vous fier uniquement à ce chiffre pour calculer combien vous souhaitez surallouer, mais si vous disposez de mesures historiques comme vous le faites, vous pouvez analyser et le déterminer en fonction de l'utilisation réelle.

La différence entre la RAM "Active" et "Consommée" est discutée dans ce fil de discussion de la communauté VMWare.

Quel contre-argument opposer à : "si une VM a 16 Go de RAM allouée, mais n'utilise que 4 Go, quel est le problème?"? Par exemple, les clients doivent-ils être éduqués?

La réponse courte à cela est oui - les clients doivent toujours être éduqués sur les meilleures pratiques, quel que soit les outils à leur disposition.

Les clients doivent être éduqués pour dimensionner leurs VM en fonction de ce qu'ils utilisent, plutôt que de ce qu'ils veulent. La plupart du temps, les gens vont surestimer leurs VMs simplement parce qu'ils pourraient avoir besoin de 16 Go de RAM, même s'ils fonctionnent historiquement avec seulement 2 Go jour après jour. En tant qu'administrateur de vSphere, vous avez les connaissances, les métriques et le pouvoir de les remettre en question et de leur demander s'ils ont vraiment besoin de la RAM qu'ils ont allouée.

Cela dit, si vous associez la gestion de la mémoire vSphere avec des limites de surallocation soigneusement contrôlées, vous ne devriez pratiquement jamais avoir de problèmes en pratique, la probabilité de manquer de RAM pendant une période prolongée est relativement faible.

En plus de cela, la vMotion automatisée (appelée VMware Distributed Resource Scheduling) est essentiellement un équilibreur de charge pour vos VMs - si une seule VM commence à consommer beaucoup de ressources, le DRS devrait déplacer des VMs pour tirer le meilleur parti des ressources du cluster.

Quelle métrique spécifique devrait être utilisée pour mesurer l'utilisation de la RAM. Suivre les pics de RAM "Active" par rapport au temps?

Principalement couvert ci-dessus - votre principale préoccupation devrait être l'utilisation de la RAM "Active", bien que vous devriez définir soigneusement vos seuils de surallocation de telle sorte que si vous atteignez un certain ratio (c'est un bon exemple, même s'il peut être légèrement obsolète). En général, je resterais certainement dans les 120% de la RAM totale du cluster, mais c'est à vous de décider du ratio avec lequel vous êtes à l'aise.

Quelques bons articles/discussions sur la surallocation de mémoire :

• Surallocation de mémoire en production? OUI OUI OUI
• vSphere - Surallocation de la mémoire?
• Surallocation de mémoire dans vSphere