VNX: Het vervangen of proactief vervangen van een defecte of defect rakende Vault-schijf op een VNX2 array. (Dell EMC corrigeerbaar)
Summary: Het vervangen of proactief vervangen van een defecte of defect rakende Vault-schijf op een VNX2 array.
Symptoms
Een kluisschijf op een VNX MCx-array is mislukt en is naar een andere locatie gespaard. Als de klant een aantal gebruiker-LUN's heeft aangemaakt over de Vault-schijven en die data wil terugplaatsen naar de Vault-schijf, hoe worden die data dan teruggeplaatst?
Bij Permanent Sparing is er geen automatische kopieerbewerking voor opnieuw opbouwen. Wanneer een normale schijf defect raakt en wordt vervangen, is er geen automatische kopieerbewerking van de permanente reserveschijf naar de vervangen schijf. De schijf die de defecte schijf heeft vervangen, maakt nu deel uit van de RAID-groep.
Wanneer een defecte Vault-schijf wordt vervangen, wordt de nieuwe schijf geformatteerd en wordt de private space opnieuw opgebouwd vanuit andere Vault-schijven, maar als een klant een RAID-groep/LUN's op een Vault-schijf heeft gemaakt, worden de LUN-data niet terug gekopieerd. Het blijft op het schijf waar het opnieuw was opgebouwd. Als u de data handmatig wilt terug kopiëren naar de oorspronkelijke locatie, moet u de opdracht naviseccli copytodisk gebruiken.
Info:
Kluisschijven op de VNX2 van de volgende generatie zijn de eerste 4 schijven in de array; 0_0, 0_1, 0_2 en 0_3.
Elke Vault-schijf heeft ongeveer 300GB Private Space-ruimte nodig om MCx-code en andere array-gerelateerde data te bewaren.
Hoewel het niet wordt aanbevolen om de klant-LUN's op de Vault-schijven te zetten, doen sommige klanten dat wel.
Cause
Next Generation VNX kopieert geen klantdata of bouwt deze niet opnieuw op als die data op Vault-schijven was opgebouwd. Wanneer een Vault-schijf wordt vervangen, wordt de nieuwe schijf geformatteerd en wordt de private space opnieuw opgebouwd vanuit de andere Vault-schijven, maar LUN-data van klanten worden niet terug gekopieerd. Als u de data handmatig terug wilt kopiëren naar de oorspronkelijke locatie, moet u de opdracht naviseccli copytodisk gebruiken.
Resolution
Scenario 1: De Vault-schijf heeft een defect en is al permanent overgenomen door een andere schijf in de array. Ga als volgt te werk om klantdata weer naar de oorspronkelijke locatie te kopiëren:
De naviseccli copytodisk-opdracht initieert het kopiëren van data van een geconfigureerde schijf (onderdeel van een RAID-groep) naar een niet-gebonden schijf. De gebruiker kan deze opdracht gebruiken voor het kopiëren van data van een gebonden schijf naar een niet-gebonden schijf, en niet alleen van een permanente reserveschijf naar een vervangende schijf.
In dit voorbeeld kopiëren we van schijf 0_1_5 naar 0_0_2
naviseccli -h <ipaddress> copytodisk 0_1_5 0_0_2
WARNING: De data van bronschijf 0_1_5 zal worden gekopieerd naar de doelschijf 0_0_2. Dit proces kan niet worden afgebroken en kan veel tijd in beslag nemen.
Wilt u doorgaan met kopiëren? (j/n) j
De bewerking van het terugkopiëren wordt dan gestart.
Scenario 2: Berichten geven aan dat de schijf een defect heeft. Het proactief vervangen van de defecte Vault-schijf in slots 0,1,2,3 op bus 0
- Zorg ervoor dat u alle niet-gebonden schijven op de array verwijdert. (We doen dit omdat een niet-gebonden schijf een permanente reserve/hotspare-schijf kan worden op de VNX2-array.)
- Controleer de schijven in Unisphere of Naviseccli in slotpositie 0,1,2,3 en zorg ervoor dat er geen dubbele fout is opgetreden op deze set schijven voordat u verder gaat.
- Nadat de timer van 5 minuten is verstreken, plaatst u een nieuwe schijf in het slot. De schijf moet gedurende ten minste 5 minuten worden verwijderd om de LUN's van de klant op de Vault-schijf volledig opnieuw op te bouwen. wacht minimaal 5 minuten**3 Verwijder de defecte of verdachte schijf die moet worden vervangen uit het slot en
- de nieuwe schijf zal online komen en het opnieuw opbouwen van gebruiker-LUN's (als er gebruiker-LUN's zijn geconfigureerd op Vault-schijven) zal starten vanaf de andere Vault-schijven.
Opmerking ** Zeer belangrijk om de schijf minimaal 5 minuten
verwijderd te latenMet Flare kan een schijf in een redundante RAID-groep offline zijn gedurende een periode van maximaal 5 minuten terwijl schrijf-I/O naar deze schijf wordt gelogd. De werkelijke I/O-waarden worden niet geregistreerd. Een bitmap wordt gebruikt om bij te houden welke adresbereiken op de schijf vervuild zijn. Als dezelfde schijf binnen een limiet van 5 minuten weer toegankelijk wordt, wordt het rebuild-logboek gebruikt om het station snel opnieuw op te bouwen, zoals in dit geval. Dit wordt een differentiële rebuild genoemd. Zodra de schijf langer dan 5 minuten verwijderd is geweest, zal er een volledige rebuild van LUN's van de andere Vault-schijven plaatsvinden. Als er geen gebruiker-LUN's zijn geconfigureerd op de Vault-schijven, hoeft u de gebruiker-LUN's niet opnieuw op te bouwen.