VNX / Yhtenäisyys: Tietoja korjaamattomista sektoreista ja pariteettivirheistä (käyttäjän korjattavissa)

Tietoja korjaamattomista sektoreista ja pariteettivirheistä CLARiiON-, VNX- tai Unity-matriisissa.

Tapahtumalokisanomat, kuten seuraavat, voivat näkyä myös nimellä Dial Homes:

VNX1
Error code: 0x953 pariteetin
sektorivirhekoodi: 0x957 korjaamaton tietosektorin
virhekoodi: 0x68A pariteetin
sektorivirhekoodi: 0x695 korjaamaton tietosektorin
virhekoodi: 0x840 tietosektorin
mitätöimä b26-välimuisti on CORRUPT_CRC. LUN= 309 ca_sync.c 0 309 2

VNX2
71688003 Korjaamaton sektori RAID Group: %2 Sijainti: %3 LBA:ta: %4 lohkoa: %5 Virhetiedot: %6 Lisätietoja: %7
71688008 Korjaamaton sektori RAID-ryhmä: 10 Asento: 1 LBA: d180 Lohkot: 8 Virhetiedot: 0 Lisätietoja: e [r5_rb FLU 8224 r5_rb]
71688008 Korjaamaton sektori RAID Group: 10 Asento: 1 LBA: d170 Lohkot: 8 Virhetiedot: 0 Lisätietoja: e [r5_rb FLU 8224 r5_rb]
71688001 Tietosektori mitätöi RAID Groupin: 10 Asento: 1 LBA: d121 Lohkot: 7 Virhetiedot: 0 Lisätietoja: e [r5_rb FLU 8224 r5_rb]

Korjaamattomia virheitä ilmenee, kun kahdella saman raid-ryhmän eri levyllä, samalla sektorilla, on mediavirheitä. 
Yksi esimerkki on, että kun levy, jossa on mediavirheitä, kopioi hotspare -levylle ja samalla sektorilla saman raid-ryhmän toisella levyllä on myös mediavirheitä, tämä johtaisi korjaamattomaan virheeseen / sektoriin. 

Edellä kuvatut tapahtumakoodit kirjataan, kun järjestelmä ei pysty lukemaan tietosektoreita levyltä, ja myöhemmät yritykset rekonstruoida tiedot muilta RAID-ryhmän levyiltä epäonnistuivat. Korjaamattomat sanomat ilmaisevat, mitkä levyt eivät pystyneet lukemaan sektoreita onnistuneesti, ja mitätöidyt sanomat ilmaisevat, mitkä levysektorit oli merkitty virheellisiksi tietyssä sijainnissa. Tämä merkintä tehdään sen varmistamiseksi, että isäntäjärjestelmään ei palauteta virheellisiä tietoja. Yritykset lukea mitätöidystä sijainnista johtavat siihen, että isännälle palautetaan kova virhe.
Yritykset kirjoittaa mitätöituun sijaintiin viimeistelevät mitätöimättömän sijainnin onnistuneesti ja yleensä "täyttävät" (korvaavat) tyhjän sijainnin, joten korjaamaton korjataan tehokkaasti. Tästä syystä joskus aiemmat korjaamattomat virheet katoavat, kun isäntä on korvannut nämä sektorit uusilla hyvillä tiedoissa.

VNX:n varalta:
Kun kaikki laitteisto-ongelmat on ratkaistu, Dell EMC:n teknisen tuen on suoritettava manuaalinen vain luku taustan tarkistaminen (ROBV), jos ongelma koskee poolin sisäisiä LUN-laitteita. ROBV lukee ja tarkistaa koko LUN:n (sisäinen) korjaamattomien tietojen tiedot, mukaan lukien käyttämättömän tilan, määrittääkseen, kuinka monta korjaamatonta sektoria saattaa vielä olla olemassa.
Kun ROBV on valmis, jos korjaamattomia tietoja esiintyy edelleen, Dell EMC:n teknisen tuen insinöörin on suoritettava lisävaiheita, kuten kerättävä ja analysoitava tallennustilan varaustaulukon tietoja (SAT) tunnistaakseen ne käyttäjät, joita asia koskee (sisäiset LUN-tunnukset, joista korjaamattomat löytyivät, yhdistetään käyttäjän LUN-tiedostoihin).
Täydellinen selvitys ja ROBV:n suorittamiseen tarvittavat ennakkovaatimukset ovat artikkelissa 466638, VNX: Vain luku -taustan tarkistamisen selitys (ROBV) (käyttäjän korjattavissa)

Kun käyttäjän LUN-tiedostosta löytyy korjaamaton sektori, isäntäsovelluksen on tarkistettava käyttäjätiedot selvittääkseen, ovatko käyttäjätiedot vioittuneita vai sijaitseeko virhe käyttämättömässä tilassa. Mikä tahansa prosessi, joka lukisi tiedot, kuten varmuuskopio, soveltuisi tunnistamaan / merkitsemään mahdollisen vioittumisen.
Jos vioittuminen tapahtuu, tiedot voidaan palauttaa hyvästä varmuuskopiosta joko täydellisellä hyvityksellä tai vain tiedostojen osittaisella palauttaminen.
Jos varmuuskopiota ei ole, tietojen palauttamiseen tai uudelleenluomiseen on käytettävä toista isäntäsovelluksen keinoa. 

Jos korjaamaton virhe ei löydy käyttäjätiedoista, taustaprosessit saattavat silti huomata virheen tulevaisuudessa, jos isäntä-I/O ei korvaa sektoria. Tämä voi johtaa virheelliseen arvioon siitä, että kyseessä on uusi virhe ja että se aiheuttaa viivästyksiä vanhan virheen analysoinnissa ja korjaamisessa, jota ei ole täysin ratkaistu.
Tässä tapauksessa on erittäin suositeltavaa siirtää hyvät tiedot toiseen LUN: iin ja poistaa alkuperäinen lun.

Unityssävoi olla muita menetelmiä tämän ongelman ratkaisemiseksi. Tarkista unity-artikkelit.

Usein kysytyt kysymykset:

Onko tekniikalla toinen tapa palauttaa kadonneet asiakastiedot, jos asiakkaan isäntäsovellus ei korvaa tietoja ja jos palautus varmuuskopiosta ei toimi? 
Ei ole muuta tapaa palauttaa tietoja kuin palautustoiminto tai luoda tiedot sovelluksesta uudelleen.
Koska korjaamattomat tiedot todella puuttuvat tiedoista, ei ole mitään keinoa tietää, mitä näiden tietojen pitäisi olla, jotta ne voitaisiin kirjoittaa takaisin.  Siksi ala "mitätöidään" ja isännälle palautetaan kova virhe. On parempi palauttaa kova virhe kuin virheelliset tiedot. 

Onko mitätöity sektori mahdollista muuttaa levyn sijaintia? 
Tavallisen LUN:n osalta virheellinen tietosektori pysyy aina samana.
Jos poolin LUN on käytössä automaattisella porrastelulla, se voi siirtyä, jos sektori siirretään.

Onko olemassa keinoa selvittää mitätöityjen sektorien todellinen sijainti?  
Mitätöityjen sektorien sijaintia on hyvin vaikea paikantaa, koska LUN-tunnukset on yhdistetty RAID-ryhmiin tai pooleihin ja mitä tietoja tapahtumalokeista on saatavilla.
Ota yhteyttä Dell EMC -tukeen ja pyydä lisäapua mitätöityä sektoria sisältävien lohkojen tunnistamiseen.  Tukitiimin on ensin mentävä ensin korjaamaton palautusprosessi läpi ja sitten eskaloittava ongelma palautustiimille. . 

Jos mitätöity sektori ei näytä vaikuttavan asiakastietoalueeseen, onko siitä mahdollista päästä eroon avaamatta LUN:n sidontaa?
Jonkin verran onnistumista on raportoitu kirjoitettaessa väliaikaisia tietoja LUN:n täyttämiseksi ja sitten poistettaessa väliaikaisia tietoja.  Jos mitätöidylle alueelle kirjoitetaan väliaikaisia tietoja, mitätöidyt sijainnit täytetään, jolloin virheellinen sektori palautetaan kelvollisilla tiedoissa. 

Voiko asiakas tarkistaa tiedostojärjestelmän tietojen eheyden vain CHKDSK: n tai FSCK: n avulla, jos Vain luku -taustatarkistus ilmoittaa korjaamattomista virheistä? 
Kun on ongelma korjaamattomia sektoreita, asiakastietojen tulisi tarkistaa, onko tiedosto vioittunut. Voit tehdä tämän ajaessasi jonkinlaista sovellusta tai ohjelmaa, joka lukee kaikki LUN-tilan käytetyt sektorit. Yleisin menetelmätyyppi on tietojen täydellinen varmuuskopiointi. Ei ole suositeltavaa suorittaa vain FSCK (UNIX) tai CHKDSK (Windows), koska nämä apuohjelmat tarkistavat vain tiedostojen metatietoalueen. Jos korjaamattomat sektorit eivät ole metatietotilassa, asiakkaalle jää vaikutelma, että tiedot ovat kunnossa, vaikka ne eivät itse asiassa olisi.

Muut usein kysytyt kysymykset:

Miksi tietojen pakkaaminen on poistettava käytöstä?
Tietojen pakkaaminen on ominaisuus, joka analysoi levyn tietoja ja käyttää algoritmeja, jotka pienentävät tietyntyyppisiin tiedostoihin luonnostaan kuuluvan toistuvan bittisarjan kokoa. RAID-ryhmän LUN:n pakkaustoiminnon aikana ohjelmisto siirtää ja pakkaa LUN-tiedot ohueen LUN-tiedostoon poolissa. LUN:sta tulee pakattu ohut LUN. Allas-LUN:ien (paksut ja ohuet) puristustoiminnot tehdään altaassa, jossa tiivistetty LUN sijaitsee. Aina kun tietoja pakataan, poolissa on tietojen siirto, joka ei auta meitä tunnistamaan oikeaa MLU:ta, johon korjaamattomuus tai odottamaton yhteistoiminta vaikuttavat. Joten ominaisuus on keskeytettävä.

Miksi automaattinen porrastaminen on poistettava käytöstä?
Automaattinen porrastusominaisuus siirtää tietoja tallennustasojen tai eri tallennusvälineiden (EFD, FC & SATA) välillä. Porrastetun tallennustilan tarkoituksena on säilyttää useimmin käytetyt tai tärkeät tiedot nopeista, korkean suorituskyvyn (kalliimpien) asemista ja siirtää harvemmin käytetyt ja vähemmän tärkeät tiedot heikkosuorituskykyisiin (halvempiin) asemista. Tietojen pakkaamisen lisäksi myös automaattiseen porrastamiseen liittyy tietojen siirtoa, joka ei auta meitä tunnistamaan sen MLU: n sektoria, johon korjaamattomat tai odottamattomat yhtymäkohteet vaikuttavat, jos sitä ei poisteta käytöstä. Uudelleensijoittaminen on siksi lopetettava ja aikataulu on pois käytöstä.

Miksi FAST Cache on poistettava käytöstä?
Nopea välimuisti on poistattava käytöstä vain, jos korjaamaton

sektorivirhe raportoidaan pikavälimuistissa Miksi ROBV on tarpeen suorittaa koko RAID-ryhmässä (RG) eikä tietyssä LUN:ssa?
Robv on tehtävä koko RG:lle, jotta se ei vaikuta tiettyihin muihin saman RG:n asiakas-LUN-tiedostoihin.

Miksi ROBV on tarpeen suorittaa uima-altaalla eikä vain RAID-ryhmässä?
Robv on ajattava koko poolissa, jos automaattinen porrastamisaikataulu on ollut jäljellä korjaamattoman raportoimisen jälkeen ja ROBV on ajoitettu alkamaan.  Tämä on tarpeen, koska tietosektorit voivat siirtää korjaamattoman toiselle sektorille, jos kyseinen tietosektori siirretään toiselle tasolle.
 
Miksi SAT - Tallennustilan kohdistustaulukon tiedot on kerältäva?
Kun SAT-tiedot suoritetaan Dell EMC -tuen työkalujen kautta, asiakas LUN/MLU määrittää, missä korjaamattomalla sektorilla on.  Tämä osoittaa myös, onko ongelma asiakkaan LUN:n datatilassa vai metatietotilassa.