Dell EMC VPLEX: DU efter att ha ändrat LUN-typen från tunn till tjock på BE-disksystem

Frågan:

Påverkan på DU/höga prestanda ses mot en påverkad volym som konverteras från tunn till tjock LUN i backend-disksystemet.  

I den aktuella versionen finns det ett problem med VPLEX-backendkoden där det felaktigt kan anse att ett LUN är tunt om underliggande LUN i backend-disksystemet konverteras från tunn till icke-tunn kapabel provisionering.

Attributet med tunn kapacitet måste uppdateras på båda nivåerna, dvs. Virtuell volym och Lagringsvolym automatiskt, när LUN-typen ändras i backend-disksystemet. Observera att attributet för tunn kapacitet ska uppdateras automatiskt på lagringsvolymnivå eftersom "tunn kapacitet" är ett skrivskyddat attribut på lagringsvolymnivå.

Om det tunna attributet inte ändras manuellt på Virtual-Volume-nivå kommer VPlex att fortsätta att skicka UNMAP-begäran till den logiska enhet vars LUN-typ ändras till thick och alla dessa förfrågningar kommer att avbrytas av backend-LUN.

Upplösning:

Det här problemet åtgärdas i GeoSynchrony 6.2.0.00.00.32 och senare versioner.

Lösningssteg:

1. När du har ändrat LUN-typen från tunn till tjock i BE-disksystemet kontrollerar du att attributet "Thin-capable" ändras på den virtuella volymen.  Om du ändrar attributet till false på virtuell volym skickas inte längre UNMAP-kommandon till BE LUN enligt följande:

1.a) Logga in i vplexcli-kontexten på följande sätt:
Obs! VPLEX som kör GeoSynchrony före 6.x vid åtkomst till vplexcli kräver inloggningsuppgifterna för tjänstkontot för inloggning.

service@ManagementServer:~> vplexcli
Försöker ::1...
Ansluten till localhost.
Escape-tecknet är '^]'.
 
Ange användarnamn: service
 
Lösenord:
Skapa loggfil:/var/log/VPlex/cli/session.log_service_localhost_Logfile_T24531_yyyymmddhhmmss

1.b) Öppna den aktuella virtuella volymkontexten och kör kommandot nedan enligt följande, vilket visar att attributet "thin-capable" är inställt på "true" även efter att LUN-typen har ändrats från tunn till tjock i BE-disksystemet:
 

1.c) Inaktivera attributet "thin-capable" manuellt till "false" enligt följande, vilket inaktiverar tunn provisionering på virtuell volymnivå enligt följande:

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

1.d) När du har ändrat attributet "thin-capable" till "false" i den virtuella volymen bör den problematiska hälsohälsan för den virtuella volymen ändras till "OK". Kör kommandot "cluster status" för att kontrollera den övergripande hälsan för VPlex enligt följande:

Exempel:
VPlexcli:/clusters/cluster-1/virtual-volumes/device_****_vol> ll
Namnvärde
-------------------------- ----------------------------------------
blockantal 429654016
blockstorlek 4K
synkron
kapacitet i cacheläge 12G
konsekvensgrupp -
expanderbar sann
expanderbar kapacitet 0B
expansionsmetod storage-volume
expansion-status -
health-indications []
health-state ok
locality distribuerad
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 inaktiverad
VPD-ID för volymtyp virtuell volym
VPD83T3:60001440000****************

VPlexcli:/> klusterstatus
Kluster-1
driftstatus:            OK
övergångsindikationer:
        Övergångsframsteg:
        Hälsotillstånd:                  OK
Hälsoindikationer:
        lokal-com:                     ok

Kluster-2
driftstatus:            OK
övergångsindikationer:
        Övergångsframsteg:
        Hälsotillstånd:                  OK
Hälsoindikationer:
        lokal-com:                     Okej

WAN-com: OK


2. Om hälsotillståndet för virtuella volymer fortfarande rapporterar "fel" eller "kritiskt fel" efter ovanstående steg utför du matrisåteridentifiering mot BE-matrisen, där den problematiska logiska enheten tillhör. Matrisen som återidentifieras bör automatiskt uppdatera attributet på lagringsvolymnivå enligt följande:

Exempel:
VPlexcli:/> matris återidentifiering -a /clusters/cluster-1/storage-elements/storage-arrays/EMC-CLARiiON-CKM0018******* -c cluster-1

3. Även efter flera försök att återupptäcka disksystemet, om den problematiska virtuella volymhälsan fortfarande rapporterar "fel" eller "kritiskt fel" måste motsvarande logiska enhet på backend-disksystemsidan tas bort från disksystemets lagringsgrupp/pool och läggas till igen, och köra kommandot för återupptäckt av disksystemet så att en manuell identifiering utlöses på VPLEX-sidan. 

4. Om inget av ovanstående steg hjälper för att lösa problemet rekommenderar vi att användaren uppgraderar till den åtgärdade version som nämns ovan och sedan fortsätter med aktiviteten för ändring av LUN-typ.