VMware : State mémoire de l’ESXi (High, Clear, Soft, Hard & Low)

 

 

Suite à notre article sur l’exploitation de TPS et pour  compléter notre Deep Dive sur la gestion mémoire de l’ESXi.

On va se tourner sur l’exploration des « states »  ESXi sous vSphere 6, car en v5 les seuils ne sont pas les mêmes

 

 

 

Prérequis de lecture

VMware : Mécanisme mémoire ESXi

 

TPS or Not, Salt, Salting, Exploit AES, ESXi 5.5 u2, ESXi 6, …… Mise au clair

 

VMware : ESXi – Large Page OR NOT Large Page – Telle est la question ?

 

 

 

Lors de la montée en charge RAM d’un hôte, celui-ci peut passer par différents états. Je dis « peut » car si  l’Overcommitment  n’est pas votre truc alors l’ESXi sera toujours à l’aise dans ses chaussures.

Si vous le torturez un peu voir beaucoup, vous pourriez obtenir ces 5 états avec leurs actions (Je dis bien pourriez car pas simple à observer).

 

 

Memory state
Seuil Actions 
High 400% de minFree Casse les « Larges Pages » en dessous de ce Seuil
Clear 100% de minFree Casse les « Larges Pages » en dessous de ce Seuil et sollicite activement TPS pour Dédup mémoire
Soft 64% de minFree TPS + Balloon
Hard 32% de minFree TPS + Compress + Swap
Low 16% de  minFree Compress + Swap + Block de VM (la CATA)

 

 

 

Qu’est ce que le « minFree »

C’est tout simplement une valeur fixe qui est calculée sur la base de la RAM totale de votre ESXi, qui associée à des seuils permettra de définir sur qu’elle « State » l’ESXi est.

 

 

Comment elle est calculée ?

Pour les premiers 28Go RAM, une valeur fixe de 899Mo est définie. Ensuite on ajoute 1% du delta RAM entre RAM total et 28Go.

Pourquoi ces 899Mo pour les premiers 28Go. Tous simplement pour les petits ESXi, cette valeur fixe permet de se garder un seuil minimum de RAM pour faire tourner le kernel.

 

 

Exemple :

avec un ESXi de 100Go 

  1. Pour les 28Go => 899Mo
  2. RAM Delta => 100000 M0 – 28000 Mo = 72000 Mo
  3. 1 % de 72000 Mo = 720Mo
  4. minFree = 899 Mo + 720 Mo = 1619 Mo

 

 

 

Un exemple réél

Avec un ESXi de 400Go RAM (indiqué exactement 393.11Go)

Sous votre ESXi, taper « esxtop » puis « m »

2016-11-17_16h42_34

 

  1. Pour les premiers 28Go (28000Mo) => 899Mo
  2. RAM Delta => 393110 Mo – 28000 Mo  = 365110 Mo
  3. 1 % de 365110 Mo ≅ 3651 Mo
  4. minFree = 899 Mo + 3651 Mo  =  4550 Mo (à quelques pouillèmes près on retrouve notre 4541 du Screeshot)

 

 

 

 

State High

Donc en reprenant notre exemple (minFree de 4541 Mo), tant que la RAM disponible est au dessus des 400% de minFree, soit 18164 Mo nous sommes dans le state High.

Nous avons 357Go de RAM disponible, bien au dessus des 400% de minFree (18Go)

2016-11-17_16h48_09

 
Actions

L’ESXi est en mode vitesse de croisière, et n’active que le mécanisme TPS

2016-11-17_16h52_50

 

 

 

 

State Clear

C’est un nouveau State qui n’existait pas sous vSphere 5, il est très similaire au « High » il se déclenche lorsque la RAM libre passe au dessous des 400% du minFree et on passe à un autre state une fois le minFree atteint.

 
Actions

Vu qu’on a atteint un niveau plus poussé de conso RAM l’hôte ne vas plus se baser sur le Schedule TPS, mais il va le pousser à dedup de plus en plus de RAM.

minFree à 13487 en dessous du seuil High (400%minFree = 18164)

2016-11-23_17h43_41

 

 

 

 

Pour les states suivants, nous n’avons pas réussi a générer clairement et surtout de manière fixe chaque state, car les seuils étant très rapprochés les mécanismes ZIP, SWAP & Ballooning s’active très rapidement

 

State Soft

On ne va pas vous refaire la musique, ce state se déclenche une fois le seuil du minFree atteint et on passe à un autre state une fois 64% du minFree atteint.

 

Actions

On active le TPS + Ballooning

 

 

 

State Hard

Entre 64% minFree et 32% minFree

 

Actions 

TPS + Compress + Swap

 

 

 

 

State Low

Entre 32% minFree et 16% minFree

 

 

Action

Si sur de la PROD, on signe la lettre de démission et on se sauve avant que tout implose.

Compression + Swap + Block de VM (la CATA)

Block : indique que toute VM qui sollicitera de la RAM seront bloquées jusqu’au retour du State « Hard »

 

 

 

 

 

Share

VMware : Mécanisme mémoire ESXi

 

Nous dépoussiérons un sujet largement abordé mais malheureusement manquants à notre blog mais aussi pour compléter notre Deep Dive sur la gestion RAM ESXi

On va donc essayer de vous faire un condensé d’informations sur les mécanismes d’optimisations de RAM.

Les mécanismes de récupérations de RAM s’exécutent séquentiellement, selon l’état de l’ESXi (article explicatif prochainement)

  1. TPS : Transparent Sharing
  2. Ballooning
  3. Compression
  4. Swap

 

 

Page mémoire

La mémoire vivre est divisée en une multitude de petit bloc allouable. Ainsi une VM qui exécute un processus en mémoire aura allouée une page mémoire physique de l’ESXi

Une page peut être de différentes tailles, selon l’OS et l’application sollicitant la RAM

  • Petite page : 4Kb (OS 32 bits, application non memory-vore)
  • Large pages : 2Mb (OS 64 Bit, Base de données SQL, Oracle,…)

 

Afficher l'image d'origine

 

 

Overcommitment :

Donner plus de mémoire virtuelle à l’ensemble des VMs que l’ESXi peut avoir en mémoire physique

 

 

 

Transparent Page Sharing

TPS est le mécanisme VMware qui permet de mutualiser les pages mémoires générées par les VMs sur le même ESX.

Si plusieurs OS similaires tournent sur le même Host, il est très probable que les VMs aient de nombreuses empreintes mémoires identiques. Au lieu de multiplier les pages mémoires, TPS les scans toutes les 60 secondes et il les fait pointer vers une unique sur la RAM Hardware (Dé duplication de mémoire).

Le TPS n’est actif que sur les pages mémoires standard (4KB)

Les Larges Pages (2 MB) ne peuvent utiliser cette fonctionnalité 

tps

 

 

Ballooning

Le ballooning est une fonctionnalité gérée par le pilote vmmemctl, installé avec les VMware Tools.

  • Une VM a besoin d’avantage de mémoire physique
  • La VM lance un appel au Vmkernel (Noyau de l’ESXi)
  • Le VMkernel demande à toutes les VMs (équipées des Tools) d’allouer une partie de leur mémoire non consommée (mais réservée) au pilote vmmemctl
  • Le pilote verrouille la mémoire demandée, signale au VMkernel que ces emplacements sont disponibles
  • Le VMkernel redistribue la mémoire à la VM qui a besoin de mémoire
  • Le pilote vmmemctl peut réserver au maximum 65% de la mémoire allouée.

Afficher l'image d'origine

 

Compression :

Si le TPS & Balloning n’ont pas réussi à libérer assez de mémoire, le VMkernel se met à scanner les pages zippable. Si une page peut être compressée à plus de 50% elle sera zippée.
Ce mécanisme est mis juste avant le SWAP car il est plus rapide de zipper – dézipper une page mémoire en RAM, que de venir la récupérer sur un disque mécanique.

 

 

Swapping :

Si tous les mécanismes précédents n’ont pas permis de libérer assez de mémoire alors l’ESXi se met à swapper, c’est-à-dire à copier les pages mémoires sur disque et la c’est la CATA coté perf

 

 

 

 

 

 

Pour observer les différents états RAM :

 
Dans les graphes de performances sous le client vSphere :

Petite légende :

  • Shared => TPS
  • Swap Used => la métrique SWAP EXi
  • Swap IN => Quantité de mémoire sortie du Swap (De Disque vers RAM)
  • Swap OUT => Quantité de mémoire Swappé (De la RAM vers Disque)
  • Active : Mémoire réellement utilisé par le vMkernel pour faire tourner le Workload
  • Granted : somme des mémoires VMs configurées
  • Consumed : Toutes les pages mémoires touchés (Très souvent identique à Granted)

 

 

 

Sous ESXTOP

Esxtop => Touche « m »

  • PMEM : Mémoire physique
  • PSHARE : Transparent Page Sharing
  • SWAP : .SWAP => Idéalement à 0
  • ZIP : Compression idéalement à 0
  • MEMCTL : Ballooning idéalement à 0

 

 

Pour aller plus loin 

 

TPS or Not, Salt, Salting, Exploit AES, ESXi 5.5 u2, ESXi 6, …… Mise au clair

 

 

 

 

 

 

 

Share

VMware : ESXi – Large Page OR NOT Large Page – Telle est la question ?

 

Prérequis à cette article :

VMware : Mécanisme mémoire ESXi

 

TPS or Not, Salt, Salting, Exploit AES, ESXi 5.5 u2, ESXi 6, …… Mise au clair

 

Explication 

TPS est arrivé aux jours, ou les VMs avaient des OS principalement 32 bits avec des pages mémoires à 4kb (Rappel : TPS ne fonctionne pas avec les larges pages supérieures à 2MB)

C’était révolutionnaire car ceci permettait d’économiser sur de la production jusqu’à 20% de RAM et pour du VDI jusqu’à 50%.

Avant d’aborder le contexte d’aujourd’hui et les OS 64 bits, il est important de définir un des mécanismes de mappage mémoire, le TLB

 

TLB selon Wikipedia en 1 phrase 

Le translation lookaside buffer, ou TLB, est une mémoire cache du processeur utilisée par l’unité de gestion mémoire (MMU) dans le but d’accélérer la traduction des adresses virtuelles en adresses physiques.

En gros c’est le sommaire, la table d’adressage entre la mémoire virtuelle et la mémoire physique.

C’est un cache de taille très limitée, donc avec des pages mémoires à 4MB vous comprendrez que c’est plus rapide de la traverser.
Mais avec des pages mémoires à 4KB, la table est beaucoup plus importante donc plus coûteuse en cycle CPU afin de la traverser.

Exemple : VM de 2Go RAM

  • 2048MB/4KB=512.000 => entrées pour pages à 4kb
  • 2048MB/2.048MB =1000 => entrés pour pages à 2MB
  • Ratio de 512

 

Avec les serveurs de plus en plus sizés en RAM, c’est naturellement que les éditeurs se redirigent vers des Larges Pages (2MB) car pour certaines instructions mémoire, c’est plus performant et aussi moins coûteux en cycle CPU dû au « sommaire » moins important.

Donc nos OS d’aujourd’hui fonctionnent majoritairement en page de 2MB mais cela n’arrange pas notre TPS et notre besoin d’Overcommit.

Vous pouvez alors complètement désactiver les Larges pages, mais cela risque de porter atteintes aux performances VM, via l’option « Mem.AllocGuestLargePage« 

Descriptif VMware : ICI

2016-11-10_14h42_48
Mem.AllocGuestLargePage

  • Pour désactiver les Larges Pages => 0
  • Pour activer les Larges Pages => 1

2016-11-10_14h38_05

 

 

 

Large Page On Demand

Mais il existe une autre option qui est plus connu sous « Large Page On Demand », qui permet d’allouer des Larges Pages exclusivement lorsque l’OS et plus précisent l’application en fera la demande.

Ainsi une bonne proportion des pages mémoires allouées seront de 4kb donc admissible au TPS.

Options : 

LPage.LPageAlwaysTryForNPT

  • Pour désactiver les Larges Pages => 0
  • Pour activer les Larges Pages => 1

 

2016-11-10_14h51_15

 

2016-11-10_14h50_03

 

 

 

Assez d’explication passons aux Tests

Serveur :

  • Nutanix Supermicro NX-3060-G4
  • 390 Go de RAM
  • Intel Xeon E5-2660 v3 2 x 10 Coeurs à 2.6Ghz

 

 

Test 1

On va envoyer une grosse boite de VMs sur un ESXi.

Pour simuler un Workload de Production, on lance la création et démarrage de 300 VMs, merci au Nutanix Fast Clone pour cloner 300 VMs en quelques minutes (Honnêtement moins 10) :

  • 100 x Windows 2012 (OS seul)
    Pour tester sans application 
  • 100 x Windows 2012 + SQL server
    Avec une Application friand des Larges Pages
  • 100 x Debian 7 32 Bits
    Ne travaillant qu’avec des Petites Pages (4KB)

 

On active le LPage.LPageAlwaysTryForNPT à 0

On démarre le tout, et tout de suite ce que l’on remarque c’est le CPU qui s’emballe. En effet comme vue ensemble le CPU est très sollicité pour les SCAN des pages mémoires

2016-11-10_16h36_22

 
Niveau mémoire, au début qu’une infime partie Shared (Page de démarrage remplit de 0) est dedupliquée, puis on observe le Sharing qui commence à prendre sa place gentillement et gagner du terrain.

2016-11-10_16h51_39

 

On le laisse tourner pour voir enfin une récupération effective au bout de plus d’une heure de Scan et dedup RAM.

2016-11-10_17h18_02

 

 

Coté CPU la tempête passée, le CPU retrouve une consommation normale.

2016-11-10_17h41_21

 

 

Résultat du Test 1 :
  • Plus de 300 VMs de config différentes déployées.
  • Plus de 225Go de RAM sauvée (et ça monte, ça monte)
  • 0 SWAP, 0 compression – 0 Ballooning
  • Memory Overcommit de 0.59 et avec 150Go de RAM de dispo on aurait pu pousser bien plus loin

2016-11-10_17h44_48

 

 

Test 2 

On s’est amusé à déployer 1024 VMs Debian 32Bits (fonctionnant avec des pages de 4kb) de config 1vCPU et 2Go RAM

 

Résultat Test 2 :
  • 157Go RAM sauvegardé via TPS
  • 0 SWAP – 0 Compression – 0 Ballooning
  • Overcommitment de malade à un ration de plus de 4 et avec encore un boulevard devant nous car 260Go de RAM sont disponible

2016-11-21_18h15_06

 

 

 

Test 3 

On a voulu taper dans de la plus grosse VM, donc à cloné 201 vRA 7 appliance 64bits (VMware vRealize Automation). Et la on a le TPS qui monte qui monte.

VM : 1vCPU & 18Go RAM
Notre but était de saturer l’ESXi mais TPS fait trop bien son JOB.

Résultat Test 3 :
  • 322Go RAM sauvegardé via TPS
  • 0 SWAP – 0 Compression – 0 Ballooning 
  • Overcommitment de malade à un ration de plus de 8, mais la sur allocation ne veut rien dire car ce sont des VM de 18Go de RAM configurées et elle ne consomme que 1.5Go)

2016-11-22_17h25_15

 

 

 

 

 

On reprend l’expression de nos Sensei qui nous on inspiré à faire ces tests Hypervisor.fr

Moralité, TPS c’est bon, mangez-en !

 

 

 

 

Pour aller plus loin :

 

VMware : State mémoire de l’ESXi (High, Clear, Soft, Hard & Low)

 

 

 

 

 

Share

Déterminer le type de RAID selon les charges de travail des VMs

Nous allons présenter dans cet article les avantages des différents RAID selon les charges de vos VMs. Pour des VMs ayant beaucoup d’accès en lecture, il est préférable d’utiliser le RAID 5 ou le RAID 6. A l’inverse, pour des VMs ayant beaucoup d’accès en écriture, il est préférable d’utiliser le RAID 1 ou le RAID 1+0.

Par exemple votre VM a besoin de 500 IOPs. Votre VM fait beaucoup d’accès en écriture et peu en lecture : 30% lecture et 70% écriture.

Vous pouvez utiliser la formule suivante pour déterminer quel RAID correspond le mieux à votre charge de travail : (IOPs total requis * lecture%) + (IOPs total requis * écriture% * RAID penalty) = (total IOPs requis)

Total IOPS : Total Lecture IOPs: 150 et Total Ecriture IOPs: 350
IOPS per RAID Set :

– Total IOPs for a RAID0 set: 500
– Total IOPs for a RAID10 set: 850
– Total IOPs for a RAID5 set: 1550
– Total IOPs for a RAID6 set: 2250

Disks per RAID Set

– Total Disks for a RAID0 set: 3
– Total Disks for a RAID10 set: 6
– Total Disks for a RAID5 set: 9
– Total Disks for a RAID6 set: 13

Ces résultats montrent bien que lorsqu’une VM a besoin de performance en écriture il est préférable de la mettre sur du stockage en RAID 0, RAID 1 et RAID 1+0.
Vous pouvez utilisez le lien suivant pour faire certains calculs : http://www.eprich.com/tools/simple-raid-group-calculator

Il existe un outil très intéressant pour déterminer les caractéristiques des I/O de votre VM : il s’agit de vscsiStats.
Vous pouvez utilisez cet outil depuis le shell (console ou ssh) sur votre esxi.

Vous pouvez lister vos VMs en tapant la commande suivante : vscsiStats -l
(ESXi est sensible à la casse)
La commande liste toutes les VMs de l’ESXi avec leur worldGroupID et l’handleID de chaque vmdk.

Exemple :

Si vous voulez récupérer des informations pour tous les disques d’une VM, tapez la commande suivante : vscsistats -s -w worldGroupID


Si vous voulez récupérer des informations pour un disque en particulier sur une VM, précisez le handleID : vscsistats -s -w worldGroupID -i handleID

Après la récupération des informations, vous pouvez utiliser la commande suivante pour voir la latence : vscsistats -p latency

La latence est en micro-secondes. Vous pouvez récupérer les informations suivantes :

vscsistats -p seekDistance
vscsistats -p outstandingIOs
vscsistats -p interarrival
vscsistats -p ioLength

Share