Dell EMC VPLEX: DU nach dem Ändern des LUN-Typs von Thin zu Thick im BE-Array

Problem:

Eine DU/High-Performance-Auswirkung tritt bei einem betroffenen Volume auf, das auf dem Back-end-Array von einer Thin- zu einer Thick-LUN konvertiert wird.  

In der aktuellen Version gibt es ein Problem mit VPLEX-Back-end-Code, bei dem eine LUN fälschlicherweise als Thin-fähig betrachtet werden kann, wenn die zugrunde liegende LUN im Back-End-Array von Thin in Non-Thin-fähiges Provisioning konvertiert wird.

Das Attribut "Thin-Capable" muss auf beiden Ebenen, d. h. "Virtual-Volume" und "Storage-Volume", automatisch aktualisiert werden, wenn der LUN-Typ auf dem Back-end-Array geändert wird. Bitte beachten Sie, dass das Attribut "Thin-fähig" auf Storage-Volume-Ebene automatisch aktualisiert werden sollte, da "Thin-Capable" ein schreibgeschütztes Attribut auf Storage-Volume-Ebene ist.

Wenn das Attribut "thin-capable" nicht manuell auf der Ebene des virtuellen Volumes geändert wird, sendet VPlex weiterhin eine UNMAP-Anforderung an die logische Einheit, deren LUN-Typ in "Thick" geändert wird, und alle diese Anfragen werden von der Backend-LUN abgebrochen.

Auflösung:

Dieses Problem wird in GeoSynchrony 6.2.0.00.00.32 und höher behoben.

Schritte zur Problemumgehung:

1. Stellen Sie nach dem Ändern des LUN-Typs von Thin zu Thick auf dem BE-Array sicher, dass das Attribut "Thin-capable" auf dem virtuellen Volume entsprechend geändert wird.  Wenn Sie das Attribut auf dem virtuellen Volume auf "false" ändern, werden keine weiteren UNMAP-Befehle wie folgt an die BE-LUN gesendet:

1.a) Melden Sie sich wie folgt beim vplexcli-Kontext an:
HINWEIS: VPLEX, auf dem GeoSynchrony vor 6.x ausgeführt wird, erfordert beim Zugriff auf die vplexcli die Zugangsdaten des Servicekontos für die Anmeldung.

service@ManagementServer:~> vplexcli
versucht ::1...
Verbunden mit localhost.
Das Escapezeichen ist '^]'.
 
Nutzernamen eingeben: service
 
Kennwort:
Logfile erstellen:/var/log/VPlex/cli/session.log_service_localhost_Logfile_T24531_yyyymmddhhmmss

1.b) Rufen Sie den Kontext des betreffenden virtuellen Volumes auf und geben Sie den folgenden Befehl wie folgt aus, der zeigt, dass das Attribut "thin-capable" auf "true" festgelegt ist, auch wenn der LUN-Typ im BE-Array von "Thin" zu "Thick" geändert wurde:
 

1.c) Deaktivieren Sie das Attribut "thin-capable" manuell wie folgt auf "false", wodurch das Thin Provisioning auf der Ebene des virtuellen Volumes wie folgt deaktiviert wird:

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

1.d) Nach dem Ändern des Attributs "thin-capable" auf "false" beim virtuellen Volume sollte die problematische Integrität des virtuellen Volumes in "OK" geändert werden. Führen Sie den Befehl "cluster status" aus, um die allgemeine Integrität von VPlex wie folgt zu überprüfen:

Beispiel:
VPlexcli:/clusters/cluster-1/virtual-volumes/device_****_vol> ll
Name Wert
-------------------------- ----------------------------------------
Blockanzahl 429654016
Blockgröße 4 KB
Cache-Modus synchrone
Kapazität 12G
Consistency-Group -
expandable true
expandable-capacity 0B
expansion-method 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 des virtuellen Volumes
vom Typ Volume-Typ VPD83T3:60001440000****************

VPlexcli:/> Clusterstatus
Betriebsstatus von Cluster-Cluster-1
:            OK
Übergangs-Indikationen:
        transitioning-progress:
        health-state:                  OK
Gesundheits-Indikationen:
        local-com:                     ok

Betriebsstatus von Cluster Cluster-2
:            OK
Übergangs-Indikationen:
        transitioning-progress:
        health-state:                  OK
Gesundheits-Indikationen:
        local-com:                     Okay

wan-com: OK


2. Wenn die Integrität des virtuellen Volumes nach den oben genannten Schritten immer noch den Status "Fehler" oder "kritischer Fehler" meldet, führen Sie eine erneute Arrayerkennung für das BE-Array durch, zu dem die problematische logische Einheit gehört. Bei der erneuten Erkennung des Arrays sollte das Attribut auf Storage-Volume-Ebene automatisch wie folgt aktualisiert werden:

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

3. Wenn die problematische Integrität des virtuellen Volumes auch nach mehreren Versuchen der erneuten Arrayerkennung immer noch "Fehler" oder "kritischer Fehler" meldet, muss die entsprechende logische Einheit auf der Back-end-Arrayseite aus der Speichergruppe/dem Pool des Arrays entfernt und wieder hinzugefügt werden. Führen Sie den Befehl "array re-discover" erneut aus, damit eine manuelle Erkennung auf der VPLEX-Seite ausgelöst wird. 

4. Wenn keiner der oben genannten Schritte zur Lösung des Problems beiträgt, empfehlen wir dem Nutzer, ein Upgrade auf die oben genannte korrigierte Version durchzuführen und dann mit der LUN-Typänderungsaktivität fortzufahren.