Etendre un volume VPlex distribué sans arrêt de production

VPlex 5.1sp3 ne permet pas facilement de procéder à des extensions de LUNs distribuées sur un cluster en mode metro. La solution est relativement laborieuse et nécessite des précautions, en particulier sur des LUNs en production, évidemment ;) . D’autre part, elle nécessite, temporairement du moins, de casser le mirroir entre les deux clusters, pour étendre un coté, puis reconstruire de l’autre coté. En fait, tout se passe a peu près comme pour des extensions de LUNs mirrorées via MirrorView sur les baies CX/VNX.

Mais ceci ne va pas nous arrêter, loin s’en faut… alors, AU BOULOT :) !

Dans les grandes lignes voici les étapes à franchir:

1. On stoppe les I/O sur un des clusters VPlex
2. On casse le mirroir VPlex et on supprime la LUN désynchronisée du cluster ou les I/O sont stoppées
3. On transforme la LUNs distribuée en LUN “locale” sur le cluster disposant encore de l’accès à la baie qui concerve la charge des I/O
4. On étend ce LUN par ajout d’extent/devices
5. On étend la LUNs déconnectée (ou on la reconstruit coté baie de stockage)
6. On la rattache au cluster d’ou on l’avait détaché initialement (celui ou les I/O ont été stoppées)
7. On reconstruit le mirroir avec la LUN encore en prod, recréant de fait un device distribué
8. On rétablit les I/O sur le cluster hors de prod

Une précision importante, cette procédure est “asymétrique”, c’est à dire qu’à l’issue de l’opération, votre paramétrage de volumétrie sera différent entre les deux clusters. Cela peut être un problème si vous souhaitez absolument une conf symétrique entre vos deux pattes. Dans ces conditions, il faut faire la manipulation “deux fois”, j’en parle brièvement en fin d’article.

En résumé, à l’issue de l’opération, vous aurez une LUN étendu composée de deux storage volumes d’un coté et une grosse LUN composé d’un seul storage volume de l’autre.

La logique naturelle est de tout réaliser via ligne de commandes vplexcli. En effet, même si certaines opérations sont réalisable assez simplement via l’interface web, les lignes de commandes ne “trompent” pas et permettent de suivre précisément toutes les étapes de la manoeuvre.

Avant toute chose, savoir d’où on part. L’outil drill-down vient à notre secours pour nous décrire la structure exacte du device distribué à étendre :

VPlexcli:/> drill-down --virtual-volume vv_bas_test
virtual-volume: vv_bas_test (cluster-1)
virtual-volume: vv_bas_test (cluster-2)
distributed-device: dd_bas_test
distributed-device-component: device_vnx1_test_legtu (cluster-1)
extent: extent_vnx1_test_legtu
storage-volume: vnx1_test_legtu (blocks: 0 - 393215999)
distributed-device-component: device_vnx1_test_leghn (cluster-2)
extent: extent_vnx1_test_leghn
storage-volume: vnx1_test_leghn (blocks: 0 - 393215999)

Dans l’exemple ci-dessus, on constate donc que le volume virtuel “vv_bas_test” est constitué de d’un distributed device “dd_bas_test”, lui même regroupant un mirroir de deux devices “device_vnx1_test_legtu” et “device_vnx1_test_leghn”.

Ces infos vont nous permettre de faire les choses dans l’ordre, sans risque pour la production. Première étape, on stoppe les I/O sur un des clusters constituant le vplex-metro. Ici, on choisit le cluster-2, mais cela pourrait tout aussi bien s’appliquer au cluster-1. Dans le cas de clusters phyisques utilisant la LUN, il faut s’assurer que la ou les machine(s) vers le cluster-1 restant soi(en)t celle(s) qui assure(nt) la production. En environnement ESXi avec le cross-connect activé, pas de souci sachant que les chemins FC vers les deux clusters peuvent être sollicités sans coupure visible coté VM. On stoppe les I/O en enlevant tout simplement la LUN du storage-view du cluster-2 :

VPlexcli:/> export storage-view removevirtualvolume --view svhn_vmware_bas --virtual-volumes vv_bas_test --force
WARNING: The view 'svhn_vmware_bas' is a live view and is exporting storage through the following initiator ports: 'radiume2650_tu18_yang', 'bacassab2_ying', 'radiume2650_tu18_ying',
'bacassab2_yang', 'bacassab3_yang', 'bacassab_yang', 'bacassab3_ying', 'bacassab_ying'. Performing this operation may affect hosts' view of storage. Proceeding anyways.
Removed the following volumes: [vv_bas_test].

Ici, le virtual volume “vv_bas_test” s’appuyant sur le device distribué à étendre a été supprimé du storage-view “svhn_vmware_bas” de notre cluster-2. Ensuite on va supprimer (à voir si vous avez ce genre de setup avec un cluster witness) le virtual volume de son consistency group, afin d’éviter qu’en cas de bascule pendant notre opération, la LUN ne se retrouve placée sur le mauvais membre du vplex-metro. On va aussi vérifier et modifier au besoin la règle par défaut du LUN en cas de bascule. Ici on a choisi de déconnecter le cluster-2, donc on va poser la règles cluster-1-detaches pour plus de sureté.

VPlexcli:/> cd /clusters/cluster-1
VPlexcli:/clusters/cluster-1> consistency-group remove-virtual-volumes vv_bas_test cg_dd_bas
VPlexcli:/clusters/cluster-1> cd /distributed-storage/distributed-devices/dd_bas_test/
VPlexcli:/distributed-storage/distributed-devices/dd_bas_test> ll
Attributes:

Name Value
---------------------- ----------------------
application-consistent false
auto-resume true
block-count 2621440
block-size 4K
capacity 10G
clusters-involved [cluster-1, cluster-2]
geometry raid-1
health-indications []
health-state ok
locality distributed
operational-status ok
rebuild-allowed true
rebuild-eta -
rebuild-progress -
rebuild-status done
rebuild-type full
rule-set-name cluster-2-detaches
service-status running
stripe-depth -
system-id dd_bas_test
transfer-size 128K
virtual-volume vv_bas_test

VPlexcli:/distributed-storage/distributed-devices/dd_bas_test> set rule-set-name cluster-1-detaches

Ensuite, nous allons casser le mirroir répliqué via le distributed device, du coté cluster où les I/O sont stoppées :

VPlexcli:/> device detach-mirror --device dd_bas_test --mirror device_vnx1_test_leghn --discard --force
Detached mirror device_vnx1_test_leghn.
Mirror device_vnx1_test_leghn is below /clusters/cluster-2/devices.

Le mirroir est désormais fracturé et la “patte” du cluster-2 est donc désormais manipulable à souhait. Attention, pendant cette phase, vous êtes en mode dégradé vis à vis de votre plan de secours éventuel, vos données ne sont plus à jour que sur un site, celui où se trouve le cluster-1.

On va supprimer toutes les déclarations de la LUN récupérée sur le cluster-2 :

VPlexcli:/clusters/cluster-2/devices> local-device destroy device_vnx1_test_leghn
WARNING: The following items will be destroyed:
Context
--------------------------------------------------
/clusters/cluster-2/devices/device_vnx1_test_leghn
Do you wish to proceed? (Yes/No) yes
VPlexcli:/clusters/cluster-2/devices> extent destroy -f extent_vnx1_test_leghn
Destroyed 1 out of 1 targeted extents.
VPlexcli:/clusters/cluster-2/devices> cd /clusters/cluster-2/storage-elements/storage-volumes/
VPlexcli:/clusters/cluster-2/storage-elements/storage-volumes> unclaim vnx1_test_leghn

On convertit ensuite le device distribué, désormais sur une seule patte, en device local au cluster-1 :

VPlexcli:/> device collapse dd_bas_test
VPlexcli:/> drill-down --device dd_bas_test
local-device: dd_bas_test (cluster-1)
extent: extent_vnx1_test_legtu
storage-volume: vnx1_test_legtu (blocks: 0 - 2621439)
VPlexcli:/> cd /clusters/cluster-1/devices/
VPlexcli:/clusters/cluster-1/devices> ll dd_bas_test
/clusters/cluster-1/devices/dd_bas_test:
Attributes:
Name Value
---------------------- ------------------
application-consistent false
auto-resume true
block-count 2621440
block-offset 0
block-size 4K
capacity 10G
geometry raid-0
health-indications []
health-state ok
locality local
operational-status ok
rebuild-allowed -
rebuild-eta -
rebuild-progress -
rebuild-status -
rebuild-type -
rule-set-name cluster-1-detaches
service-status running
stripe-depth 4K
system-id dd_bas_test
transfer-size -
virtual-volume vv_bas_test
visibility global
Contexts:
Name Description
---------- -------------------------------------------------------------------
components The list of components that support this device or system virtual
volume.
VPlexcli:/clusters/cluster-1/devices> cd /clusters/cluster-1/devices/dd_bas_test
VPlexcli:/clusters/cluster-1/devices/dd_bas_test> set visibility local
VPlexcli:/clusters/cluster-1/devices/dd_bas_test> set name device_vnx1_test_legtu
VPlexcli:/clusters/cluster-1/devices/dd_bas_test> set application-consistent false

Vous voyez qu’une fois le “collapse” réalisé, le device est désormais un device local au cluster-1. Ensuite, on a également positionné la visibilité de ce device à ‘local’ pour éviter toute publication coté cluster-2 et ensuite, on supprime le mode application consistent éventuellement (si vous avez initialement importé un LUN existant AVANT l’installation de votre VPlex). Ce paramètre est nécessaire lors de l’import de la LUN, mais il peut être supprimé ensuite, cela vous évitera que le VPlex vous interdise son extension dans la phase suivante ;)

Phase suivante, nous allons étendre le LUN restant en production. Pour ce faire, il faut d’abord importer une LUN préalablement préparée pour ensuite étendre le volume via un “expand”. Vous noterez que toute la première partie du scripting est relativement simple et connue, il s’agit tout simplement de déclarer une nouvelle LUN dans le VPlex, qui sera ensuite concaténée à la LUN en prod pour constituer votre volume final étendu :

VPlexcli:/clusters/cluster-1/storage-elements/storage-volumes> claim -n vnx1_test_legtu_ext1 VPD83T3:60060160xxxxxxxxxxxxxxxxxxxxxxx
VPlexcli:/clusters/cluster-1/storage-elements/storage-volumes> cd ../extents/
VPlexcli:/clusters/cluster-1/storage-elements/extents> create vnx1_test_legtu_ext1
VPlexcli:/clusters/cluster-1/storage-elements/extents> cd extent_vnx1_test_legtu_ext1_1/
VPlexcli:/clusters/cluster-1/storage-elements/extents/extent_vnx1_test_legtu_ext1_1> set name extent_vnx1_test_legtu_ext1
VPlexcli:/clusters/cluster-1/storage-elements/extents/extent_vnx1_test_legtu_ext1> cd ../../../devices
VPlexcli:/clusters/cluster-1/devices> create device_vnx1_test_legtu_ext1 raid-0 extent_vnx1_test_legtu_ext1

On concatène la LUN préparée :

VPlexcli:/clusters/cluster-1/devices> virtual-volume expand -f --virtual-volume vv_bas_test --extent device_vnx1_test_legtu_ext1
VPlexcli:/clusters/cluster-1/devices> drill-down --virtual-volume vv_bas_test
virtual-volume: vv_bas_test (cluster-1)
local-device: device_vnx1_test_legtu (cluster-1)
local-device-component: device_vnx1_test_legtu2013Feb04_133538
extent: extent_vnx1_test_legtu
storage-volume: vnx1_test_legtu (blocks: 0 - 2621439)
local-device-component: device_vnx1_test_legtu_ext1
extent: extent_vnx1_test_legtu_ext1
storage-volume: vnx1_test_legtu_ext1 (blocks: 0 - 2621439)

Vous voyez que désormais, la LUN en prod repose sur un device local lui-même encapsulant deux devices locaux, la LUN historique et la seconde LUN d’extension.

A ce stade, la LUN est étendue, donc sa nouvelle volumétrie est directement utilisable sur le host ou la VM, moyennant un rescan des disques). Avant de terminer, il faut donc créer une LUN qui va être servie à nouveau par le cluster-2 actuellement non relié. Cette LUN devra faire au moins la taille cumulée de la LUN historique étendu de la seconde LUN. Typiquement, si vous aviez initialement une LUN distribué de 1 To, que vous lui avez adjoint une LUN complémentaire de 500 Go, la LUN a créer du coté cluster-2 devra faire 1,5 To au moins.

Lorsque cette LUN est créée et présentée au cluster-2 du VPlex depuis vos baies de stockage, faites un petit re-discover de la baie concernée (array re-discover EMC-CKxxxxxx par exemple, pour une baie EMC, où EMC-CKxxxx est le serial de votre baie, connu du VPlex).

Enfin, il s’agit de déclarer la nouvelle LUN sur le cluster-2 :

VPlexcli:/clusters/cluster-1/devices> cd /clusters/cluster-2/storage-elements/storage-volumes/
VPlexcli:/clusters/cluster-2/storage-elements/storage-volumes> claim -n vnx1_test_leghn_20g VPD83T3:60060xxxxxxxxxxxxxxxxxxxxxx
VPlexcli:/clusters/cluster-2/storage-elements/storage-volumes> cd ../extents/
VPlexcli:/clusters/cluster-2/storage-elements/extents> create vnx1_test_leghn_20g
VPlexcli:/clusters/cluster-2/storage-elements/extents> cd extent_vnx1_test_leghn_20g_1/
VPlexcli:/clusters/cluster-2/storage-elements/extents/extent_vnx1_test_leghn_20g_1> set name extent_vnx1_test_leghn_20g
VPlexcli:/clusters/cluster-2/storage-elements/extents/extent_vnx1_test_leghn_20g> cd ../../../devices/
VPlexcli:/clusters/cluster-2/devices> create device_vnx1_test_leghn_20g raid-0 extent_vnx1_test_leghn_20g

… puis de reconstruire le mirroir et ce faisant, de demander au VPlex de réinstancier un nouveau distributed device :

VPlexcli:/clusters/cluster-2/devices> device attach-mirror --device device_vnx1_test_legtu --mirror device_vnx1_test_leghn_20g
Distributed device 'device_vnx1_test_legtu' is using rule-set 'cluster-1-detaches'.
VPlexcli:/clusters/cluster-2/devices> cd /distributed-storage/distributed-devices/
VPlexcli:/distributed-storage/distributed-devices> ll
Name Status Operational Health State Auto Rule Set Name Transfer
------------------------- ------- Status ------------- Resume ------------------ Size
------------------------- ------- ----------- ------------- ------ ------------------ --------
(...)
device_vnx1_test_legtu running degraded major-failure true cluster-1-detaches 128K
(...)
VPlexcli:/distributed-storage/distributed-devices> cd device_vnx1_test_legtu/
VPlexcli:/distributed-storage/distributed-devices/device_vnx1_test_legtu> set name dd_test
VPlexcli:/distributed-storage/distributed-devices/dd_test> set transfer-size 2M
VPlexcli:/distributed-storage/distributed-devices/dd_test> cd
VPlexcli:/> rebuild status
[1] storage_volumes marked for rebuild
Global rebuilds:
device rebuild type rebuilder director rebuilt/total percent finished throughput ETA
------- ------------ ------------------ ------------- ---------------- ---------- -----
dd_test full s1_0c33_spa 15G/20G 75.14% 134M/s 37s
Local rebuilds:
No active local rebuilds.

Vous noterez qu’afin d’accélérer la reconstruction, j’ai augmenté la taille du transfer-size à l’interieur du distributed device, petite astuce qui peut aussi vous être utile, mais attention à la consommation sur votre réseau inter-site ;)

Le distributed device est désormais en cours de reconstruction et il nous reste juste à remettre tout en place au niveau des règles de failover (consistency groups, ruleset éventuellement) et représenter le volume du coté cluster-2 :

VPlexcli:/> cd /clusters/cluster-1/consistency-groups/
VPlexcli:/clusters/cluster-1/consistency-groups> consistency-group add-virtual-volumes vv_bas
VPlexcli:/clusters/cluster-1/consistency-groups> consistency-group add-virtual-volumes vv_bas_test --consistency-group cg_dd_bas
VPlexcli:/clusters/cluster-1/consistency-groups> export storage-view addvirtualvolume --view svhn_vmware_bas --virtual-volumes vv_bas_test -f
WARNING: Exporting a volume through 2 or more views is a valid configuration in only very specific circumstances. Please ensure that initiator ports: radiume2650_tu18_yang,
radiume2650_tu18_ying, bacassab2_ying, bacassab2_yang, bacassab3_yang, bacassab_yang, bacassab3_ying, bacassab_ying are participating in host cluster and should all have
access to volume 'vv_bas_test'. Proceeding anyways.

Un petit mot concernant l’asymétrie dont j’ai parlé en début d’article. Si vous souhaitez absolument avoir une symétrie parfaite entre vos deux clusters vis à vis des device / storage-volumes et extents, une fois cette première opération terminé, vous pouvez tout simplement reproduire (une fois le mirroir resynchronisé évidemment ;) ) la même opération, mais cette fois ci, sans augmenter la taille de la LUN, sur l’autre cluster. Dans notre exemple, vous sortez la LUN “composite” du cluster-1, vous cassez tout l’assemblage, vous représentez une LUN unique de la même taille que celle restée en prod, puis vous reconstruisez le mirroir, cette fois-ci du cluster-2 vers le cluster-1. La procédure est quasi identique, sans la partie extension. A l’issue, vous aurez à nouveau une seule LUN simple de chaque coté.

Voila, ce guide est terminé. Bien entendu, comme tout guide, il reste indicatif et je ne saurais que trop vous conseiller de contacter la hotline EMC en cas de doute sur votre config ou votre TAM ou référant VPlex chez EMC pour toute question.

Ce guide est une réécriture libre d’une doc fournie par EMC et issue des procedure generators VPlex, qui sont également des sources d’information très intéressante et la base du scripting VPlex en général.