Hot Spare eller hot mess

En vanlig tilnærming for å legge til et sikkerhetslag i RAID er å ha reservedisk(er) tilgjengelig slik at byttetiden for en defekt disk minimeres. Den mest ekstreme formen for dette kalles å ha en “hot spare” – en reservedisk som faktisk sitter i arrayen, men er ubrukt inntil arrayen oppdager en diskfeil, hvorpå systemet automatisk deaktiverer den defekte disken og aktiverer hot spare-disken, akkurat som om et menneske hadde byttet ut den ene disken og satt inn den andre, slik at en resilver-operasjon (gjenoppbygging av arrayen) kan begynne så snart som mulig. Dette kan redusere tiden det tar å bytte inn en ny disk fra timer eller dager til sekunder og kan i teorien gi en ekstremt stor økning i sikkerhet.

Først vil jeg ta opp noe jeg personlig mener er en feil i navnekonvensjonene. Det vi kaller en hot spare burde etter min mening egentlig kalles en warm spare, fordi den sitter der klar til bruk, men ikke inneholder de nødvendige dataene for å kunne brukes umiddelbart. En reservedisk som oppbevares utenfor kabinettet – en som krever at et menneske griper inn og bytter diskene manuelt – ville være en cold spare. For å virkelig være en hot spare burde en disk allerede inneholde data og dermed være et aktivt deltagende medlem av RAID-arrayen på en eller annen måte. Red Hat har en god artikkel om hvordan denne terminologien gjelder for katastrofegjenopprettingslokasjoner som referanse. Denne differensieringen er viktig fordi det vi kaller en hot spare ikke allerede inneholder data og ikke umiddelbart trer inn for å erstatte den defekte disken, men i stedet trer inn for umiddelbart å begynne prosessen med å gjenopprette den tapte disken – en kritisk forskjell.

For å holde begrepene klare vil jeg fra nå av referere til det leverandørene kaller hot spares som “warm spares.” Dette vil gi mening om kort tid.

Det er to hovedproblemstillinger med warm spares. Den første er den ineffektive naturen til warm spare i de fleste brukstilfeller, og den andre er risikoen for “automatisk arrayødeleggelse.”

De fleste nærmer seg warm spare-konseptet som et middel til å redusere den høye risikoen for sekundær diskfeil på en RAID 5-array med paritet. RAID 5-arrayer beskytter kun mot svikt i én enkelt disk i arrayen. Når én disk har sviktet, er arrayen uten noen form for paritet, og ytterligere diskfeil resulterer i totalt tap av arrayen. RAID 5 velges fordi det er svært kostnadseffektivt for den gitte kapasiteten og ofrer pålitelighet for å oppnå denne kostnadseffektiviteten. Fordi RAID 5 derfor er risikabelt sammenlignet med andre RAID-alternativer, som RAID 6 eller RAID 10, er det vanlig å implementere en warm spare for å minimere tiden arrayen er i en degradert tilstand, slik at arrayen kan begynne å resilver seg selv så raskt som mulig.

Det viktigste å ta med seg her er at warm spares generelt brukes som en buffer mot bruken av mindre pålitelige RAID-arraytyper som et kostnadsbesparende tiltak. Warm spares er dramatisk mer vanlig i RAID 5-arrayer, etterfulgt av RAID 6-arrayer. Begge velges fremfor RAID 10 på grunn av kostnad per kapasitet, ikke for pålitelighet eller ytelse. Det finnes ett tilfelle der warm spare-ideen virkelig gir mening for ekstra pålitelighet, og det er RAID 10 med en warm spare, men det kommer vi til. Utenfor det scenariet mener jeg at warm spares gir liten mening i den virkelige verden.

Vi starter med å undersøke RAID 1 med en warm spare. RAID 1 består av to eller flere disker i et speil. Å legge til en warm spare er fint fordi hvis ett av de speilede parene svikter, vil warm spare umiddelbart begynne å speile den gjenværende disken og du vil igjen være beskyttet innen kort tid. Det er flott. Bortsett fra én liten feil: i stedet for å bruke en warm spare kunne den samme disken ha blitt lagt til RAID 1-arrayen hele tiden, der den ville ha vært et tredje speil. I denne kapasiteten som tredjespeil ville disken ha bidratt til den samlede ytelsen til arrayen og gitt en nesten femti prosent leseytelsesforbedring mens skriveytelsen holdt seg stabil, og gitt øyeblikkelig beskyttelse ved diskfeil i stedet for “så snart den har speilet seg”-beskyttelse. I bunn og grunn ville det ha vært en ekte “hot spare” i stedet for en warm spare. Så uten å bruke en eneste krone mer ville systemet ha hatt bedre diskarray-ytelse og bedre pålitelighet, rett og slett ved å ha den ekstra disken i en aktiv “i arrayen”-kapasitet i stedet for å sitte varm og ledig og vente på at katastrofen skal inntreffe.

Med RAID 5 ser vi en enda mer dramatisk advarsel mot warm spare-konseptet, her der det er mer vanlig enn noe annet sted. RAID 5 er enkelt-paritet RAID med mulighet til å gjenoppbygge, ved hjelp av pariteten, enhver disk i arrayen som svikter. Det er her de virkelige problemene begynner. I motsetning til RAID 1 der en re-speil-operasjon kan være ganske rask, har en RAID 5 resilver (gjenoppbygging) potensial til å ta svært lang tid. Warm spare vil ikke hjelpe med å beskytte arrayen før denne resilver-prosessen fullføres vellykket – dette tar vanligvis mange timer og kan lett ta dager og muligens uker eller måneder avhengig av størrelsen på arrayen og hvor opptatt arrayen er. Hvis vi tok den samme warm spare-disken og i stedet ga den i oppgave å være et medlem av arrayen med en ekstra paritetsstribe, ville vi oppnå RAID 6. Det samme settet med disker som vi har for RAID 5 pluss warm spare ville skape en RAID 6-array av nøyaktig samme kapasitet. Igjen, som i RAID 1-eksempelet ovenfor, ville dette ligne mye på å ha en hot spare, der disken deltar i arrayen med live-data i stedet for å sitte passivt og vente på at en annen disk svikter før den starter prosessen med å overta. I denne kapasiteten degraderes arrayen til RAID 5-ekvivalent ved feil, men uten noen gjenoppbyggingstid, så den ekstra disken er nyttig umiddelbart i stedet for først etter en muligens svært langvarig resilver-prosess. Så for de samme pengene og den samme kapasiteten er valget om å sette opp diskene i RAID 6 i stedet for RAID 5 pluss warm spare en fullstendig seier.

Vi kan fortsette dette eksempelet med RAID 6 pluss warm spare. Denne er litt vanskeligere å definere fordi det i de fleste RAID-systemer, bortsett fra det noe uvanlige RAIDZ3 fra ZFS, ikke finnes et trippel-paritetssystem tilgjengelig ett steg over RAID 6 (tenk deg om det fantes en RAID 7, for eksempel). Hvis det hadde eksistert, ville det eksakte argumentet som ble fremhevet for RAID 5 pluss warm spare gjelde for RAID 6 pluss warm spare. I de fleste tilfeller må RAID 6 med warm spare rettferdiggjøre seg mot en RAID 10-array. RAID 10 er mer ytelsesfullt og langt mer pålitelig enn en RAID 6-array, men RAID 6 velges generelt for å spare penger sammenlignet med RAID 10. Men for å motvirke RAID 6s skjørhet brukes noen ganger warm spares. I noen tilfeller, som en liten fem-disk RAID 6-array med en warm spare, er dette krone for krone ekvivalent med en seks-disk RAID 10-array uten warm spare. I større arrayer blir kostnadsfordelen med RAID 6 mer tydelig, men jo større kostnadsbesparelsen er, desto større er risikoforskjellen, ettersom paritet-RAID-systemer øker risikoen med arraystørrelse mye raskere enn spelingbaserte RAID-systemer som RAID 10. Penger spart i dag gjøres til prisen av driftsavbrudd eller datatap i morgen.

Der en warm spare fungerer effektivt er i en RAID 10-array der en warm spare-gjenoppbygging er en speil-gjenoppbygging, som i RAID 1, som ikke medfører paritetsrisiko, der det ikke finnes noe logisk utvidet RAID-system over RAID 10 som vi prøver å spare penger ved å gå med et mer skjørt system. Her kan det gi mening å legge til en warm spare for kritiske arrayer fordi det ikke finnes noen mer kostnadseffektiv måte å oppnå den samme ekstra påliteligheten på. RAID 10 er imidlertid så pålitelig uten en warm spare at enhver bedrift som vurderer RAID 5 eller RAID 6 med warm spare logisk sett ville stoppe ved enkelt RAID 10 og allerede ha overskredet den påliteligheten de tidligere hadde vurdert å nøye seg med. Så bare bedrifter som ikke vurderer disse mer skjøre systemene og som søker den mest robuste mulige løsningen, ville logisk sett se på RAID 10 pluss warm spare som sin løsning.

For teknisk nøyaktighet kan RAID 10 utvides for bedre leseytelse og dramatisk forbedring i pålitelighet (men med en femti prosent kostnadsøkning) ved å gå over til tre-disk RAID 1-speil i RAID 0-stripen i stedet for standard to-disk RAID 1-speil, akkurat som vi viste i RAID 1-eksempelet vårt. Dette er et pålitelighetsnivå som sjelden søkes i den virkelige verden, men det kan eksistere og er et alternativ. Normalt begrenses dette av antall disker i fysiske array-kabinetter samt at det konkurrerer dårlig mot å bygge en helt separat sekundær RAID 10-array i et annet kabinett og deretter speile disse på et høyt nivå, noe som effektivt skaper RAID 101 – som er det effektive resultatet av vanlige, høykvalitets lagringsarray-klynger i dag.

Vår andre bekymring er “automatisk arrayødeleggelse.” Dette gjelder kun for paritet-RAID-scenariene med RAID 5 og RAID 6 (eller de sjeldne RAID 2, RAID 3, RAID 4 og RAIDZ3). Med warm spare-konseptet er ideen at når en disk svikter, byttes warm spare automatisk og umiddelbart inn av array-kontrolleren og prosessen med å resilver arrayen begynner umiddelbart. Hvis resilvering var en fullstendig pålitelig prosess, ville dette åpenbart være svært velkommen. Virkeligheten er dessverre ganske annerledes.

Under en resilver-prosess er en paritet-RAID-array utsatt for Unrecoverable Read Errors (UREs). Hvis en URE oppstår under en enkelt-paritet RAID resilver (det vil si RAID 2–5), mislykkes resilver-prosessen og arrayen går tapt fullstendig. Dette er kritisk å forstå fordi ingen ekstra disk har sviktet. Så hvis warm spare ikke hadde vært til stede, ville resilvering ikke ha begynt og dataene ville fortsatt vært intakte og tilgjengelige – bare ikke like raskt som vanlig og med en liten risiko for sekundær diskfeil. URE-rater er svært høye med dagens store disker, og med store arrayer kan risikoen bli så høy at den beveger seg fra “mulig” til “forventet” under en standard resilver-operasjon.

Så i mange tilfeller kan warm spare selv faktisk være utløseren for datatap i stedet for reddingen av data som forventet. En array som ville ha overlevd kan bli ødelagt av resilver-prosessen før mennesket som administrerer den engang er blitt varslet om at den første disken har sviktet. Hadde et menneske vært involvert, kunne de i det minste ha tatt steget med å ta en fersk sikkerhetskopi av arrayen før de startet resilvering, i visshet om at den siste kopien av dataene ville vært tilgjengelig i tilfelle resilver-prosessen mislyktes. Det ville også tillatt mennesket å planlegge når resilvering skulle begynne, muligens vente til arbeidstiden er over eller helgen har begynt når arrayen er mindre belastet.

Dobbel og trippel paritet RAID (henholdsvis RAID 6 og RAIDZ3) deler URE-risiko ettersom de også er basert på paritet. De reduserer denne risikoen gjennom de ekstra nivåene av paritet og gjør dette vellykket for det meste. Risikoen eksisterer fortsatt, spesielt i svært store RAID 6-arrayer, men i de neste årene forblir risikoen generelt ganske lav for de fleste lagringsarrayer inntil langt større spindel-baserte lagringsmedier er tilgjengelige på markedet.

Det største problemet med paritet-RAID og URE-risiko er at drivkraften mot paritet-RAID (vilje til å møte ekstra dataintegritetsrisiko for å senke kostnadene) er den samme drivkraften som introduserer økt URE-risiko (kjøp av rimelige, ikke-enterprise SATA harddisker). Bedrifter som bruker paritet-RAID gjør det generelt med store, rimelige SATA-disker og bringer to svært farlige faktorer sammen for en eksplosiv kombinasjon. Bruk av ikke-paritet RAID 1 eller RAID 10 vil fullstendig eliminere problemet, og bruk av svært pålitelige enterprise SAS-disker vil drastisk redusere risikofaktoren med én størrelsesorden (ikke et uttrykk, det er faktisk en endring på én størrelsesorden).

I tillegg er det mulig under resilver-operasjoner at ytelsen degraderes på paritetssystemer så drastisk at det tilsvarer et langvarig driftsavbrudd. Resilver-prosessen, spesielt på store arrayer, kan være så intensiv at sluttbrukere ikke kan skille mellom en fullstendig sviktet array og en resilverende array. Faktisk kan resilvering i ekstreme tilfeller ta så lang tid og være så forstyrrende at kostnaden for virksomheten kan være høyere enn om arrayen rett og slett hadde sviktet fullstendig og en gjenoppretting fra sikkerhetskopi hadde blitt gjort i stedet. Dette resilver-problemet påvirker ikke RAID 1 og RAID 10, igjen, fordi de er speil-baserte, ikke paritet-baserte RAID-systemer, og resilver-prosessen er triviell og ytelsesdegraderingen av systemet er minimal og kortvarig. I ekstreme tilfeller kan paritet-resilvering ta uker eller måneder der systemene oppfører seg som om de er offline – og på ethvert tidspunkt i denne prosessen er det potensial for at URE-feil kan oppstå som nevnt ovenfor, noe som ville avslutte resilvering og tvinge gjenoppretting fra sikkerhetskopi uansett. (Typiske resilver-operasjoner tar ikke uker, men tar mange timer, og å ta dager er slett ikke uvanlig.)

Vår endelige oversikt kan brytes ned til følgende (konvensjonell term “hot spare” brukt igjen): RAID 10 uten “hot spare” er nesten alltid et bedre valg enn RAID 6 med “hot spare.” RAID 6 uten “hot spare” er alltid bedre enn RAID 5 med “hot spare.” RAID 1 med ekstra speilmedlem er alltid bedre enn RAID 1 med “hot spare.” Så uansett hvilket RAID-nivå med hot spare du bestemmer deg for, flytt rett og slett ett nivå opp i RAID-pålitelighet og dropp “hot spare” for å maksimere både ytelse og pålitelighet til lik eller nesten lik kostnad.

Warm spares, som paritet-RAID, hadde sin tid i solen. Faktisk var det da paritet-RAID fortsatt ga mening for utbredt bruk – da URE-feil var usannsynlige og diskkostnadene var høye – at warm spare-disker ga mening i tillegg. De var godt kombinert; når det ene ga mening, gjorde det andre det ofte også. Det som ofte overses er at etter hvert som paritet-RAID, spesielt RAID 5, har mistet effektivitet, har det trukket warm spare med seg på uventede måter.