Le storage vMotion hier et aujourd’hui

Storage vMotion est une technologie apparue déjà dans le vCenter 2.5, qui permet, sur le même principe que le vMotion, de déplacer les fichiers d’une VM (disques virtuels, vmx, vswp, etc) d’un datastore à un autre.

Pour rappel, le vMotion, permet de changer une VM d’ESX. Si une VM A tourne sur un ESX X, le vMotion permet de le déplacer sur l’ESX Y avec un downtime minime. Dans ce cas de figure, ce qui est réellement déplacé, c’est la RAM de la VM. Finalement, qu’est ce qui défini une VM tournant sur un ESX, si ce n’est une instance et la RAM de la VM ?

Le storage vMotion quand à lui, ne change pas la VM d’ESX, mais il permet de déplacer l’ensemble de ses fichiers d’un datastore à un autre (indépendamment du type de stockage).

Bien que relativement récent, le svMotion a déjà beaucoup évolué, et vSphere 5 le fait encore évoluer, pour atteindre sa quatrième version aujourd’hui.

Petit historique :

  • en VI3.X, VMware introduit le svMotion (sans interface graphique), basé sur la technologie des snapshots. Lors d’un svMotion, un snapshot est pris de la VM, stocké également sur le datastore source. Les écritures étant dorénavant faites dans le disque delta, le disque de base peut être tranquillement copié sur le datastore de destination. Cette opération prenant du temps, le premier delta peut atteindre une taille importante. On fait donc un deuxième snapshot, qui nous libérera le premier delta de toute écriture. Le premier snapshot est consolidé avec le disque de base sur le datastore de destination, mais cette opération pouvant encore prendre un peu de temps, on recommence avec un troisième snapshot, et ainsi de suite.
    Cette méthode était déjà un grand progrès, mais s’avérait lente, un peu risquée pour la consistance de la VM (notamment en cas de panne soudaine ou de coupure réseau) et peu « propre » en cas d’annulation (beaucoup de snapshots résiduels).
  • en vSphere 4, VMware change le design du svMotion et utilise une nouvelle technologie, le Changed Block Tracking (CBT) ou également appelée Dirty Block Tracking (DBT). Avec cette méthode, les snapshots ne sont plus utilisés lors d’un svMotion. Les blocks du disque source sont copiés (bulk copy) et durant cette copie initiale, une liste des blocks que la VM a changé est maintenue par le VMkernel. Seuls les blocks déjà copiés, modifiés par la VM, doivent être recopiés, les blocks qui n’ont pas encore été copiés par la bulk copy n’ont pas besoin de figurer dans la liste du CBT. Sur le même principe que la première méthode, plusieurs itérations sont faite, jusqu’à stabilisation. C’est à dire que peu de blocks (seuil défini) sont modifiés durant le temps de la dernière itération. Ensuite, la machine est suspendue et basculée (atomic switch), ce qui n’était pas possible avec la méthode snapshot. Le temps de l’atomic switch est généralement moins d’une seconde (en pratique, perte d’un ping) durant cet intervalle, la VM est freezée.
  • Hot Block Avoidance. Cette méthode est une légère évolution de DBT (ou CBT). Elle permet d’éviter de copier à chaque itération des mêmes blocks. VMware s’est rendu compte que dans la pratique, bien souvent, les mêmes blocks sont réécrits régulièrement. Avec Hot Block Avoidance, à la fin de la bulk copy (première copie du disque) la liste des blocks modifiés est analysée, et si un block à été changé x fois (seuil défini) il est considéré comme Hot Block, et ne sera copié que lors de l’avant-dernière itération (pour éviter d’écrire ces blocks pour rien à chaque itération). Cette méthode n’a jamais été implémentée comme méthode par défaut. La raison est qu’elle consomme beaucoup de mémoire et n’apporte pas d’amélioration dans tous les cas, selon les workflows étudiés.

En vSphere 5, VMware a encore changé le design de svMotion, le CBT n’est plus du tout utilisé, le nouveau concept s’appel I/O Mirror. Le problème de CBT était que les itérations successives prennent du temps et que cela provoque un grand nombre d’opération de lecture/ecriture.

IO Mirror fonctionne complétement différemment. Le module Data Mover du VMkernel est toujours utilisé pour copier les blocks. Les étapes sont les suivantes :

  • bulk copy du disque. C’est la copie initiale, tous les blocks sont copiés de la source à la destination (possible d’utiliser VAAI, voir plus bas).
  • Pendant la bulk copy, les écritures arrivants sur le disque de la VM sont automatiquement classées en 3 catégories :
    1. dans une zone déjà copiée par le bulk copy : les écritures sont faites sur le disque source et mirrorées sur le disque de destination
    2. dans la zone en cours de copie : les écritures ne sont pas faites sur le disque mais conservées le temps que la bulk copy de la zone soit finie, puis effectuées sur le disque source et mirrorées sur le disque de destination.
    3. Dans une zone pas encore copiée : les écritures sont faites uniquement sur le disque source.
  • Les lectures sont toutes faites sur le disque source.

Storage vMotion IO Mirror

Avec cette méthode, plusieurs avantages :

  • vitesse améliorée car il n’y a plus ce système d’itérations successives, le temps du svMotion est désormais le temps de la bulk copy (presque).
  • support de VMs avec snapshots
  • encore moins de downtime lors de l’atomic switch (toutes les IO sont faites, pas besoin de freezer pour copier les derniers blocks).
  • compatible avec VAAI (voir l’article de Cédric Mégroz sur ce même blog ici)
  • beaucoup moins d’I/O sont effectuées

Le principal inconvénient que je vois pour l’instant, est celui que l’on retrouve avec toute réplication ou mirroring, c’est les éventuels latences. Dans ce nouveau svMotion, la VM, durant l’opération, aura les performances de la baie ou la ligne la plus lente, car les écritures devront être faites sur le disque source et le disque destination en mode synchrone (on attend l’acknowledgment du plus lent).

Voilà, n’hésitez pas à me faire part de vos questions ou commentaires.
Merci de votre lecture.
Stéphane

Sources :

A propos de 

http://ch.linkedin.com/in/sgrimbuhler

Stéphane GRIMBUHLER 

Virtualization & Storage Architect (VCP / VCAP-DCA)
VMware Instructor (VCI)
vExpert 2012 to 2014

twitter : @sgrimbuhler
sgrimbuhler@virtualgeek.ch

  1. Merci c’est intéressant !

Laisser un commentaire


NOTE - Vous pouvez utiliser les éléments et attributs HTML tags and attributes:
<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>