(Eng) My NPX / VCDX journey and my 2 cents advices

This post follow a previous one where I give a big thank to the vCommunity :

 

Fouad EL AKKAD, NPX-18, and VCDX-283

 

For Reminder What are those Certifications ?

They are the highest level on VMware and Nutanix certification program, that refer to the Architect Skills sets.

 

In the Nutanix Program :

 

In The VMware Program :

 

 

It has been a little while since I had to take the time to write this post, so I am enjoying a trip to Las Vegas. => Casablanca to get me started.

There are several sources on the net, so the idea is not to put a study guide but rather to give you a little feedback with 2 – 3 tips.

 

First, we have to start with the “WHY” embark yourself on such an adventure.
If it is to earn more money, I will stop you right away it is unlikely that you will go to the end especially that there is another much more effective, but if it is for a challenge and the desire to complete your skills, then I can only encourage you.

 

For my story, it has been 2 – 3 years (2013 – 2016) with my office colleagues Igor Zecevic (@zecevicigor), Bilel Kamoun (@BILKAM2), and Alban Lecorps (@AlbanLecorps); we were collecting VCP certifications / NPP (Professional) then VCAP (Advanced): DCA (Administration) & DCD (Design).

At that time, I was an engineer at the City Hall of Paris, mainly with my hands in the technique to manage, administer, and ensure high availability, without having a business-oriented view.

I had the chance to attend a Nutanix Bootcamp in September 2016 set up for free (1001 Thanks to Nutanix) in Nutanix’s Amsterdam offices and intimidated into a room with a VCDX-DTM to my right (VDI) Jason Yeo and my left two VCDX-DCV (Datacenter) Derek Seaman and Michael Wilmsen

In addition, for coach Bas Rayman (NPX) and Magnus Anderson (Double VCDX DCV and Cloud).

And, there I discover a new world of IT-architect, or behind every technical decision, there is the “why”.

 

In short, during this boot camp we went through the different silos of the architecture (Compute, Storage, Network, and BC-DR) these having to meet the requirements of Availability, Management (scalability), Performance, Recovery, and Security, and so-called AMPRS.

We had to work in a group, respond to scenarios covering each of these silos, present them and especially with the “Why” Technical and Business.

 

A new horizon opened up for me. In IT like other sciences, the more you learn, the more you realize that you do not know that much.

Back at the office, I jump on my friend Igor Zecevic to board it with me. I had to insist on one week and come back to the charge by presenting him with the skeleton of an Index of the future documentation (which was ultimately far from reality) to convince him.

So here, we are on the starting blocks, with a very recent project carried out together that needs to be documented.

 

It took us about eight months of work about 1H to 2H per day on average to arrive at the final documentation. The idea was to make a documentary based on VMware and Nutanix (Yes it works superbly together) to be able to present it to the VCDX and NPX.

 

VCDX: 1st in June 2017, superb experience but failed, this is simply the apprehension of the format of the exam, not enough preparation, and technical + soft skills gap to solve.

 

VCDX: 2nd defense nine months later on April 2018, result which also Failed. However, with the feeling of being passed not very far, the hardest was the big disappointment of failure.

 

NPX: 1st defense in November 2018, with the experience of my two previous VCDX failures and a good preparation BOOOM, I picked up the NPX-18.
I say it’s a good goal achieved I should move on to something else, but quickly the unfinished feeling comes back with the VCDX still in mind

 

VCDX: 3rd defense in June 2019 (i.e., two years after my 1st defense) with more experience in soft skills (presentation, oral, objection management) certainly with the experience of my current position as a System engineer (pre-sale) at Nutanix.

And this time Re-BOOOM it has done, I get the VCDX 283.

 

Here is my story in short, now my advice:

 

  • Do not be impressed: if I did it, others could do it. It is not just words; I went from a very technical engineer with little business knowledge to a much more complete engineer in terms of soft skills that can conduct advanced discussions with technical teams or more high level with C-Level.
  • Have good time management: especially, be regular in your work progress not to lose the thread.
  • Focus: if you are the type to quickly let go of projects you started yesterday, I am afraid this story is not for you.
  • Community: One of the most important success factors is the great community on Twitter, slack, the people there will be happy to assist you in any way possible
  • Trust on you: I remember in my documentation having made technical choices under the advice of people already VCDX, but in reality, it was not the right option and had to go back to my first choice because I knew the context and the requirements.
  • Mentor: Choose a mentor and hire him from the beginning of your documentation to avoid, a bad methodology, doing an off-topic, or writing too much technical literature that is not necessary.
  • Once the documentation is complete: the ideal thing in my opinion is not to quickly submit your document to Nutanix / VMware because once it is done, it is done.
    I would rather do some mock (defense simulation) which will allow you to readjust your document in case of error, and inconsistency.
  • ENGLISH: For non-Native speakers. Documentation and oral defense are in English, no need to be bilingual but at least be able to manage a technical conversation easily and prepare to respond quickly with pre-constructed sentences to all the questions you had during your mocks.

 

Small FAQ:

 

NPX and VCDX , what is the difference?

Very similar in the approach and content, the big difference is:

VCDX: Oral 2 modules on the VMware stack

Defense: 75-minute presentation of the architecture of your documentation

Scenario: this is a 45-minutes session of White Boarding; simulate an architectural consulting meeting with a panel of VCDX playing the role of customers

 

NPX: Oral 3-module one the Nutanix SDS and 2 Hypervisors

Note that the Nutanix SDS solution is multi-Hypervisor (AHV – ESXi – Hyper-V)

Defense: 125-minutes presentation of the architecture of your documentation with your use case’s hypervisor

Scenario: Just like VCDX 60-minutes simulation with Whiteboarding but under a Hypervisor that differs from the one in your documentation.

Troubleshoot: 45-minutes session where you have to solve a technical or performance problem always under a Hypervisor that differs from the one in your documentation (but the same as the module of the scenario)

 

  • How many pages minimum?

I would say at least 75/100 pages; for me, the difference comes from your experience. You can be super concise in your writing because you have the experience and technical background to answer any question quickly by justifying even if it is not in your document. If not, you can go further in your documentation to detail more and prepare for panel questions.

 

  • How long does it take for documentation?

It all depends, but allow at least six months by being regular in the work.

 

  • Can I have your document to see what it actually represents?

No, without even having to justify for a bunch of obvious reasons

 

  • Where to start?

My advice would be to prepare and pass the VMware VCAP-DCD Design certification that will allow you to acquire the basics and jargons of design discussions.

Off Course the Blueprints:

NPX : https://www.nutanix.com/go/nutanix-platform-expert-npx

VCDX-DCV : https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/certification/vmw-vcdx6-dcv-blueprint.pdf

 

Then see the summary examples:

Derek Seaman:

NPX: https://www.derekseaman.com/2018/06/nutanix-npx-architecture-guide-how-to-part-1.html

VCDX: https://www.derekseaman.com/2014/10/sample-vcdx-dcv-architecture-outline.html

Gregg Robertson:

https://thesaffageek.co.uk/2017/05/15/vcdx-preparation-advice/

And an example of documentation provided by Duncan Epping:

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/cloud-infrastructure-achitecture-white-paper.pdf

Rene’s blog VCDX133 with a series of extremely useful articles.

VCDX : https://vcdx133.com/2015/01/27/vcdx-series/

NPX: https://vcdx133.com/2015/03/06/nutanix-platform-link-o-rama/

The same goes for Dereck Sieman blog:

https://www.derekseaman.com/2014/07/vcdx-link-o-rama.html

https://www.derekseaman.com/2018/04/my-journey-to-nutanix-platform-expert-npx-014.html

 And Read everything you could find on the internet.

 

  • After VCDX NPX, will I get a new villa and Tesla?

Uh not really do not expect fundamental changes but it all depends on your organization, this can clearly be a lever in some cases.

 

 

 

 

Share

Thank you for my NPX / VCDX numbers

 

I have been thinking about this post from the early beginnings of my NPX / VCDX journey, the whole journey took a bit more time than I had planned for but finally, it’s time.

It’s time to be thankful, recognize all the great help that I received during my journey and I know without the vCommunity it wouldn’t have been possible.

Thanks, first of all to my family for the patience and time they gave me to allow me to work on the documentation, the mocks and travel, helping me through the lows of failing and the highs of passing.

My second thanks is for Igor Zecevic @zecevicigor ‏, my partner in crime as we did a joint submission, I owe a great deal to him as he was a large part of my success.

So now here comes a super large list of people, which helped me in various ways with documentation reviews, mocks, advice, blog posts and many many other things!

I don’t want prioritize them as I believe that would be unfair, I mean people that didn’t even know who I was, were willing to give up their free time to help me in various ways and that is a huge deal!!!!!

Now as you see, a load of people were involved in my 2 year journey in getting to this NPX / VCDX and I hope I am not forgetting anyone, but my success is their success too.



Bilal Ahmed @Dark_KnightUK

ShadyElMalatawey @ShadyMalatawey

Bilel Kammoun  @BILKAM2

Adil Ehajiz  @ELHAJIZADIL

Magnus Anderson @magander3

Bas Raayman@BasRaayman

Abdullah @do0dzZZ

Manny Sidhu @MannySidhu2

Brett Guarino @Brett_Guarino(before being on panelist path)

Gregg Robertson @GreggRobertson5

Dominik Zorgnotti @vDominikZ(before being on panelist path)

Per Thorn @per_thorn

Jason Gierson @JasonTweet7889

Rebecca Fitzhugh @RebeccaFitzhugh 

Ramandeep Singh @rdsinghc

Sylvain Huguet @vshuguet

Alexandre Arrive @aArriveCornec

Gatien GHEZA @GatienGHEZA

Damien Raynal @DamRay

Kalen Arndt @kalenarndt

Josh Odgers @josh_odgers

Kiran Reid @Apollokre1d 

Scott Bowe @scottrbowe

Chris Porter @uprightvinyl 

Samuel Rothenbühler @bancswissunique

Nabil RIZK @nabsrizk

Kim Bottu @Kim_Bottu

Paul McSharry @pmcsharry (before being a panelist)

vincenthan @vincenthan 

Brian Suhr @bsuhr 

Sylvain Huguet @vshuguet 

Ben Mayer @benediktmayer

Paul Meehan @PaulPMeehan

Simon Long @SimonLong_ 

Eric Fourn @Efourn 

René van den Bedem @vcdx133

Mohammed Salem @vmSalem 

Mike Brown @VirtuallyMikeB

Timo Sugliani @tsugliani 

Simon Z @RockingKeats

Anton Davidovskiy @adavidovskiy

Daniel RIVIERE

Share

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

 

 

 

 

 

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 

 

 

 

 

 

 

 

 

Share

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

 

Prérequis à cette article :

 

 

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 :

 

 

 

 

 

 

Share