Meme Google ne l’a pas (plus) dans son cache! Que penser de tout ca? )

Pyro de donne la définition exatce de l’overcommit façon VMWARE et pourtant tu t’arrêtes au balooning…

Quant aux pb de perfs, sur Hyper-V c’est assez explicite avec le curseur façons “slider” …C’est soit perf, soit consolidation…

Et comme le fait justement remarqué PiroNet, il y a différentes techniques d’overcommit. Celle de MS n’échappe pas à une potentielle dégradation des perfs si toutes les VM tentent toutes d’utiliser la RAM qui leur a été allouée. Ça swapera DANS la VM mais ca reste de l’overcommit. Chez nous on appelle ca du ballooning

En fait le Dynamic Memory de Microsoft s’apparente plus au Ballooning de VMware; grosso modo je recupere de la memoire non utilisee d’une VM x pour la donner a une VM y qui en demande.

Il faut savoir que le Memory Overcommit est une suite de techniques utilisees pour gerer la memoire au mieux et ayant comme buts avoues de consolider et d’utiliser les resources memoire au maximum.

Dans le Memory Overcommit on retrouve:
-le Tranparent Page Sharing, cad je garde en memoire qu’une copie de tout les blocks memoire identiquent.
-Ballooning, la memoire non-active d’une VM est re-assignee a une autre VM qui en demande.
-En dernier lieu, ds le cas ou les 2 premieres techniques n’ont pas su liberer la memoire reclamee par une VM (dans la limite de sa configuration memoire) le swapping sur disque est active. C’est clairement mortel au niveau perf et cela necessite que le vAdmin revoit l’allocation memoire de ses VM et les priorites (shares).

Dans la version vSphere 4.1, une nouvelle technique apparait avant le swapping sur disque, cest le Memory Compression, ici certains blocks memoire suivant un algorithme, sont ‘compresses’ pour liberer de l’espace memoire qui es reclamee par une autre VM.

Il y a aussi le DRS, ca ne fait pas partie du Memory Overcommit mais il faut aussi savoir que la VM demandeuse de memoire peut etre migrer sur un autre serveur qui pourra lui fournir ce quelle demande si localement l’hyperviseur ne peut le lui fournir. DRS n’est pas gratuit certe mais ca vaut son pesant d’Or!

Toutes ces techniques on leur pendant dans le monde du storage; snapshot, deduplication, compression, tiering… et pourtant personne ne dirait a EMC, Pillar ou NetApp que ces techniques sont dangereuses pour votre entreprise! La memoire c’est de l’espace de stockage, certe volatile mais les memes principes peuvent s’y appliquer…

Comme le dit Jame O’Neill “…If a consultant signs off a design which depends on a system being able to magically create more memory capacity in an emergency, then their firm runs the risk of being sued if disaster strikes and the magic fails.”
Mon amis James, cette ‘magie’ se produit tout les jours sur vos storage chez Microsoft, pourquoi cela ne pourrait pas etre le cas sur les serveurs et dans Hyper-V??

En lisant l’article, j’ai trouve des commenatires de Jame O’Neill qui sont tres faux, qui demontrent qu’il ne connait pas le fonctionnement du Memory Overcommit de VMware et pire qu’il elude dans annees d’experience d’Administrateurs Wintel tel que vous et moi qui vous diront qu’au moins une fois par mois j’utilise le Live Migration pour pouvoir patcher mes serveur. Qu’on se demande pourquoi Windows 7 a besoin de 2GB minimum. Pourquoi il faut minimum 32GB d’espace disque pour installer Win2k8. Pourquoi meme si j’ai plein de memoire physique Windows continue a swapper, etc…

Voici les fameux commentaires:
-comparer le vMotion/Live Migration a un air-bag de voiture. On en a besoin que de temps en temps et encore…
-comparer le Memory Overcommit a de la magie par laquelle VMware ‘cree’ plus de memoire qu’il y en a physiquement.
-dire que le Memory Overcommit = swapper sur le disk sans plus.
-critiquer le VDI en disant que c’est mieux d’utiliser Citrix/Terminal Serveur, alors qu’on sait que le VDI est complemenatire au classique Citrix/TS.

Bref me voila, a nouveau, avec une tres longue tartine Je suis sans doute trop passionne par le sujet LOL

Pour moi l’overcommitment chez VmWAre n’est pas seulement l’allocation dynamique de mémoire entre VM mais aussi la possibilité d’allouer plus de mémoire que dispo…

(d’ou le terme d’OVERcommit

Si justement, sur Hyper-V R2 les VM W2k8 version Enterprise et Datacenter seulement utiliseront la fonction ‘hot add’ pour dynamiquement ajouter/retirer de la memoire a chaud. Cela permet donc de consolider plus de VM sur un serveur physique que cela ne l’etait possible auparavant.

Site a suivre pour plus d’info: http://blogs.technet.com/virtualization/archive/2010/03/18/dynamic-memory-coming-to-hyper-v.aspx

“Ne pas exploiter la mémoire comme le fait un scheduler pour le cpu revient à dédier un pcpu par vcpu sous prétexte que c’est plus sûr pour les performances…”

…