Dell EMC VPLEX: DU dopo aver modificato il tipo di LUN da thin a thick su un array BE

Problema:

L'impatto di DU/prestazioni elevate si verifica su un volume interessato che viene convertito da thin a thick LUN sull'array back-end.  

Nella versione corrente, si verifica un problema con il codice back-end VPLEX per cui può erroneamente considerare una LUN come compatibile con thin se la LUN sottostante nell'array back-end viene convertita dal provisioning compatibile con thin a non thin.

L'attributo thin-capable deve essere aggiornato automaticamente a entrambi i livelli, ad esempio Virtual-Volume e Storage-Volume, quando il tipo di LUN viene modificato nell'array back-end. Tenere presente che l'attributo thin-capable deve essere aggiornato automaticamente a livello di volume di storage, in quanto "thin-capable" è un attributo read-only a livello di volume di storage.

Se l'attributo thin-capable non viene modificato manualmente a livello di volume virtuale, VPlex continuerà a inviare richieste UNMAP all'unità logica il cui tipo di LUN viene modificato in thick e tutte queste richieste verranno interrotte dalla LUN back-end.

Risoluzione:

Questo problema è stato risolto in GeoSynchrony 6.2.0.00.00.32 e versioni successive.

Procedura della soluzione alternativa:

1. Dopo aver modificato il tipo di LUN da thin a thick sull'array BE, assicurarsi che l'attributo "Thin-capable" sia modificato di conseguenza sul volume virtuale.  Se si modifica l'attributo in false sul volume virtuale, i comandi UNMAP non verranno più inviati alla LUN BE come segue:

1.a) Accedere al contesto vplexcli come segue:
NOTA: VPLEX che esegue GeoSynchrony prima della versione 6.x quando si accede a vplexcli richiederà le credenziali dell'account di servizio per l'accesso.

service@ManagementServer:~> vplexcli
Tentativo ::1...
Connesso a localhost.
Il carattere di escape è '^]'.
 
Inserisci nome utente: servizio
 
Password:
creazione del file di log:/var/log/VPlex/cli/session.log_service_localhost_Logfile_T24531_yyyymmddhhmmss

1.b) Entrare nel contesto del volume virtuale interessato ed eseguire il comando seguente come segue, che mostra che l'attributo "thin-capable" è impostato su "true" anche dopo che il tipo di LUN è stato modificato da thin a thick nell'array BE:
 

1.c) Disabilitare manualmente l'attributo "thin-capable" su "false" come segue, che disabiliterà il thin provisioning a livello di volume virtuale come segue:

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

1.d) Dopo aver modificato l'attributo "thin-capable" in "false" in virtual-volume, lo stato problematico del volume virtuale deve essere modificato in "OK". Eseguire il comando "cluster status" per controllare lo stato generale di VPlex come segue:

Esempio:
VPlexcli:/clusters/cluster-1/virtual-volumes/device_****_vol> ll
Name Value
-------------------------- ----------------------------------------
block-count 429654016
block-size Capacità sincrona
in modalità cache 4K
12G
consistency-group -
expandable true
expandable-capacity 0B
metodo di espansione 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
Tipo di volume: virtual-volume
VPD-ID VPD83T3:60001440000****************

VPlexcli:/> cluster status
Cluster cluster-1
operational-status:            OK
Indicazioni di transizione:
        Transizione-Progresso:
        stato-integrità:                  ok
salute-indicazioni:
        local-com:                     ok

Cluster-cluster-2
stato operativo:            OK
Indicazioni di transizione:
        Transizione-Progresso:
        stato-integrità:                  ok
salute-indicazioni:
        local-com:                     Ok

WAN-COM: OK


2. Se lo stato del volume virtuale segnala ancora lo stato "error" o "critical-failure" dopo il passaggio precedente, eseguire il nuovo rilevamento dell'array rispetto all'array BE, a cui appartiene l'unità logica problematica. Il nuovo rilevamento dell'array dovrebbe aggiornare automaticamente l'attributo a livello di volume di storage come segue:

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

3. Anche dopo diversi tentativi di ririlevamento dell'array, se lo stato del volume virtuale problematico continua a segnalare "errore" o "errore critico", è necessario rimuovere l'unità logica corrispondente sul lato array back-end dal gruppo di storage/pool dell'array e aggiungerla nuovamente ed eseguire nuovamente il comando di riscoperta dell'array in modo che venga attivata una rilevazione manuale sul lato VPLEX. 

4. Se nessuno dei passaggi precedenti aiuta a risolvere il problema, si consiglia all'utente di eseguire l'aggiornamento alla versione fissa sopra menzionata e quindi procedere con l'attività di modifica del tipo di LUN.