Comment la mémoire est-elle allouée sur le serveur ESXi?

Nous avons un serveur ESXi 4.1 avec 48 Go de RAM.

Pour chaque machine virtuelle, nous allouons 4 Go de mémoire. Puisque le serveur aura 13 machines virtuelles, mon manager pense que c'est faux.

Je vais leur expliquer qu'ESXi va gérer la mémoire elle-même, mais ils m'ont demandé combien de mémoire j'avais alloué pour le serveur ESXi lui-même.

Je n'en ai pas alloué (je n'ai même pas entendu parler d'une option d'allocation de mémoire pour le serveur ESXi lui-même).

Comment la mémoire est-elle allouée au serveur ESXi? Comment peut-il surallouer / distribuer la RAM entre les machines virtuelles sans problème?

Il y a beaucoup plus que juste ESXi en question ici,

1. Chaque machine virtuelle consommera jusqu'à 4 Go + «frais généraux», ce qui est documenté ici . Cela dépend des vCPU, + de la mémoire allouée. Au minimum, chaque machine virtuelle utilisera 4261,98 Mo (4096 + 165,98)
2. La surcharge de mémoire propre à ESXi, cela dépend du matériel. L'option la plus simple consiste à examiner l' utilisation de la mémoire système dans le client vSphere. De mémoire, je me souviens que c'est autour de la marque de 1,3 Go, mais comme indiqué, cela dépend beaucoup du matériel.

Explication de l'allocation de mémoire et du surengagement

Notez que l'hyperviseur n'allouera pas toute cette mémoire à l'avance , il dépend de l'utilisation de la machine virtuelle. Cependant, il vaut la peine de comprendre ce qui se passera si les machines virtuelles tentent d'allouer et d'utiliser toute la mémoire qui leur est allouée.

Le maximum que votre hôte VM + essaiera d'utiliser sera approximativement, le kilométrage de 55 Go peut varier

• 1,3 Go utilisé par ESXi
• 4261,98 Mo * 13 utilisés par les machines virtuelles

Il y a un autre aspect à prendre en compte et ce sont les seuils de mémoire. Par défaut, VMware visera à disposer de 6% d'espace libre (seuil de mémoire élevé). Ainsi, les 55 Go de mémoire utilisée doivent être réduits à environ 45 Go

Cela signifie que l'hôte aura environ 10 500 Mo de mémoire dont il a besoin pour récupérer quelque part si les machines virtuelles utilisent la mémoire qui leur a été allouée. ESX fait trois choses pour trouver ces 10,5 Go supplémentaires.

Méthodes de récupération de mémoire

1. Partage de page transparent
2. Ballon de mémoire
3. Échange d'hyperviseur

Vous devez lire et comprendre Comprendre la gestion des ressources mémoire dans VMware® ESX ™ Server .

En fonction d'un grand nombre de facteurs, une combinaison des trois se produira / pourrait se produire sur un hôte trop engagé. Vous devez tester votre environnement et surveiller ces mesures pour comprendre l'impact du sur-engagement.

Quelques règles approximatives qui valent la peine d'être connues (toutes dans l'article ci-dessus et d'autres sources).

1. Le partage de page transparent ne se produit pas pour les machines virtuelles qui utilisent des pages de 2/4 Mo. Comme vous avez alloué 4096 Mo à vos machines virtuelles Windows, elles utiliseront les pages 2/4 Mo par défaut (en fonction de PAE). Ce n'est que sous la pression de la mémoire que VMware divisera les grandes pages en pages de 4 Ko pouvant être partagées. TPS repose sur l'utilisation de cycles CPU inactifs et la numérisation des pages mémoire à un certain rythme. Il renvoie la mémoire relativement lentement (pensez à une heure plutôt qu'à des minutes). Donc, une tempête de démarrage signifie que TPS ne vous aidera pas. Sur les trois, cela a le plus faible impact sur les performances. Plus du document,

Dans les systèmes de virtualisation de mémoire assistée par matériel (par exemple, Intel EPT Hardware Assist et AMD RVI Hardware Assist [6]), ESX sauvegardera automatiquement les pages physiques invitées avec de grandes pages physiques hôtes (région de mémoire contiguë de 2 Mo au lieu de 4 Ko pour les pages normales) pour meilleures performances grâce à moins de ratés TLB. Dans de tels systèmes, ESX ne partagera pas ces grandes pages car: 1) la probabilité de trouver deux grandes pages ayant un contenu identique est faible, et 2) le surcoût de faire une comparaison bit par bit pour une page de 2 Mo est beaucoup plus grand que pour une page de 4 Ko. Cependant, ESX génère toujours des hachages pour les pages 4KB dans chaque grande page. Étant donné qu'ESX n'échangera pas de grandes pages, lors de l'échange d'hôte, la grande page sera divisée en petites pages afin que ces hachages pré-générés puissent être utilisés pour partager les petites pages avant qu'elles ne soient échangées. En bref, nous ne pouvons observer aucun partage de page pour les systèmes de virtualisation de mémoire assistée par matériel tant que la mémoire hôte n'est pas surchargée.

1. La montgolfière intervient ensuite (les seuils sont configurables, par défaut, c'est lorsque l'hôte dispose de moins de 6% de mémoire libre (entre élevé et logiciel)). Assurez-vous d'installer le pilote et faites attention à Java et aux applications gérées en général. Le système d'exploitation n'a aucune idée de ce que le ramasse-miettes fera ensuite et il finira par frapper les pages qui ont été échangées sur le disque. Il n'est pas rare que les serveurs qui exécutent des applications java exclusivement désactivent le swap pour garantir que cela ne se produise pas. Jetez un œil à la page 17 de vSphere Memory Management, SPECjbb

2. La permutation d'hyperviseur , parmi les trois méthodes, est la seule qui garantit que la "mémoire" est disponible pour l'hyperviseur dans un temps défini. Ceci sera utilisé si 1 & 2 ne lui donnent pas assez de mémoire pour rester sous le seuil dur (par défaut 2% de mémoire libre). Lorsque vous lisez les mesures de performance (faites les vôtres), vous vous rendrez compte que c'est la pire performance des trois. Essayez de l'éviter à tout prix, car l'impact sur les performances sera très visible sur presque toutes les applications, pourcentage à deux chiffres

3. Il y a un autre état à connaître de faible (par défaut 1%). D'après le manuel, cela peut considérablement réduire vos performances,

Dans un cas rare où la mémoire libre de l'hôte tombe en dessous du seuil bas, l'hyperviseur continue de récupérer de la mémoire par échange et compression de mémoire, et bloque en outre l'exécution de toutes les machines virtuelles qui consomment plus de mémoire que leurs allocations de mémoire cible.

Sommaire

Le point clé à souligner est qu'il est impossible de prédire à partir des livres blancs comment se comportera votre environnement.

1. Combien TPS peut-il vous donner? (Cela dépend de la similitude de vos machines virtuelles avec leur système d'exploitation, Service Pack et applications en cours d'exécution)
2. À quelle vitesse vos VM allouent-elles votre mémoire? Plus ils le font rapidement, plus vous avez de chances de passer au seuil suivant avant que le schéma de récupération de mémoire le moins impactant réussisse à vous maintenir dans votre seuil actuel.
3. Selon l'application, chaque schéma de récupération de mémoire aura un impact très variable.

Testez vos scénarios moyens, vous êtes un scénario à 95% et enfin votre maximum pour comprendre comment votre environnement fonctionnera.

Modifier 1

Il convient d'ajouter qu'avec vSphere 4 (ou 4.1 ne se souvient pas), il est maintenant possible de placer l'échange d'hyperviseur sur le disque local mais toujours de vmotion la VM. Si vous utilisez un stockage partagé, je vous recommande fortement de déplacer le fichier d'échange d'hyperviseur pour qu'il soit sur le disque local par défaut. Cela garantit que lorsqu'un hôte est soumis à une pression de mémoire sévère, cela n'impacte pas tous les autres hôtes / machines virtuelles vSphere sur le même stockage partagé.

Modifier 2

Sur la base des commentaires, fait le fait que ESX n'alloue pas la mémoire à l'avance en gras ...

Modifier 3

Expliqué un peu plus sur les seuils de mémoire.

VMware (et d'autres technologies de virtualisation) partagent des ressources (mémoire, temps processeur, E / S de divers types) entre machines virtuelles selon différents algorithmes.

Il est posssible de overcommit ressources, car toutes les machines virtuelles utilisera tout le traitement, la mémoire ou E / S dont ils ont besoin tout le temps. Le guide de gestion des ressources de VMware est probablement le meilleur endroit pour lire ce qui est possible dans ESXi.

Vous pouvez également gérer l'effet des algorithmes en pondérant différentes VM pour différentes ressources - par exemple, vous pouvez donner à une VM de serveur d'applications une pondération plus élevée pour le processeur qu'une VM de serveur de fichiers. Cependant, les paramètres prêts à l'emploi gèrent très bien la plupart des exigences. Dans certains cas, faire une configuration ici suffit à apaiser les gestionnaires qui ne l'obtiennent pas tout à fait, mais bien sûr, soyez prudent et lisez les documents de votre version de VMware et comprenez ce que vous faites. Si votre gestionnaire n'a pas besoin de placement supplémentaire, utilisez simplement les valeurs par défaut.

Notez que le surengagement n'est pas nécessairement toujours une bonne idée, en particulier si vous avez virtualisé sur un seul serveur. Vous devez surveiller votre utilisation des ressources dans votre domaine ESXi et, si nécessaire, ajouter des hôtes / ressources supplémentaires si vous consommez fréquemment toutes les ressources.

Laissez votre installation VMWare ESXi s'en occuper. Vous pouvez surcharger les ressources RAM sur les systèmes VMWare en raison de son utilisation des techniques de gonflement de la mémoire, de compression et de déduplication .

Si les machines virtuelles utilisent un système d'exploitation similaire, vous réalisez des économies. Veillez à activer les outils VMWare à l'intérieur des machines virtuelles invitées pour utiliser pleinement ces fonctionnalités.