Zero-G Storage vMotion
Posted by NiTRo | Filed under Kb, Performance, Test, Tips & Tricks
Notre expérience de Storage vMotion remonte à l’arrivée d’ESX 3.0.1 (aka VI3) où DMotion permettait de migrer à chaud de VMFS 2 à VMFS 3 :
Follow the Migrate Virtual Machine Wizard to select the ESX 3.0.1 host and VMFS3 datastore destination. The Wizard validates the destination and moves the configuration files of the virtual machine and virtual disks to the new VMFS3 datastore.
Depuis, nous avons étudié, testé, troubleshooté, et utilisé en production (de manière parfois intensive) cette fonctionnalité (qui a beaucoup évolué depuis 2007) devenue presque banale depuis SDRS.
C’est au moment où nous croyons tout savoir du mécanisme que nous prenons une grande claque d’humilité lors d’une migration de plusieurs centaines de VM et que nous nous apercevons pour la première fois qu’un svmotion d’un vmdk thin (ou Lazy Zeroed) génère 2 fois plus d’écritures que de lectures :
Nous n’avions jamais fait le rapprochement entre un svmotion et un sujet qui a longtemps fait polémique :
Because zeroing takes place at run-time for a thin disk, there can be some performance impact for write-intensive applications while writing data for the first time.
Et le pire c’est qu’il nous a fallu un temps infini à l’échelle de Google pour tomber sur un thread reddit où un VCDX explique tout d’une seule phrase :
It has to zero the block before writing the actual data.
Voila pourquoi sans VAAI (ou au moins la primitive WRITE_SAME) vos svmotion (thin ou lazy zeroed) prendrons 2 fois plus de temps car 2 fois plus de données transiterons vers le stockage (entre 2 VMFS avec le même blocksize).
A titre de démonstration, voici un visualEsxtop de 2 svmotion consécutifs de la même VM entre 2 datastore, avec et sans le setting DataMover.HardwareAcceleratedInit :
Ce n’est pas une défaillance de votre téléviseur, avec le zeroing offloadé à la baie c’est presque 2 fois plus rapide (ou 2 fois moins long si vous préférez…).
Ce comportement n’a évidement aucun rapport avec la “non-récupération” des zéros lors d’un svmotion… Bien qu’il semble etre possible de le forcer d’une manière non supportée !
Tags: SVMotion, thin provisioning, VAAI, zeroing
Loading ...
June 16th, 2014 at 16:34
Très bon article
December 15th, 2014 at 10:33
[...] faire du thin on thick). Tant que tout va bien, vous n’avez à craindre que l’impact du thin des vmdk. Mais quand l’espace vient à manquer dans la baie, on espère pour vous que ça se passe [...]
February 10th, 2015 at 20:14
Question bête, le graphe de Perfs vSphere est sur le datastore source ou destination.
De ce que je comprends c’est à la destination ou le bloc est mis à 0 puis écrit, mais pourquoi 2 fois plus de données passent??
Sorry un peu perdu
February 11th, 2015 at 9:13
@fouad lecture a la source, écriture à la destination. Le volume de données transférées ne change pas mais le volume de données écrites est supérieur à cause du zeroing.
February 11th, 2015 at 15:19
@NiTRo merci pour la clarification et de prendre le temps d’y répondre.
C’était ce paragraphe qui m’a laissé sur ce questionnement.
“Voila pourquoi sans VAAI (ou au moins la primitive WRITE_SAME) vos svmotion (thin ou lazy zeroed) prendrons 2 fois plus de temps car 2 fois plus de données transiterons vers le stockage (entre 2 VMFS avec le même blocksize).
”
Bon boulot Messieurs et merci encore
February 11th, 2015 at 15:37
Merci