Hyper-V R2 CSV : The Shadow Warrior
Posted by NiTRo | Filed under Hyper-V, Kb
Pour être tout à fait honnête, depuis notre découverte d’Hyper-V R2, nous étions resté sur l’idée que le backup des VM sur CSV nécessitait un Hardware VSS prodiver et donc une baie de stockage “Hyper-V R2 compliant”. Mais en réalité, c’est encore pire…
L’excellent whitepaper d’Aidan Finn nous permet de comprendre à quel point la partie backup d’Hyper-v R2 est loin d’être idéale. Si vous n’avez pas d’Hardware VSS provider, vous “pourriez” utilisez le Software VSS provider d’Hyper-V R2 si vous avez envie de voir les performances de votre infrastructure s’effondrer :
Redirected Mode is active from the time that the backup job starts until the backup job completes
C’est à dire que pendant TOUTE la durée du backup, TOUT le trafic disque de TOUTES les VM est redirigé en SMB, par le réseau, vers le CSV coordinator ! Et, pire encore :
We recommend that virtual machines deployed on CSV should be backed up serially
En admettant que vous ayez un Hardware VSS provider, vous aurez quand même droit à un petit flood réseau :
Redirected Mode only takes place for the time it takes the SAN to create a snapshot of the LUN containing the CSV volume
Et nous avons gardé le meilleur pour la fin :
If the virtual machine’s Dynamic VHDs need to expand then the CSV Coordinator will have to start Redirected Mode for the entire CSV so it can perform the expansion of the VHD.
C’est à dire que si vos VM sont en thin provisioning, à chaque fois qu’un VHD doit grossir, TOUT le trafic disque de TOUTES les VM du CSV passe par le réseau en SMB pendant la durée de l’opération. La grande classe.
Et si le thin provisioning ne vous fait vraiment pas peur, à plus ou moins court terme le CSV sera fragmenté, et là c’est le drame :
Fragmentation leads to greater latency for read operations. You can defrag the physical storage volumes. In the case of a CSV, that means that the CSV will be in Redirected Mode for the length of the defrag operation
Alors, la prochaine fois qu’on vous parle d’Hyper-V, souriez 
Tags: Bullshit, FAIL, whitepapers
Loading ...
September 1st, 2011 at 8:01
N’oublie pas : Don’t get stuck in the IT past
:p
Pour le coup, un petit tag bullshit serait de mise non ?
September 1st, 2011 at 9:30
Haha, Go tag #bullshit, c’est juste grandiose, heureusement que j’ai jamais testé ce produit …
J’ai de plus en plus l’impression qu’ils ont que des $$$ pour le marketing …
vSphere a une grosse marge pour un bon moment encore.
September 1st, 2011 at 10:06
Pour le coup, le “Are you stuck in the past?” leur irait bien mieux qu’a VMware
September 1st, 2011 at 18:47
stuck in the bullshit ouai
September 1st, 2011 at 22:54
Il faut présenter ça avec une fausse moustache, des moonboots et un VAN…
Ça passe pour une innovation.
September 5th, 2011 at 14:32
Tout comme l’auteur de l’article cité, je travaille dans une SSII partenaire MS (Gold) mais également partenaire VMware (VAC)..Je ne fais que des projets de virtu depuis 2 ans et demi maintenant; j’ai donc l’occasion d’éprouver les différences VMware / Hyper-V… Je suis d’accord, VMware a encore pas mal d’avance.. Par j’ai été surpris par la dernière “affirmation” (l’expansion du VHD dynamique qui passe le volume CSV en “redirect mode”), je n’avais jamais lu ça dans aucune doc MS. J’ai donc testé rapidement par moi même pour me rendre compte. Effectivement quand on écris dans un VHD dynamique (pour la première fois bien sur) le réseau CSV est sollicité (mais trés peu, 0.1% de 1 gigabit dans mon cas), alors que si je refais le même test mais en forçant le “redirect mode” sur le volume CSV, mon réseau CSV passe à 90% d’occupation. Je crois qu’il faut donc pondérer le discours théorique alarmiste sur ce point précis. Le volume CSV passe donc bien en “redirect mode” pendant une expansion de VHD dynamique mais pendant un temps tellement court que l’impact n’est pas du tout le même que pendant un “redirect mode” prolongé (ce qui est par contre bien le cas lors d’une sauvegarde telle que vous la décrivez). De plus l’expansion d’un “bloc” d’un VHD dynamique n’est réalisée qu’une seule fois dans sa “vie”.
September 5th, 2011 at 14:39
Merci pour ton feedback Jb.
J’avoue que ce qui me gène plus c’est le risque de pic de latence lors d’un changement fc/ethernet.
De plus, je trouve que cela ne fait vraiment pas sérieux comme “side effect”…
September 5th, 2011 at 15:07
On est bien d’accord que tout ça n’est pas la panacée.. mais tout ça est lié aux limitations de NTFS. Quand MS se sera (peut être un jour
) équipé d’un système de gestion de fichier “clusterisable” comme l’est VMFS ces effets de bord n’existeront plus.
October 18th, 2011 at 8:02
Salut,
je travaille aussi dans le monde la virtu depuis quelques années, exclusivement VMware. Je m’intéresse depuis peu à Hyper-V (depuis le R2 SP1 pour des raisons assez simples de coûts… mais c’est un autre débat).
Je suis assez d’accord avec JB et c’est la confirmation que j’ai eu de quelqu’un de chez MS :
- en thin-provisioning, lors de l’extension du disque, le CSV ne passe pas en redirected mode. En revanche, il y a bien du trafic sur le réseau CSV. Donc oui du trafic passep our les metadatas, mais les blocs qui vont dans la VM dans le nouvel espace en cours d’extension, passent toujours via le SAN en direct.
- pour les snapshots VSS, concernant les VSS Hardware, même combat : du trafic passe sur le réseau CSV, mais pas de redirected mode des i/o blocs des VM.
Après certes, on peut rester sur le fait que le CSV n’est pas un vrai file system partagé come VMFS. Mais ca tempère fortement les craintes que j’ai eu lorsque j’ai lu l’article chez A Finn et ici après.
(J’ai pas posté de commentaire chez lui car mon dernier commentaire n’a pas été mis en ligne… sur les VMDq et SR-IOV)
FredK
October 18th, 2011 at 11:29
FredK, je veux bien admettre qu’il y ait une erreur dans le whitepaper mais encore faut il en avoir la preuve. Y a t’il une ressource MS genre technet qui pourrait abonder dans ton sens ?
Je vais essayer de dégager une peu de temps pour faire une maquette de ce scénario en attendant.
Merci pour ton retour.
October 18th, 2011 at 12:06
Helas je suis actuellement en attente d’une plate-forme de test… mais comme je disais, j’ai eu l’info d’un TAM MS, car j’ai été interpelé par ces affirmations.
Je sais que le TAM est sérieux, et sa réponse est un engagement mine de rien.
Cela dit, c’est vrai que je n’ai pas de preuve écrite. Par contre ça abonde ce qu’affirmait Jb qui lui a testé apparement et qu’il a remarqué un très faible débit sur le réseau.
Mais nous sommes d’accord, pas plus de choses écrites noires sur blanc d’un côté comme de l’autre
FredK
October 18th, 2011 at 15:27
Alors.. nouvelles infos !
Le VSS hardware implique bien un passage en mode redirected. Mais comme stipulé dans le doc d’A Finn, ceci est beaucoup plus bref, vu la rapidité d’un snap sur les baies…
Donc reste le thin provisionning. Là apparemment c’est le noeud coordinateur qui fait l’extension donc pas de redirected mode.
J’attends encore des docs ou des liens pour confirmer ceci. Pas évident comme infos à obtenir cela dit…
Donc clairement, le backup Hyper-V semble quand même moins abouti que le backup VMware, actuellement… car sur les premières versions de VCB, y’aurait aussi des choses à dire
Ca m’embête un peu, car j’ai l’impression que ça va pas être évident à implémenter le backup sur Hyper-V… alors que côté VMware y’a un paquet de solutions sympas et qui fonctionnent actuellement.
FredK
October 18th, 2011 at 15:45
Merci pour les infos !
Je suis d’accord pour VCB mais c’était il y a plusieurs années maintenant, la on parle d’une solution actuelle…
October 20th, 2011 at 13:29
Bon j’ai eu confirmation, mais pas de docs dispo
VSS Hardware : redirected mode, mais bref, compte tenu du mécanisme des snapshots de baies.
Extension VHD : pas de redirected mode, c’est le noeud coordinateur qui se charge de l’extension au niveau “NTFS”.
FredK
October 20th, 2011 at 14:21
Merci FredK, pour l’Extension VHD j’imagine que tu n’as pas pu avoir de détail au sujet de la latence induite par la communication avec le node coordinator avant de pouvoir ecrire les blocks ?
October 21st, 2011 at 12:33
Non désolé… j’ai même pas de documents qui précise cela. Juste un retour d’un TAM et d’une autre personne chez MS qui ont eu aussi confirmation des ingé. support.
Plus l’expérience de Jb
Bientôt peut-être une plate-forme pour vérifier aussi ça de visu ! Je suis un peu comme St Thomas
Cela dit la remarque de Jb était assez pertinente, et d’ailleurs je m’étais déjà fait la même pour VMware à une certaine époque et les disques en thin-provisioning, l’extension d’un VHD (ou VMDK) est mine de rien une phase assez transitoire … donc hormis contexte très particulier (où l’on crée de nouvelles VMs chaque second, en thin et qu’elles s’étendent rapidement et de manière conjointe.. une grosse infra cloud chez un FAI peut-être ? ), finalement l’impact sera assez limité dans le temps. A un moment toutes les VMs seront au max de la taille du disque ou le stockage (non infini) aura explosé
Donc pour moi ça reste moins impactant que le coup des sauvegardes qui elles ont lieu quotidiennement voire plus souvent ! En VSS hardware on limite un peu la casse, même si sur un grand environnement faut en tenir compte, mais en VSS software n’en parlons pas !
Mais clairement, techniquement VMware est devant, mais la raison veut que les coûts soient également de mise dans les infras… et là faut voir si Hyper-V ne peut pas “satisfaire” certaines PME/PMI ou des entités de grands groupes… à voir Après tout elles partent sur du SAN iSCSI donc à part le surplus de l’”encapsulation” SMB le redirected mode passe aussi par du réseau ethernet…comme l’iSCSI, non ? Faut juste être conscient des contraintes, et savoir si elles sont compatibles avec le besoin en qualité de service associé (toujours en prenant en compte le coût de tout ça… car techniquement, je sais pour qui mon coeur balance
)
FredK
October 21st, 2011 at 12:39
Et puis perso, moi y’a d’autres choses qui m’interpellent plus que les disques en thin chez Hyper-V…. les snapshots !
Pour les supprimer faut faire un power off de la machine ! C’est dingue… et puis le reboot suivant peut prendre un certain temps compte tenu du nettoyage du disque et de l’intégration des deltas AVHD dans le VHD… Je comprends pourquoi MS ne recommande pas les snapshots en production, sauf que les snapshots sont quand un élément très pratique en virtu. notamment si l’on adresse des environnement type dev ou test…où l’on aime bien “casser” des choses involontairement mais de manière volontaire
Donc si le dev. se plante, veut revenir à son snapshot précédent et doit attendre 2 heures avant de récupérer sa machine, on est pas près de voir les versions suivantes du soft
Je parle pas du live migration qui peut engendrer des BSOD et d’autres petits points qui ont attiré mon attention…
October 21st, 2011 at 13:33
Pour l’iSCSI je suis pas tout à fait d’accord car dans le cas d’Hyper-V le problème me semble être une potentielle contention sur le node coordinator là ou VMware utilise les réservations SCSI pour que chaque node fasse sa tambouille.
Pour les snapshot, le pire c’est que CITRIX utilise le vhd et les commit en live depuis XenServer 5.6 il me semble ?
October 21st, 2011 at 15:56
Pour l’iSCSI, ce que je voulais dire c’est que on est sur un support ethernet, en iSCSI ou SMB, et donc les ordres passent par des liens de ce type, avec des latences similaires au final. Après je suis d’accord avec toi sur le fait que le coordinateur voit les ordres concentrés en son point, donc à voir comment il gère ça s’il faut faire un nombre important de snapshot sur un nombre important de CSV car le redirected mode durera un certain temps au final. Je parle du VSS hardware, car le VSS software ne me paraît même pas envisageable ! Peut-être avec un lien 10G pour le réseau CSV, pour assurer un bon débit, mais effectivement, ça mérite qu’on se pose la question.
Par contre, désolé mais je connais pas du tout Citrix
.. déjà je découvre Hyper-V depuis 1 mois et quelques… chaque chose en son temps 
October 22nd, 2011 at 20:57
Ils ferait mieux de nous faire un client NFS…
Bon et ben je me suis trompé, même avec xenserver 6 il faut toujours un poweroff pour consolider les vm. La classe.
October 24th, 2011 at 16:15
Clair que le NFS manque cruellement.. cela dit s’il n’arrivent pas à faire un NFS performant, au final on l’utiliserait pas… donc qu’ils améliorent surtout la partie bloc déjà dispo !