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 : 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

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

 

Pré requis de lecture 

VMware : Mécanisme mémoire ESXi

 

 

 

 

tps3 

 

 

 

L’annonce de VMware sur la désactivation du TPS par défaut dans les builds à partir de Décembre 2014, a fait couler pas mal de lignes sur les blogs mais suite aux différentes recherches, cela reste tout de même assez confus.

 

Nous souhaitons donc revenir légèrement dessus.

 

 

 

 

Avant tout un peu de lexique :

 

 

TPS (Transparent Page Sharing)

 

tps

 

 

 

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 scan toutes les 60 secondes et il les fait pointer vers une unique sur la RAM Hardware.

 

TPS Intra-VM (Toujours activer par défaut)
Pages mémoires identiques sur la même VMs

TPS Inter-VM
Pages mémoires identiques entres VMs

 

 

 

Exploit AES

C’est un hack découvert, permettant quand 2 VMs partagent la même page mémoire sous certaines conditions très spécifiques, de casser l’encryption AES de la clef et ainsi accéder à la machine cible depuis une autre machine d’un même ESXi.

Concernant les conditions très spécifiques, nos 2 vSavants d’hypervisor ont dépouillés les bulletins de sécurités avec test de performances  avec et sans TPS.

A voir : http://www.hypervisor.fr/?p=5298

 

 

 

Salting :

C’est un mécanisme apparu chez VMware très récemment, depuis les updates :

 

 

Grosso modo, une grande partie des utilisateurs, par simplicité, utilisent des mots de passes communs (azerty, p@ssw0rd, ….). Ceux-ci sont attachés à un hash code.

Les hackers ont un dictionnaire de mot de passe commun avec hash correspondant, et comparent donc ce dernier avec ceux de l’utilisateur. Si c’est le même Bingo, ils peuvent craquer le password.

Le salting permet de faire d’un mot de passe commun un non commun, en y ajoutant des données ce qui génère un hash aléatoire donc différents des dictionnaires de password des hackers.

 

 

 

Le problème

Par mesure de sécurité VMware a donc décidé de désactiver par défaut le TPS depuis les derniers Update d’ESXi.

Ainsi l’un des mécanismes rois de VMware se retrouve non fonctionnel.

VMware afin de se dédouaner invite les admins à l’activer manuellement.

 

 

Donc suite aux passages des updates ESXi, plusieurs problèmes peuvent apparaître :

  • Montée en charge de la consommation dans les clusters de la mémoire utilisée, car elle n’est plus partagée, et ceux immédiatement après update.
  • Les Designers d’infrastructures compte toujours lors du sizing les 20 – 30% de consommation RAM à la baisse, donc calculs à revoir selon le contexte.
  • Une gestion plus fine des VMs, car il faut voir quelles sont les populations de VMs VIP qui ne doivent en aucun cas être confrontées a cette faille.
  • Des discutions interminables inter-service

 

 

Résumé

Il n’y a pas de règle générale à appliquer, c’est au cas par cas selon les infrastructures.

Les fournisseurs de cloud public auront du mal à vendre cette faille comme une normalité à leurs clients.
Les cahiers des charges et SLA sont généralement clairs qu’aucune faille de sécurité connue est tolérable, le TPS sera donc à bannir.

Pour les environnements de prod maîtrisés où des applications non sensibles sont hébergées et les environnements VDI, la perte de ressources VS risques,  peut être démesuré.

 

 

 

 

Contrôle

 

Pour contrôler le fonctionnement des différents mécanismes de récupération de RAM faire:

  1. Démarrer ESXTOP dans la console de l’ESXi , Passez en mode mémoire en appuyant sur « m"
  2. ‘free’ de ‘PMEM /MB’ donne la mémoire disponible dans l’ESXi
  3. ‘curr’ de ‘MEMCTL/MB’ Total mémoire balloonée.
  4. ‘curr’ de ‘SWAP/MB’ donne la mémoire swappée.
  5. Dans notre contexte voir ‘PSHARE’, mais plus précisément ‘saving’ qui est le total de la mémoire sauvée via TPS

 

 

 

Réactivation ou désactivation du TPS

 

ScreenHunter_192 Apr. 01 11.27

KB 2097593

 

 

Pour Activer / désactiver le TPS il faut Activer ou désactiver le Salting sur un ESXi

  1. Connectez vous au vCenter ou ESXi
  2. Sur l’ESXi cible
  3. Configuration => Advanced Settings
  4. Dans Advanced Settings => Mem.
  5. Recherchez Mem.ShareForceSalting et passer la valeur à 0 pour réactiver TPS
  6. OK.
  7. Pour activer le changement:
    • Migrer les VMs vers un autre host puis les repasser sur l’ESXi d’origine
    • OU
    • Éteindre et allumer les VMs.

 

 

Pour désactiver le TPS pour une VM spécifique

  1. Éteindre la VM a désactiver le TPS
  2. Clic droit « Settings »
  3. General => Advanced section.
  4. Configuration Parameters….
  5. Ajouter une ligne via Add Row
  6. Ajouter le texte sched.mem.pshare.salt et mettre en valeur 2.
  7. Allumer la VM

 

 

Ou via Script pour activation sur ESXi

SCRIPT VMware se trouvant dans le KB 2097593

 

A utiliser avec les options

  • .\pshare-salting.ps1  <vcenter IP/hostname> -s -> Enables pshare salting.
  • .\pshare-salting.ps1  <vcenter IP/hostname> -o -> Turn offs pshare salting and falls back to  default TPS behavior.

 

 

 

 

 

 

 

 

En espérant que tout soit plus clair désormais pour vous.

 

 

Pour aller plus loin

 

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

 

 

 

Share