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

Service « VMware Workstation Server » ne démarre pas / Not Start / Won’t start

Probleme

Sous VMware Workstation 12.1.1 et Windows 8.1

 

Petite misère mes VM s’allument, se ping entre elle, mais impossible depuis mon Windows de pinguer mes VMs qui sont sous la configuration réseau  « Host-Only »

 

Direction le gestionnaire de service et nous voyons que le service « VMware WorkStation Server »  est arrêté.

1

 

Impossible de le démarrer, on jette un œil sur les journaux d’événements et comme d’Hab le charabia MS.

3

 

 

J’ai tenté la désinstallation de VMware Workstation passage de ccleaner, toujours rien.

 

Solution 

Bah la solution toute simple

Allez dans :

C:\ProgramData\VMware\hostd

Supprimer ou renommé le fichier « DataStore.xml » et c’est reparti

2

 

 

On redémarre le service et ça repart

4

 

 

 

 

Share

VMware : vCPU Hot ADD oui mais pas pour SQL Standard

sql-hotadd

 

 

 

La fonctionnalité hot add arrivée avec vSphere 5.1, permettant d’ajouter à chaud un ou plusieurs vCPU à nos petites VMs, est une fonctionnalité facilitant énormément les processus d’exploitations. Évitant ainsi des échanges de mails interminable pour avoir une fenêtre de maintenance.

 

Les conditions requises sont :  

  • Etre en minimum VMware Hardware 8
  • Activer la fonctionnalité machine éteinte
  • Avoir la bonne version de Windows 

2016-05-09_14h27_45

 

 

Mais attention à SQL server (à partir de SQL server 2008), seul l’Editions Entreprise suppote le Hot Add

Source : https://technet.microsoft.com/en-us/library/bb964703(v=sql.105).aspx

 

Requirements for hot add CPU:

  • Requires the 64-bit edition of Windows Server 2008 Datacenter or the Windows Server 2008 Enterprise Edition for Itanium-Based Systems operating system.
  • Requires SQL Server Enterprise

 

 

Donc faire bien attention pour un SQL server Standard, il vous faudra redémarrer votre VMs

 

Si vous êtes dans la bonne édition, il se peut que les nouveaux vCPU ne soit pas vu automatiquement par le moteur SQL.

Pour se faire rien de plus simple vérifier avant de passer la commande SQL ci-dessous dans les propriété de votre instance sous Processeurs le nombre de vCPU utilisé par le moteur SQL.

2016-05-09_14h45_24

2016-05-09_14h01_39

 

 

Passer la requête SQL :

 

 

Rejeter de nouveau un œil sur les propriétés de votre instance, vous devriez voir vos nouveaux vCPU

2016-05-09_14h45_49

 

 

 

 

 

 

 

Share