Dell EMC VPLEX: DU efter ændring af LUN-typen fra tynd til tyk på BE-array

Spørgsmål:

DU/høj ydeevne ses i forhold til en berørt diskenhed, som konverteres fra tynd til tyk LUN på back-end-arrayet.  

I den aktuelle version er der et problem med VPLEX backend-kode, hvor en LUN fejlagtigt kan betragtes som tynd, hvis underliggende LUN i backend-systemet konverteres fra tynd til ikke-tynd klargøring.

Den tynde attribut skal opdateres automatisk på begge niveauer, dvs. Virtual-Volume og Storage-Volume, når LUN-typen ændres i backend-arrayet. Vær opmærksom på, at tynd attribut bør opdateres automatisk på lagerdiskenhedsniveau, da "tynd-kompatibel" er en skrivebeskyttet attribut på lagerdiskenhedsniveau.

Hvis den tynde attribut ikke ændres manuelt på virtual-volume-niveau, fortsætter VPlex med at sende UNMAP-anmodning til den logiske enhed, hvis LUN-type ændres til tyk, og alle disse anmodninger afbrydes af backend-LUN'en.

Opløsning:

Dette problem er løst i GeoSynchrony 6.2.0.00.00.32 og nyere versioner.

Trin til løsning:

1. Når du har ændret LUN-typen fra tynd til tyk på BE-systemet, skal du sørge for, at attributten "Thin-capable" ændres på virtuel diskenhed i overensstemmelse hermed.  Hvis attributten ændres til false på virtuel diskenhed, sendes der ikke flere UNMAP-kommandoer til BE LUN på følgende måde:

1.a) Log ind på vplexcli-konteksten på følgende måde:
BEMÆRK: VPLEX, der kører GeoSynchrony før 6.x ved adgang til VPEXCLI kræver loginoplysninger til tjenestekontoen.

service@ManagementServer:~> vplexcli
Forsøger ::1...
Oprettet forbindelse til localhost.
Escape tegn er '^]'.
 
Indtast brugernavn: service

Adgangskode:Oprettelse af logfil:/var/log/VPlex/cli/session.log_service_localhost_Logfile_T24531_yyyymmddhhmmss 1.b) Kom ind i den pågældende virtuelle volumenkontekst, og udsted nedenstående kommando som følger,
  som viser, at attributten "tynd kapabel" er indstillet til "sand", selv efter at LUN-typen er ændret fra tynd til tyk ved BE-arrayet:


 

1.c) Deaktiver attributten "thin-capable" manuelt til "false" som følger, hvilket deaktiverer thin provisioning på virtual volume level som følger:

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

1.d) Når attributten "thin-capable" er ændret til "false" ved virtual-volume, skal den problematiske virtual-volume-tilstand ændres til "OK". Kør kommandoen "cluster status" for at kontrollere VPlex' generelle tilstand på følgende måde:

Eksempel:
VPlexcli:/clusters/cluster-1/virtual-volumes/device_****_vol> ll
Name Value
-------------------------- ----------------------------------------
block-count 429654016
blokstørrelse 4K
cache-mode synkron
kapacitet 12G
konsistensgruppe -
skalerbar ægte
udvidelseskapacitet 0B
udvidelsesmetode 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
Diskenhedstype virtual-volume
VPD-ID VPD83T3:60001440000****************

VPlexcli:/> klyngestatus
Klyngeklynge-1
driftsstatus:            OK
overgangsindikationer:
        Overgangsstatus:
        sundhedstilstand:                  OK
sundheds-indikationer:
        Lokalt-com:                     ok

Klyngeklynge-2
driftsstatus:            OK
overgangsindikationer:
        Overgangsstatus:
        sundhedstilstand:                  OK
sundheds-indikationer:
        Lokalt-com:                     Ok

WAN-COM: OK


2. Hvis tilstanden af virtuel diskenhed stadig rapporterer tilstanden "fejl" eller "kritisk fejl" efter ovenstående trin, skal du genopdage systemet i forhold til BE-arrayet, hvor den problematiske logiske enhed tilhører. Genopdagelsen af systemet bør automatisk opdatere attributten på lagerdiskenhedsniveau som følger:

Eksempel:
VPlexcli:/> genopdagelse af system -a /klynger/klynge-1/lagerelementer/lagersystemer/EMC-CLARiiON-CKM0018******* -c klynge-1

3. Selv efter flere forsøg på genopdagelse af systemet, hvis den problematiske virtuelle diskenhedstilstand stadig rapporterer "fejl" eller "kritisk fejl", skal den tilsvarende logiske enhed på backend-array-siden fjernes fra arrayets storagegruppe/pulje og føjes til den igen og køre kommandoen til genopdagelse af array, så en manuel registrering udløses på VPLEX-siden. 

4. Hvis intet af ovenstående trin hjælper med at løse problemet, anbefaler vi, at brugeren opgraderer til den rettede version, der er nævnt ovenfor, og derefter fortsætter med LUN-typeændringsaktiviteten.