Déplacer un volume VPlex d’une baie à une autre

English sum-up :
A little VPlex tutorial : how to migrate a local volume from an array to another without disruption.

Après tous ces billets « de haut vol » depuis quelques semaines, on change de registre avec une manipulation plus terre à terre mais qui nécessite malgré tout un peu de méthode. L’objectif de ce petit tutoriel est de déplacer à chaud un volume d’une baie A à une baie B sur un cluster VPlex. Le cas d’usage typique est celui d’une migration d’une vieille baie vers une nouvelle ou éventuellement un changement de tiering/qos. En fait, techniquement l’opération consiste tout simplement à créer un miroir du volume à déplacer sur la baie cible, puis de retirer « la patte » de l’ancienne baie une fois la synchro terminée.

Mais, trêve de blabla, voici les étapes et les commandes associées :

1. Préparation du volume cible : VPlex travaille au niveau device pour ce type d’opération. On va donc provisionner d’abord le nouveau volume cible à travers le VPlex sur le même cluster local que celui de la baie source. On passe donc par les étape classique de claim, extent et enfin device. Une fois le LUN présenté au VPlex :

cd /clusters/cluster-1/storage-elements/storage-volumes
claim -n volume_cible VPD83T6:60000xxxxxxxxxx
cd /clusters/cluster-1/storage-elements/extents
create volume_cible
set extent_volume_cible_1::name extent_volume_cible
cd /clusters/cluster-1/devices
create device_volume_cible raid-0 extent_volume_cible

2. Une fois le volume cible disponible, on va tour simplement créer un miroir à partir du volume source, via la commande « attach-mirror » :

cd /clusters/cluster-1/devices
device attach-mirror device_volume_source device_volume_cible

Evidemment … faites bien attention à l’ordre des devices. Source en premier, destination en second. J’avoue ne pas avoir testé « dans l’autre sens », mais ce serait intéressant de voir le comportement du VPlex sachant qu’en général, la source est déja présentée à son ou ses serveurs et donc est lié à un virtual volume, dans une storage view etc. …

Une fois l’opération lancée, vous pouvez suivre la synchro via la commande « rebuild » :

rebuild status
[1] storage_volumes marked for rebuild

Global rebuilds:
  No active global rebuilds.

cluster-1 local rebuilds:
device                rebuild type  rebuilder director  rebuilt/total  percent finished  throughput  ETA
--------------------  ------------  ------------------  -------------  ----------------  ----------  --------
device_volume_source  full          s1_0c33_spa           1.86G/1.36T             0.13%      142M/s    2.79hr

Vous pouvez éventuellement accélérer le processus en augmentant la taille des blocs de transfert. Utilisez la commande « rebuild set-transfer-size ». En général, personnellement, je positionne le tfrsize à 2 Mo, qui semble être un bon compromis, d’après différents tests réalisés chez nous :

rebuild set-transfer-size device_volume_source 2M

3. Une fois la synchro terminée, il nous suffit de procéder au détachement de l’ancien volume, devenu inutile. La commande « device detach-mirror » est à l’oeuvre. Attention cependant, il va falloir d’abord récupérer l’ancien device qui a du prendre un nom différent de l’original. Pour y voir plus clair, on utilise la commande « drill-down » qui permet de visualiser toute la hiérarchie d’un device (ou d’un virtual volume) donné :

cd /clusters/cluster-1/devices
drill-down -r device_volume_source
local-device: device_volume_source (cluster-1)
   local-device-component: device_volume_cible
      extent: extent_volume_cible
         storage-volume: volume_cible (blocks: 0 - 364172543)
   local-device-component: device_volume_source2014Oct20_162427
      extent: extent_volume_source
         storage-volume: volume_source (blocks: 0 - 364172543)

Vous notez que désormais vous avez deux niveaux de device : le device « top level » qui reprend le nom actuel du device source que nous avons mirroré et en dessous le device cible et son « ancien collègue » le device source dont le nom a été modifié pour ne pas générer de doublons. Pour notre exemple, nous devons donc « détacher » le volume source initial, en l’occurence « device_volume_source2014Oct20_162427 ». On procède donc à la commande suivante :

device detach-mirror -m device_volume_source2014Oct20_162427 volume_source
Detached mirror device_volume_source2014Oct20_162427.

4. C’est pratiquement terminé. Dors et déjà, vous travaillez sur le nouveau volume « device_volume_cible ». Il vous reste malgré tout un peu de ménage à faire, car vous avez supprimé une patte du mirroir, mais la hiérarchie est toujours là. On va utilise la commande « device collapse » pour réduire la hiérarchie :

cd /clusters/cluster-1/devices
drill-down -r device_volume_source

local-device: device_volume_source (cluster-1)
   local-device-component: device_volume_cible
      extent: extent_volume_cible
         storage-volume: volume_cible (blocks: 0 - 364172543)
device collapse device_volume_source
drill-down -r device_volume_source

local-device: device_volume_source (cluster-1)
   extent: extent_volume_cible
      storage-volume: volume_cible (blocks: 0 - 364172543)

5. Il vous reste sur les bras l’ancien device détaché qu’il faudra décomissionner via des commandes « destroy » en cascade, puis le supprimer coté baie.

Bien entendu, et c’est là, la magie de VPlex, tout cela se fait online sans interruption de service ! J’espère que ce tutoriel vous sera utile. A votre disposition pour toute question et/ou précision au sujet de ces opération.