Dell EMC VPLEX : Après la modification du type de LUN dynamique à lourd sur la baie BE

Question:

L’impact DU/hautes performances est observé sur un volume affecté qui est converti d’une LUN dynamique en LUN statique sur la baie back-end.  

Dans la version actuelle, il existe un problème avec le code back-end VPLEX où il peut considérer à tort une LUN comme compatible avec le provisionnement dynamique si la LUN sous-jacente de la baie back-end est convertie d’un provisionnement compatible avec le provisionnement dynamique en provisionnement non compatible avec le provisionnement dynamique.

L’attribut compatible avec le provisionnement dynamique doit être mis à jour automatiquement aux deux niveaux, c’est-à-dire volume virtuel et volume de stockage, lorsque le type de LUN est modifié sur la baie back-end. Veuillez noter que l’attribut compatible avec le provisionnement dynamique doit être automatiquement mis à jour au niveau du volume de stockage, car « compatible avec le provisionnement dynamique » est un attribut en lecture seule au niveau du volume de stockage.

Si l’attribut compatible avec le provisionnement dynamique n’est pas modifié manuellement au niveau du volume virtuel, VPlex continue d’envoyer la demande de suppression de mappages à l’unité logique dont le type de LUN est modifié en provisionnement définitif et toutes ces demandes sont abandonnées par le LUN back-end.

Résolution:

Ce problème est résolu dans GeoSynchrony 6.2.0.00.00.32 et versions ultérieures.

Étapes de contournement :

1. Après avoir modifié le type de LUN de thin à thick sur la baie BE, assurez-vous que l’attribut « Thin-capable » est modifié sur le volume virtuel en conséquence.  La modification de l’attribut sur false sur le volume virtuel n’enverra plus de commandes UNMAP à BE LUN comme suit :

1.a) Connectez-vous au contexte vplexcli comme suit :
REMARQUE : VPLEX exécutant une version de GeoSynchrony antérieure à la version 6.x lors de l’accès à vplexcli nécessite les informations d’identification du compte de service pour la connexion.

service@ManagementServer :~> vplexcli
Trying ::1...
Connecté à l’hôte local.
Le caractère d’échappement est '^]'.
 
Saisissez le nom d’utilisateur : service
 
Mot de passe :
création du fichier journal :/var/log/VPlex/cli/session.log_service_localhost_Logfile_T24531_yyyymmddhhmmss

1.b) Accédez au contexte du volume virtuel concerné et exécutez la commande ci-dessous comme suit, qui montre que l’attribut « thin-capable » est défini sur « true », même après que le type de LUN est passé de thin à thick sur la baie BE :
 

1.c) Désactivez manuellement l’attribut « thin-capable » sur « false » comme suit, ce qui désactivera le provisionnement dynamique au niveau du volume virtuel comme suit :

Example :
VPlexcli :/clusters/cluster-1/virtual-volumes/device_****_vol> set thin-capable false

1.d) Après avoir remplacé l’attribut « thin-capable » par « false » au niveau du volume virtuel, l’intégrité problématique du volume virtuel doit être remplacée par « OK ». Exécutez la commande « cluster status » pour vérifier l’intégrité globale du VPlex comme suit :

Exemple :
VPlexcli :/clusters/cluster-1/virtual-volumes/device_****_vol> ll
Name Value
-------------------------- ----------------------------------------
block-count 429654016
block-size 4K
cache-mode synchrone
capacity 12G
consistency-group -
expandable true
expandable-capacity 0B
expandable expandable storage-volume
expansion-status -
health-indications []
health-state ok
locality distributed
operational-status ok
recoverpoint-protection-at []
recoverpoint-usage -
scsi-release-delay 0
service-status running
storage-array-family clariion
storage-tier -
supporting-device device_****_1
system-id device_**_1_vol
thin-capable false
thin-enabled disabled
vpd-id de volume virtuel
de type volume VPD83T3:60001440000****************

VPlexcli :/> cluster status
Cluster cluster-1
operational-status :            OK
Transitioning-Indications :
        Transitioning-Progress :
        état d’intégrité :                  Indications de santé OK
:
        local-com :                     ok

Cluster cluster-2
operational-status :            OK
Transitioning-Indications :
        Transitioning-Progress :
        état d’intégrité :                  Indications de santé OK
:
        local-com :                     d’accord

WAN-com : OK


2. Si l’intégrité du volume virtuel signale toujours un état « erreur » ou « panne critique » après les étapes ci-dessus, effectuez une nouvelle détection de la baie sur la baie BE, à laquelle appartient l’unité logique problématique. La baie re-discover doit actualiser automatiquement l’attribut au niveau du volume de stockage comme suit :

Example :
VPlexcli :/> array re-discover -a /clusters/cluster-1/storage-elements/storage-arrays/EMC-CLARiiON-CKM0018******* -c cluster-1

3. Même après plusieurs tentatives de redécouverte de la baie, si l’intégrité du volume virtuel problématique signale toujours une « erreur » ou une « panne critique », l’unité logique correspondante côté baie back-end doit être supprimée du groupe de stockage/pool de la baie et rajoutée à celle-ci, puis réexécutez la commande re-discover de la baie afin qu’une découverte manuelle soit déclenchée côté VPLEX. 

4. Si aucune des étapes ci-dessus ne permet de résoudre le problème, nous recommandons à l’utilisateur d’effectuer une mise à niveau vers la version corrigée mentionnée ci-dessus, puis de poursuivre l’activité de changement de type de LUN.