Doble feil og punkteringer i RAID-matriser

Innholdsfortegnelse

1. Datafeil og doble feil
2. Punkteringer: Hva er de, og hvordan forårsakes de?
3. Forhindre problemer før de oppstår, og løse punkteringer som har oppstått
   
    

Kapittel 1: Datafeil og doble feil

RAID-matriser er ikke immune mot datafeil.  RAID-kontrolleren og fastvare for harddisker inneholder funksjoner som sporer og korrigerer mange typer datafeil før de skrives til en matrise/stasjon.  Hvis du bruker utdatert fastvare, kan det føre til at feil data skrives til en matrise/stasjon fordi den mangler funksjonene for feilhåndtering/feilkorrigering som er tilgjengelige i de nyeste fastvareversjonene.


Datafeil kan også skyldes fysiske ugyldige blokker.  Dette kan for eksempel oppstå når skrive-/lesehodet påvirker den roterende platen (kalt et «hodekrasj»).  Blokker kan også bli ugyldige over tid fordi platens evne til å lagre biter magnetisk på en bestemt plassering blir svekket.  Ugyldige blokker som skyldes svekkelse i platen, kan ofte leses.  En slik ugyldig blokk kan bare spores uregelmessig eller med utvidet diagnostikk på stasjonene.  


En ugyldig blokk, også kalt en ugyldig logisk blokkadressering (LBA), kan også skyldes feil i logiske data.  Dette skjer når data skrives feil til en stasjon, selv om skrivingen rapporteres som vellykket.  I tillegg kan gyldige data som er lagret på en disk, bli endret utilsiktet.  Det kan for eksempel forekomme en «bitvending» når lese/-skrivehodet videresender eller skriver til en plassering i nærheten og fører til at data i form av nuller og ettall endres til en annen verdi.  Et slikt forhold fører til at datakonsekvensen blir skadet.  Verdien av dataene på en bestemt blokk er forskjellig fra de opprinnelige dataene, og det er ikke sikkert at den samsvarer med kontrollsummen for dataene.  Den fysiske LBA-en fungerer og kan skrives til uten problemer, men den inneholder for øyeblikket feil data og kan tolkes som en ugyldig blokk.


Ugyldige LBA-er rapporteres vanligvis som sense code 3/11/0. Sense Key 3 er en Medium Error (Middels feil).  En ytterligere Sense Code og Sense-kvalifikatoren 11/00 defineres som en Unrecovered Read Error (Ikke-gjenopprettet lesefeil).  Det blir ikke gjort forsøk på å korrigere blokken, og det fastsettes ikke om den ugyldige blokken er et resultat av en fysisk defekt på stasjonsplaten eller en feil i dataene av andre årsaker.  Eksistensen av sense code 3/11/00 betyr ikke automatisk at den fysiske stasjonen har sviktet eller at den bør skiftes ut.


Maskinvarebaserte RAID-kontrollere fra Dell tilbyr funksjoner som Patrol Read og konsekvenskontroll for å korrigere mange datafeilscenarioer.  Patrol Read fungerer som standard som en automatisk bakgrunnsoppgave som kontrollerer alle de individuelle blokkene på en harddisk for å sikre at dataene kan leses på riktig måte.  Patrol Read prøver å korrigere ugyldige blokker eller tilordne blokker som ikke kan korrigeres, på nytt til reserverte blokker.  Konsekvenskontroll er en funksjon som aktiveres manuelt (kan også planlegges), som sammenligner alle stasjonene i en matrise med hverandre for å sikre at dataene og redundansen samsvarer.  Tre stasjoner i en RAID 5-matrise blir for eksempel sammenlignet for å sikre at dataene og pariteten bruker de riktige verdiene.  Hvis én feil blir oppdaget, brukes de resterende dataene og/eller pariteten til å skrive på nytt og korrigere den ugyldige verdien.  I en RAID 1-matrise vil dataene på den ene stasjonen sammenlignes med den andre stasjonen for å sikre at dataene er riktig speilet.


Enhver enkeltfeil i en RAID-matrise, hvis den ikke er korrigert, kan forårsake mer alvorlige feil i matrisen, spesielt når det oppstår en ny feil.  Én eller flere enkeltfeil fører ikke til tap av data så lenge matrisen blir værende i en optimal tilstand.  Det er fortsatt tilstrekkelig data pluss redundans til å fungere normalt mens matrisen er optimal.


På grunn av muligheten for at kontrolleren kan korrigere for feil under normal drift, er det ikke alltid lett å oppdage når det finnes underliggende problemer i dataene.  Det er sjelden noen feil eller varsler i kontrollerloggen, maskinvareloggene eller hendelsesloggene for operativsystemet når ett eller flere enkeltfeilforhold finnes.  Derfor kan det hende at en matrise fungerer normalt i svært lang tid, til tross for at det finnes konsistensfeil og/eller enkeltfeil.




Figur 1: Flere enkeltfeil i en RAID 5-matrise – optimale arrayer


som vises i figur 1, har arrayet flere feil.  Men ettersom det bare er én enkeltfeil i en stripe, har kontrolleren fortsatt tilgang til alle dataene på grunn av redundansen i RAID 5.  Hvis feilen oppstår i paritetssegmentet, er alle data er intakte, og feilen har ingen innvirkning på leseoperasjoner.  Hvis feilen oppstår i et datasegment, må det utføres en XOR-sammenligning mellom de gyldige dataene og de gyldige paritetsdelene for å beregne det manglende/ugyldige datasegmentet på nytt.  I begge tilfeller, siden det bare er én enkelt feil i en stripe, er det tilstrekkelig redundans tilgjengelig for å få tilgang til alle dataene.

Hvis én eller flere stasjoner i en RAID-matrise inneholder datafeil, og en annen stasjon i arrayet ikke lenger er et aktivt medlem hvis matrisen på grunn av stasjonsfeil, fremmed konfigurasjon, fjerning av stasjon eller andre årsaker, oppretter dette en betingelse som kalles en «dobbeltfeil».  En dobbeltfeil fører til umiddelbar datatap av all informasjon i de berørte stripene.




Figur 2: Dobbeltfeil med en mislykket stasjon (data i stripe 1 og 2 går tapt) – degradert matrise


Det er mulig at det kan oppstå en dobbeltfeil med matrisen igjen i en optimal tilstand.  Dette kan forekomme med identiske ugyldige LBA-er på flere harddisker.  Dette forekommer svært sjelden, fordi det er så mange LBA-er på dagens store harddisker.  Det er svært usannsynlig at den samme LBA-en på flere harddisker er «dårlig» samtidig.

Hvis du utfører regelmessige konsekvenskontrolloperasjoner, rettes det opp for enkeltfeil, enten en fysisk ugyldig blokk eller en logisk feil i dataene. Konsekvenskontroll kan også redusere risikoen for en dobbeltfeil hvis det oppstår flere feil.  Når det ikke er mer enn én enkelt feil i en gitt stripe, kan en konsekvenskontroll nesten alltid eliminere feilen.

Tilbake til toppen
 

---

 

Kapittel 2: Punkteringer: Hva er de, og hvordan forårsakes de?

En punktering er en funksjon i PERC-kontrollerne fra Dell som er utformet for å gi kontrolleren muligheten til å gjenopprette redundansen i matrisen til tross for tap av data som skyldes en dobbeltfeil.  Et annet navn på en punktering er «gjenoppbygging med feil».  RAID-kontrolleren oppdager en dobbeltfeil, og fordi det ikke er nok redundans å gjenopprette dataene i den aktuelle stripen, oppretter kontrolleren en punktering i stripen og tillater at gjenoppbyggingen fortsetter.

 

• Et forhold som fører til at data er utilgjengelige i samme stripe på flere stasjoner, er en dobbeltfeil
• Dobbeltfeil fører til tap av alle data på den aktuelle stripen
• Alle punkteringer er dobbeltfeil, men ikke alle dobbeltfeil er punkteringer

Figur 3: Punkterte striper (data i stripe 1 og 2 går tapt på grunn av dobbeltfeil) – Optimal matriseUten


punkteringsfunksjonen, vil gjenoppbyggingen av arrayet mislykkes og etterlate matrisen i en degradert tilstand.  I enkelte tilfeller kan feilene føre til at flere stasjoner mislykkes, slik at matrisen ender opp i en ikke-fungerende frakoblet tilstand.  Punktering av en matrise har ingen innvirkning på muligheten til å starte opp eller få tilgang til data i matrisen.  Eventuelle skader eller tapte data på grunn av en dobbeltfeil hadde allerede oppstått. 



Punkteringer kan forekomme i én av to situasjoner:
 

• Dobbeltfeil finnes allerede (data er allerede tapt)
  • Datafeil i en tilkoblet stasjon overføres (kopieres) til en gjenoppbyggingsstasjon

 

• Dobbeltfeil finnes ikke (data går tapt når en ny feil oppstår)
  • Hvis en ugyldig blokk forekommer på en tilkoblet stasjon mens den er i degradert tilstand, punkteres den aktuelle LBA-en

Fordelen med å punktere en matrise er å holde systemet tilgjengelig i produksjon, og redundansen i matrisen gjenopprettes.  Dataene i den aktuelle stripen er tapt uansett om punkteringen forekommer eller ikke.  Den største ulempen med LSI-metoden er at når matrisen har en punktering, oppstår det fortsatt uopprettelige feil hver gang de aktuelle dataene (hvis noen) åpnes. 


Punkteringer kan forekomme på tre plasseringer.  For det første kan en punktering forekommer på et tomt område som ikke inneholder data.  Denne stripen blir utilgjengelig, men ettersom det ikke finnes noen data på plasseringen, har det ikke stor innvirkning.  Alle forsøk fra et operativsystem på å skrive til en punktert stripe mislykkes, og dataene blir skrevet til en annen plassering. 


For det andre kan en punktering forekomme i en stripe som inneholder data som ikke er kritiske, for eksempel en Viktig-fil.  Hvis de aktuelle dataene ikke åpnes, genereres det ingen feil under normal I/U.  Forsøk på å sikkerhetskopiere filsystemet klarer ikke å sikkerhetskopiere filer som er berørt av en punktering.  Hvis du utfører en konsekvenskontroll eller Patrol Read-operasjoner, genereres sense-kode:  11.03.00 for den aktuelle LBA-en og/eller stripene.


For det tredje kan det forekomme en punktering i dataområdet som er tilgjengelig.  I slike tilfeller kan de tapte dataene føre til en rekke feil.  Feilene kan være mindre feil som ikke har negativ innvirkning på et produksjonsmiljø.  Feilene kan også være mer alvorlig og kan hindre systemet i å starte et operativsystem, eller føre til at applikasjoner slutter å fungere.


 En punktert matrise må til slutt slettes og opprettes på nytt for å fjerne punkteringen.  Denne prosedyren sletter alle data. Dataene må opprettes på nytt eller gjenopprettes fra en sikkerhetskopi etter at punkteringen er fjernet.  Løsningen på en punktering kan planlegges for en tid som er mer fordelaktig for virksomhetens behov.


Hvis du får tilgang til dataene på en punktert stripe, rapporteres det fortsatt feil mot de berørte ugyldige LBA-ene uten mulig korrigering. Til slutt (etter minutter, dager, uker, måneder og så videre) fylles BBM-tabellen (Bad Block Management = behandling av ugyldige blokker), slik at én eller flere stasjoner blir flagget som en prediktiv feil. I figur 3 vil stasjon 0 vanligvis være stasjonen som blir flagget som en prediktiv feil, fordi feilene på stasjon 1 og 2 blir overført til den. Stasjon 0 kan faktisk fungere som normalt, og utskifting av stasjon 0 vil bare føre til at erstatningen også flagges som prediktiv feil.


En konsekvenskontroll som utføres etter at en punktering har oppstått, vil ikke løse problemet.  Det er derfor veldig viktig at du utfører konsekvenskontroller jevnlig. Det er spesielt viktig før du bytter ut stasjoner, når det er mulig. Matrisen må være i en optimal tilstand for å utføre konsekvenskontrollen.


En RAID-matrise som inneholder én enkelt datafeil i forbindelse med en ekstra feilhendelse, for eksempel en harddiskfeil, fører til en punktering når den defekte disken eller den nye stasjonen bygges inn i matrisen. Eksempel: En optimal RAID 5-matrise inkluderer tre medlemmer, stasjon 0, stasjon 1 og stasjon 2. Hvis stasjon 0 mislykkes (figur 2) og byttes ut, brukes gjenværende data og paritet på stasjon 1 og 2 til å gjenoppbygge den manglende informasjonen erstatningsstasjon 0. Hvis det finnes en datafeil på stasjon 1 når gjenoppbyggingen når denne feilen, er det imidlertid ikke nok informasjon på stripen til å gjenoppbygge de manglende dataene på stripen. Stasjon 0 har ingen data, stasjon 1 har ugyldige data og stasjon 2 har gyldige data mens gjenoppbyggingen pågår. Det finnes flere feil på den aktuelle stripen. Stasjon 0 og 1 inneholder ikke gyldige data, så eventuelle data på denne stripen kan ikke gjenopprettes og går derfor tapt.  Resultatet som er vist i figur 3, er at det opprettes punkteringer (på stripe 1 og 2) under gjenoppbyggingen. Feilene overføres til stasjon 0. 


Punktering av matrisen gjenoppretter redundansen og returnerer matrisen til en optimal tilstand.  Dette sørger for at matrisen er beskyttet mot ytterligere tap av data hvis det skulle oppstå flere feil eller stasjonssvikt.
 
Tilbake til toppen
 

---

Kapittel 3: Forhindre problemer før de oppstår og løse punkteringer etter at de har oppstått

Det kan være fristende å jobbe under mottoet «hvis det ikke er ødelagt, så ikke fiks det». Selv om dette kan stemme på mange områder, anbefales det på det sterkeste at du utfører rutinemessig og jevnlig vedlikehold for å beskytte og administrere undersystemer for lagring på best mulig måte. Proaktivt vedlikehold kan korrigere eksisterende feil og hindre at enkelte feil oppstår. Det er ikke mulig å forhindre all feil, men de mest alvorlige feilene kan reduseres betydelig med proaktivt vedlikehold. Følgende trinn gjelder for undersystemer for lagring og RAID-undersystemer:

 

• Oppdater drivere og fastvare på kontrollere, harddisker, bakpaneler og andre enheter
• Utfør rutinemessige konsekvenskontroller
• Se gjennom logger for indikasjoner på problemer

Dette trenger ikke å være en teknisk gjennomgang på høyt nivå, men kan ganske enkelt være en grunnleggende oversikt over loggene på jakt etter svært åpenbare indikasjoner på potensielle problemer
. Kontakt Dells tekniske støtte med eventuelle spørsmål eller bekymringer. Det som bør gjøres


, er å sørge for at fastvaren holdes oppdatert. Fastvaren inneholder all logikken for drift av en enhet. Den har funksjonene og egenskapene for enheten samt en rekke funksjoner for feilbehandling og feilretting. Hvis fastvaren holdes oppdatert, kan du oppnå bedre ytelse og færre feil. Nye funksjoner og forbedringer kan også legges til via en fastvareoppdatering.


Fastvaren kan ligge på en rekke steder. RAID-kontrollere inneholder fastvare, og det samme gjør hver enkelt individuelle harddisk som er installert i et system eller en matrise. Bakplan og eksterne kabinetter inneholder også fastvare som kan påvirke driften av stasjoner og matriser i den.


En annen anbefaling for proaktivt vedlikehold er å utføre en konsekvenskontroll.  En konsekvenskontroll er en manuell operasjon fordi den bruker en del av den generelle tilgjengelige båndbredden på RAID-kontrolleren. Konsekvenskontrollen kan imidlertid planlegges for et tidspunkt der den har minst innvirkning på ytelsen.


Konsekvenskontrollen ser etter ugyldige blokker på diskene, men enda viktigere er det at dataene i matrisen sammenlignes for å sikre at alle delene samsvarer på riktig måte. Når den finner et problem, fastsetter den hvordan dataene skal se ut, og korrigerer dem ved å kontrollere dataene på andre stasjoner i matrisen. Korrigering av relativt små datafeil er den beste metoden for å redusere risikoen for punkteringer som skyldes eksisterende datafeil i forbindelse med en ny feil. Eksistensen av doble feil og punkteringer kan føre til tap av produktivitet i den tiden som er nødvendig for å gjenopprette matrisen(e) og dataene til en fungerende tilstand, eller til og med fullstendig tap av alle data.


Når det finnes en dobbel feil eller punktering, er det ofte noe datatap. Hvis disse feilene forekommer i et tomt område eller ikke-kritisk dataområde, er den umiddelbare virkningen på data i et produksjonsmiljø relativt liten. Disse feilene kan imidlertid bety at det finnes mer alvorlige problemer. Maskinvarefeil og utdatert fastvare kan kreve umiddelbar oppmerksomhet.


Hvis en kjent eller mistenkt dobbeltfeil eller punktering finnes, følger du disse trinnene for å minimere risikoen for mer alvorlige problemer:

 

• Utfører en konsekvenskontroll (matrisen må være optimal)
• Finn ut om det finnes maskinvareproblemer
• Kontroller kontrollerloggen
• Utfør maskinvarediagnostikk
• Kontakt Dells tekniske kundestøtte ved behov

Hvis disse trinnene er utført, finnes det andre mulige problemer. Punkteringer kan føre til at harddisker går inn i en prediktiv feilstatus over tid. Datafeil som overføres til en stasjon, blir rapportert som mediefeil på stasjonen, selv om det ikke finnes noen faktiske maskinvareproblemer. Hver gang LBA åpnes, rapporteres det en feil. Når feilloggen er full, vil stasjonen rapportere seg selv som en prediktiv feil.


Én enkelt punktert LBA på en stasjon kan rapporteres mange ganger. Avhengig av antallet punkteringer er det mulig at flere stasjoner i en matrise rapporteres som en prediktiv feil. Hvis du bytter ut stasjonen med den prediktive feilen, blir eksisterende punkteringer videre overført til erstatningsstasjonen, noe som til slutt fører til at erstatningsstasjonen også flagges som en prediktiv feil. I et slikt tilfelle er den eneste korrigerende handlingen å løse punkteringstilstanden.


Når vi ser på figur 3, kan vi se at det er en punktering på stripene 1 og 2. Bytte av harddisker løser ikke dette problemet, fordi det ikke er tilstrekkelig dataredundans til å bygge de opprinnelige dataene på nytt. Alle data som finnes i de punktert stripene, går tapt (med mindre de ligger i en tidligere sikkerhetskopi). Husk at en punktering ikke fører til tap av data, men det gjør en dobbeltfeil. En punktering er en metode for å gjenopprette redundans til en matrise som inneholder en dobbeltfeil.
 

 

 

 

1. Forkast bevart hurtigbuffer (hvis en slik finnes)
2. Fjern fremmede konfigurasjoner (hvis noen finnes)
3. Slett matrisen
4. Forskyv posisjonen for stasjonene med én (flytt disk 0 til spor 1, disk 1 til spor 2 og disk 2 til spor 0, som i figur 1)
5. Opprett matrisen på nytt etter ønske
6. Utfør en fullstendig initialisering av matrisen (ikke en hurtiginitialisering)
7. Utfør en konsekvenskontroll i matrisen

Hvis konsekvenskontrollen fullfører uten feil, kan du trygt regne med at matrisen nå er i god tilstand, og at punkteringen er fjernet. Data kan nå gjenopprettes til den friske matrisen.


I mer alvorlige tilfeller kan det hende at problemet ikke løses, og feil kan vedvare til tross for at du følger disse trinnene. Hvis du ikke løser et problem ved å følge disse trinnene, kontakter du Teknisk støtte hos Dell for å få mer hjelp.


Det kan være nødvendig å analysere punkteringene mer detaljert for å fastslå hvilke stasjoner som er felles. I figur 3 viser for eksempel kontrollerloggen en punktering mellom disk 0 og 1, og en punktering mellom disk 0 og 2. Disk 0 er den felles stasjonen. Følg de samme trinnene som ovenfor, men fjern først felles stasjoner helt. Hvis vi bruker figur 1 som eksempel, fjerner du disk 0 og følger deretter de angitte trinnene. Opprett matrisen ved hjelp av de gjenværende diskene (1 og 2). Når dette er fullført, og etter en konsekvenskontroll avgjør at matrisen er i god tilstand, legger du til disk 0 igjen og utfører trinnene på nytt med alle stasjonene, eller bruker funksjonene RLM (migrering av RAID-nivå) og/eller OCE -funksjonene (online kapasitetsutvidelse) til å legge til de gjenværende stasjonene i matrisen igjen.


Alle stasjoner som flagges med prediktiv feil, bør fjernes og ikke inkluderes i gjenopprettingsprosessen. Vi bruker nok en gang figur 3 som eksempel: hvis disk 0 hadde en prediktiv feil, fjerner du denne stasjonen. Deretter utfører du trinnene som beskrevet ovenfor. Siden det bare er to stasjoner igjen, er den opprettede RAID-matrisen RAID 1 i stedet for en RAID 5. Når du har skaffet en erstatningsdisk 0 (på grunn av den prediktive feilen), utfører du trinnene på nytt, inkludert alle de tre stasjonene, eller legger til disk 0 i den eksisterende matrisen ved hjelp av RLM og endrer den fra en RAID 1 med to stasjoner til en RAID 5 med tre stasjoner.


Prosessen kan være skremmende, spesielt med tanke på muligheten for tap av data. Forebygging er åpenbart mye bedre enn å endre opp med feil. Erfaring har vist at nesten alle dobbeltfeil og punkteringer kunne ha vært unngått ved å utføre proaktivt vedlikehold på RAID-maskinvaren og -matrisene.
 

 

 

Relatert artikkel
PERC – Slik løser du en RAID-punktering

 

Tilbake til toppen

 

-

-