La gratuité d’Hyper-V est un (très) mauvais argument
Posted by NiTRo | Filed under Hyper-V, VMware
Anton Zhbankov à posté sur vadmin.ru un comparatif très complet sur les couts d’architecture (hors stockage) vSphere/Hyper-V. Aussi brulant et pertinent que ce sujet puisse être, il est très (trop ?) largement faussé par le rouleau compresseur marketing Microsoft qui met en avant la gratuité quasi totale de sa solution. Bien que ce soit le seul argument à peu près valable face à vSphere (on les voient mal parler des performances ou des fonctionnalités…), le comparatif d’Anton nous prouve le contraire :
Couts en $ / VM (128Go/ host)
Le secret de ces résultats est la gestion de la mémoire, largement critiqué par Microsoft. Anton a donc fait ses calculs avec différents ratio de sur-allocation (1.2, 1.3 et 1.4), ce qui permet d’avoir plusieurs points de comparaison pour différents corps de métier. Le résultat est évidement proportionnel : la différence de prix est réduite par le nombre croissant de VM jusqu’à devenir en défaveur d’Hyper-V sur des serveurs à 64Go de RAM et plus !
Loading ...
December 31st, 2009 at 9:56
Hum,
pas sur que le graphique soit très parlant (ni la page en russe/chèque, pas très compréhensible), d’autant que l’argument de mensonge marketing ne serait valable -après validation par un labo indépendant bien sur- qu’à partir du moment ou l’on aurait 1 serveur à 64Go.
Quid si j’ai deux serveurs à 32 Go RAM?
December 31st, 2009 at 16:26
Moi ça me parle en tout cas, et pas besoin de labo pour faire des multiplications
Ce n’est pas le nombre de host qui est au centre de cette étude mais le nombre de VM : pour un nombre de VM identique, ça me coute moins cher sur vSphere car j’en met plus sur chaque host donc je gagne en licences et en matériel.
January 4th, 2010 at 23:33
Comme je le disais ds un de mes posts sur mon blog, le memory overcommit est aussi impotant que le partage du CPU, des cartes reseaux et du stockage…
La virtualization c’est une meilleur utilisation de toutes les resources d’une machine, memoire incluse!
January 4th, 2010 at 23:48
Amen !
March 19th, 2010 at 12:18
Sauf que j’ai du mal à voir comment on peut avoir des hauts niveau de perf avec de la suralllocation mémoire…Il faut être un peu cohérent également…
Et en parlant Performances, voici une étude INDEPENDANTE (voir les résultats sur l’overcommit justement) :
http://virtualizationreview.com/Articles/2009/03/02/Lab-Experiment-Hypervisors.aspx?Page=1
March 19th, 2010 at 12:27
On parle d’exploiter la RAM non utilisée, le dédoublonage de pages ou les zones mémoires “non libérées” par les guest OS sans impact (significatif) sur les performances. Il est évident que le memory overcommit mal (ou trop) utilisé peu s’avérer néfaste pour les performances.
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…
Mais tout cela, MS l’a compris puisqu’ils annoncent fièrement cette fonction pour Hyper-V : http://blogs.technet.com/virtualization/archive/2010/03/18/dynamic-memory-coming-to-hyper-v.aspx
March 19th, 2010 at 14:08
>Sauf que j’ai du mal à voir comment on peut avoir des >hauts niveau de perf avec de la suralllocation mémoire…>Il faut être un peu cohérent également…
Comme le dit bien NiTRo VMware a plusieurs methodes pour faire du ‘memory overcommit’, et il vient de rajouter une couche avec de la compression en temps reel. Et pour info la derniere methode de la liste, celle a eviter par tout les moyens, le paging sur HDD! Quoique si tu utilises des SSD tu minimises grandement la perte de perf mais bon ca c’est un autre debat
Faisons des analogies, MS a invente le ‘memory overcommit’ avec son fameux ‘pagefile.sys’, tu as 512MB de pMEM sur ton serveur, tu rajoutes 2GB de page file sur le disque et hop tu as 2.5GB de memoire, a part qu’ici c’est direct sur le HDD, aie les perfs! Et oui que ce soit VMware ou MS, swapper sur le disque est tres tres lent!
Autre analogie, tu as un seul endroit pour stocker tes documents, tu evites d’avoir les meme documents dispersee car ca prend notament de la place sur le disque, pareil pour le TPS de VMware qui partage un bloc memoire avec plusieurs machines virtuelles qui utilisent la meme info. Tu fais de la gestion optimalisee de tes documents, TPS fait pareil avec la memoire de ton serveur.
Et encore une analogie pour la route, le tout nouveau memory compression, compare cela a un document que tu zippes pour prendre moins de place sur ton disque, pareil ici avec le memory compression mais en memoire.
Oui toutes ces techniques de gestion de la memoire ont un cout sur les perfs, surtout ds le cas extreme du paging sur HDD, a eviter point barre. Mais les avantages sont tellement enormes lorsque le vAdmin gere bien son vEnvironement…
Bref et voila que MS propose aussi du ‘memory overcommit’ avec le SP1 de W2k8 r2, mais la ou le bas blesse, c’est que pour le moment il n’y a aucune methode de gestion de la memoire, on en revient a du bete swapping sur disque ds le cas ou la machine virtuelle utilise la partie de memoire qui est ‘overcommited’. Mais on y arrivera un jour…
March 19th, 2010 at 18:36
Merci pour vos éclairages
March 19th, 2010 at 18:41
Par contre Nitro, je saisis pas bien :
“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…”
…
March 19th, 2010 at 18:43
J’avoue, 2 contre 1 c’est un peu facile mais il faut dire que la technique MS qui consiste à nier l’intérêt d’une fonctionnalité jusqu’à ce qu’elle soit disponible au catalogue MS est un peu énervante.
Il y a eu vmotion et maintenant l’overcommit et bientôt le svmotion ou le failover network/san ?
March 19th, 2010 at 18:48
le rôle de l’hyperviseur est de partager les ressources, je faisais l’analogie entre le partage des ressources cpu (faites par le scheduler) et le partage de la ram (faites par les mécanismes d’overcommit). Sans forcement entrer dans les situation de contention tout comme tu peux avoir plus de vcpu que de pcpu sans pour autant saturer le serveur.
March 20th, 2010 at 12:12
Attention l’allocation dynamique annnoncée avec le SP1 n’a rien a voir avec l’overcommit !!! Avec le SP1 il ne sera toujours pas possible d’allouer plus de mémoire que disponible physiquement!
March 20th, 2010 at 15:47
Bien sûr que si, il s’agit juste d’un jeu de mot entre la mémoire allouée et la mémoire réellement consommée.
March 20th, 2010 at 16:38
>n’a rien a voir avec l’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
March 22nd, 2010 at 16:34
Ce post va mettre tout le monde d’accord : http://www.virtualization.info/2010/03/microsoft-details-upcoming-hyper-v.html
March 22nd, 2010 at 16:49
J’avais donc raison…Rien a voir avec l’overcommit de WmWARE…
March 22nd, 2010 at 16:57
pourtant c’est exactement ce que je comprend quand je lis ca : Eventually all the memory will be committed and since you can’t hot unplug memory we have a component to take memory out of use in one VM so that it can be given to another – and Hyper-V will take memory from the VMs which need it least.
March 22nd, 2010 at 17:57
oui mais pas d’overcommitment :
By de-allocating memory in VMs Hyper-V ensures the total allocated remains below the total present..
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
March 22nd, 2010 at 18:07
Autant pour moi, en effet le Dynamic Memory d’Hyper-V R2 ne fait pas du ‘Memory Overcommit’ a la VMware.
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
March 22nd, 2010 at 20:33
En terme de mémoire allouée, “take memory out of use in one VM so that it can be given to another” ca veut dire overcommit
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
March 22nd, 2010 at 20:52
Rahhh Nitro quelle mauvaise fois tout de même
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…
March 22nd, 2010 at 20:55
Tu ne vas quand même pas me dire que je joues plus (+) sur les mots que le marketing MS !
March 22nd, 2010 at 21:46
Mouais…Tu reconnais que c’est une bone technqiue alors
….du FUD y’en a pas mal chez VMWARE aussi…
March 22nd, 2010 at 22:13
la technique de ballooning est bonne (à moi sens) si elle est bien utilisée. La seule chose que je trouve dommage c’est l’utilisation du hot-add qui limite (pour l’instant) l’usage à peu d’OS. Et pour le FUD, je penses qu’on peut dire que tous les éditeurs en usent et surtout en abusent…
March 23rd, 2010 at 10:57
Oops James O’Neill s’est fait taper sur les doigts dirait-on et son post sur le Dynamic Memory n’est plus dispo…
Meme Google ne l’a pas (plus) dans son cache! Que penser de tout ca?
)
March 23rd, 2010 at 11:46
Tu as un lien vers son blog stp ?
March 23rd, 2010 at 15:09
http://blogs.technet.com/jamesone/archive/2010/03/22/dynamic-memory-in-hyper-v.aspx