Hot Spare eller et varmt rod

En almindelig tilgang til at tilføje et ekstra sikkerhedslag til RAID er at have reservedrev til rådighed, så udskiftningstiden for et defekt drev minimeres. Den mest ekstreme form for dette omtales som at have et “hot spare” – et reservedrev, der sidder i arrayet men er ubrugt, indtil arrayet opdager et drevfejl, hvorefter systemet automatisk deaktiverer det fejlede drev og aktiverer hot spare'en, præcis som hvis en person blot havde taget det ene drev ud af arrayet og sat det andet i, så en resilver-operation (genopbygning af arrayet) kan begynde hurtigst muligt. Dette kan reducere udskiftningstiden fra timer eller dage til sekunder og kan i teorien give en ekstrem forbedring af sikkerheden.

Først vil jeg gerne adressere det, jeg personligt opfatter som en fejl i navnekonventionerne. Det, vi kalder et hot spare, bør efter min mening faktisk kaldes et warm spare, fordi det sidder klar, men ikke indeholder de nødvendige data til at træde ind med det samme. Et reservedrev opbevaret uden for chassiset, som kræver menneskelig indgriben til at bytte drevene manuelt, ville være et cold spare. For virkelig at være et hot spare bør et drev være fyldt med data og dermed fungere som aktivt medlem af RAID-arrayet på en eller anden måde. Red Hat har en god artikel om, hvordan denne terminologi anvendes i forbindelse med disaster recovery-sites som reference. Denne sondring er vigtig, fordi det, vi kalder et hot spare, ikke allerede indeholder data og ikke umiddelbart træder ind og erstatter det defekte drev, men i stedet straks begynder processen med at gendanne det tabte drev – en afgørende forskel.

For at holde begreberne klare vil jeg herefter omtale det, som leverandører kalder hot spares, som “warm spares.” Dette vil give mening om lidt.

Der er to primære bekymringer ved warm spares. Den første er warm spare'ens ineffektive natur i de fleste brugsscenarier, og den anden er risikoen for “automatisk array-destruktion.”

De fleste mennesker ser warm spare-konceptet som et middel til at afbøde den høje risiko for sekundær drevfejl på et paritetsbåret RAID 5-array. RAID 5-arrays beskytter kun mod fejl på én enkelt disk i arrayet. Når én disk er fejlet, er arrayet uden nogen form for paritet, og enhver yderligere drevfejl medfører totalt tab af arrayet. RAID 5 vælges, fordi det er meget billigt for den givne kapacitet og ofrer pålidelighed for at opnå denne omkostningseffektivitet. Fordi RAID 5 er risikabelt i sammenligning med andre RAID-muligheder, såsom RAID 6 eller RAID 10, er det almindeligt at implementere et warm spare for at minimere den tid, arrayet befinder sig i en forringet tilstand, så arrayet kan begynde at resilvere sig selv så hurtigt som muligt.

Konklusionen her, som er mere relevant, er, at warm spares generelt bruges som buffer mod at anvende mindre pålidelige RAID-arraytyper som en omkostningsbesparende foranstaltning. Warm spares er langt mere udbredte i RAID 5-arrays efterfulgt af RAID 6-arrays, som begge vælges frem for RAID 10 på grund af pris pr. kapacitet, ikke pålidelighed eller ydeevne. Der er ét tilfælde, hvor warm spare-ideen virkelig giver mening for øget pålidelighed, og det er RAID 10 med et warm spare, men det vender vi tilbage til. Uden for det scenarie mener jeg, at warm spares giver ringe mening i den virkelige verden.

Vi starter med at undersøge RAID 1 med et warm spare. RAID 1 består af to eller flere drev i et spejl. Det er fint at tilføje et warm spare, fordi hvis et af de spejlede par fejler, vil warm spare'en straks begynde at spejle det resterende drev, og man er hurtigt beskyttet igen. Det er vidunderligt. Bortset fra én mindre fejl: I stedet for at bruge et warm spare kunne det samme drev have været tilføjet RAID 1-arrayet hele tiden, hvor det ville have fungeret som et tertiært spejl. I denne tertiære spejlkapacitet ville drevet have bidraget til arrayets samlede ydeevne med en næsten halvtreds procent forbedring af læseydeevnen, mens skriveydeevnen forblev uændret, og levere øjeblikkelig beskyttelse i tilfælde af drevfejl snarere end beskyttelse “så snart det har spejlet igen.” Det ville i bund og grund have været et ægte “hot spare” snarere end et warm spare. Så uden at bruge en eneste ekstra krone ville systemet have haft bedre array-ydeevne og bedre pålidelighed ved blot at have det ekstra drev i aktiv kapacitet i arrayet frem for at sidde varmt og inaktivt og vente på, at katastrofen indtræffer.

Med RAID 5 ser vi en endnu mere dramatisk advarsel mod warm spare-konceptet, her hvor det er mere udbredt end noget andet sted. RAID 5 er enkelt-paritets-RAID med mulighed for at genopbygge, ved hjælp af paritet, ethvert drev i arrayet, der fejler. Det er her de reelle problemer begynder. I modsætning til RAID 1, hvor en genspegling kan være ganske hurtig, kan en RAID 5-resilver (genopbygning) tage ganske lang tid. Warm spare'en vil ikke hjælpe med at beskytte arrayet, før denne resilver-proces fuldføres – det tager ofte mange timer, let dage og muligvis uger eller måneder afhængigt af arrayets størrelse og belastning. Hvis vi tog det samme warm spare-drev og i stedet lod det være medlem af arrayet med en ekstra paritetsstribe, ville vi opnå RAID 6. Det samme sæt drev, som vi har til RAID 5 plus warm spare, ville skabe et RAID 6-array med præcis samme kapacitet. Igen, ligesom RAID 1-eksemplet ovenfor, ville dette svare til at have et hot spare, hvor drevet deltager i arrayet med live-data frem for at sidde inaktivt og vente på, at et andet drev fejler, før det træder til og begynder at overtage. I denne kapacitet forringes arrayet til et RAID 5-ækvivalent ved fejl, men uden nogen genopbygningstid, så det ekstra drev er nyttigt med det samme frem for kun efter en muligvis meget langvarig resilver-proces. Så for de samme penge og samme kapacitet er valget om at konfigurere drevene i RAID 6 frem for RAID 5 plus warm spare en fuldstændig gevinst.

Vi kan fortsætte dette eksempel med RAID 6 plus warm spare. Dette er lidt sværere at definere, fordi der i de fleste RAID-systemer, undtagen det noget sjældne RAIDZ3 fra ZFS, ikke er noget triple-paritetssystem tilgængeligt ét trin over RAID 6 (forestil dig, hvis der fandtes et RAID 7). Hvis det var tilfældet, ville det præcise argument fra RAID 5 plus warm spare gælde for RAID 6 plus warm spare. I de fleste tilfælde skal RAID 6 med et warm spare retfærdiggøres over for et RAID 10-array. RAID 10 er mere ydelsesdygtig og langt mere pålidelig end et RAID 6-array, men RAID 6 vælges generelt for at spare penge sammenlignet med RAID 10. Men for at afbøde RAID 6’s skrøbelighed anvendes warm spares nogle gange. I visse tilfælde, som et lille fem-disk RAID 6-array med et warm spare, er dette dollar for dollar ækvivalent med et seks-disk RAID 10-array uden et warm spare. I større arrays bliver omkostningsfordelen ved RAID 6 tydelig, men jo større omkostningsbesparelsen er, jo større er risikoforskellen, da paritetsbårede RAID-systemer øger risikoen med arrayets størrelse meget hurtigere end spejlbaserede RAID-systemer som RAID 10. Enhver penge sparet i dag sker på bekostning af risikoen for nedbrud eller datatab i morgen.

Hvor et warm spare er effektivt, er i et RAID 10-array, hvor en warm spare-genopbygning er en spejlgenopbygning, som i RAID 1, der ikke bærer paritetstræk, og hvor der ikke er et logisk udvidet RAID-system over RAID 10, som vi forsøger at spare penge fra ved at gå med et mere skrøbeligt system. Her kan tilføjelse af et warm spare give mening for kritiske arrays, fordi der ikke er en mere omkostningseffektiv måde at opnå samme ekstra pålidelighed på. RAID 10 er imidlertid så pålidelig uden et warm spare, at enhver virksomhed, der overvejer RAID 5 eller RAID 6 med et warm spare, logisk set ville stoppe ved simpelt RAID 10, efter allerede at have overskredet den pålidelighed, de tidligere overvejede at nøjes med. Så kun virksomheder, der ikke overvejer disse mere skrøbelige systemer og ønsker den mest robuste mulige løsning, ville logisk set kigge på RAID 10 plus warm spare som deres løsning.

Blot for teknisk nøjagtighed kan RAID 10 udvides for bedre læseydeevne og dramatisk forbedret pålidelighed (men med en halvtreds procent omkostningsstigning) ved at flytte til tre-disk RAID 1-spejle i sin RAID 0-stribe frem for standard to-disk RAID 1-spejle, ligesom vi viste i vores RAID 1-eksempel. Dette er et pålidelelighedsniveau, der sjældent efterspørges i den virkelige verden, men det kan eksistere og er en mulighed. Normalt begrænses dette af drevtællingsbegrænsninger i fysiske array-chassiser samt ved at konkurrere dårligt med at bygge et helt separat sekundært RAID 10-array i et andet chassis og derefter spejle disse på højt niveau, hvilket effektivt skaber RAID 101 – som er det effektive resultat af almindelige, high-end storage array-klynger i dag.

Vores anden bekymring er “automatisk array-destruktion.” Dette gælder kun for paritetsbårede RAID-scenarier med RAID 5 og RAID 6 (eller det sjældne RAID 2, RAID 3, RAID 4 og RAIDZ3). Med warm spare-konceptet er ideen, at når et drev fejler, indsættes warm spare'en automatisk og øjeblikkeligt af array-controlleren, og processen med at resilvere arrayet begynder straks. Hvis resilvering var en fuldstændig pålidelig proces, ville dette åbenlyst være meget velkommen. Virkeligheden er desværre ganske anderledes.

Under en resilver-proces er et paritetsbåret RAID-array i fare for Unrecoverable Read Errors (URE'er). Hvis en URE opstår i en enkelt-paritets-RAID-resilver (dvs. RAID 2 – 5), mislykkes resilver-processen, og arrayet går tabt fuldstændigt. Dette er afgørende at forstå, fordi intet yderligere drev er fejlet. Så hvis warm spare'en ikke havde været til stede, ville resilvering ikke have startet, og dataene ville stadig være intakte og tilgængelige – blot ikke så hurtigt som normalt og med en lille risiko for sekundær drevfejl. URE-rater er meget høje med nutidens store drev, og med store arrays kan risiciene blive så høje, at de bevæger sig fra “mulige” til “forventede” under en standard resilver-operation.

Så i mange tilfælde kan warm spare'en selv faktisk være udløseren for datatab snarere end dataens redder som forventet. Et array, der ville have overlevet, kan blive ødelagt af resilver-processen, inden den administrator, der administrerer det, overhovedet bliver adviseret om, at det første drev er fejlet. Hvis et menneske var involveret, kunne de som minimum have taget skridt til at tage en frisk backup af arrayet, inden resilvering startede, vel vidende at den seneste kopi af dataene ville være tilgængelig, hvis resilver-processen mislykkedes. Det ville også give mulighed for at planlægge, hvornår resilvering skal starte – muligvis vente til efter arbejdstid eller weekenden er begyndt, når arrayet er mindre udsat for høj belastning.

Dual- og triple-paritetsbåret RAID (henholdsvis RAID 6 og RAIDZ3) deler URE-risici, da de også er baseret på paritet. De afbøder denne risiko gennem de ekstra paritetsniveauer og gør det for det meste med succes. Risikoen eksisterer stadig, især i meget store RAID 6-arrays, men i de kommende år forbliver risiciene generelt ret lave for de fleste storage-arrays, indtil langt større spindelbaserede lagringsmedier er tilgængelige på markedet.

Det største problem med paritetsbåret RAID og URE-risikoen er, at drivkraften bag paritetsbåret RAID (vilje til at stå over for yderligere dataintegritetsrisici for at sænke omkostningerne) er den samme drivkraft, der introducerer forhøjet URE-risiko (køb af lavpris, ikke-enterprise SATA-harddiske). Virksomheder, der vælger paritetsbåret RAID, gør det generelt med store, billige SATA-drev, hvilket bringer to meget farlige faktorer sammen til en eksplosiv kombination. Brug af ikke-paritetsbaseret RAID 1 eller RAID 10 vil fuldstændig eliminere problemet, og brug af meget pålidelige enterprise SAS-drev vil drastisk reducere risikofaktoren med en størrelsesorden (ikke et udtryk, det er faktisk en ændring på én størrelsesorden).

Desuden er det under resilver-operationer muligt for ydeevnen at falde på paritetsbaserede systemer så drastisk, at det svarer til et langvarigt nedbrud. Resilver-processen, især på store arrays, kan være så intensiv, at slutbrugere ikke kan skelne mellem et fuldstændig fejlet array og et resilverende array. Faktisk kan resilvering i ekstreme tilfælde tage så lang tid og være så forstyrrende, at omkostningerne for virksomheden kan være højere, end hvis arrayet simpelthen var fejlet fuldstændigt og en gendannelse fra backup var blevet udført i stedet. Dette resilver-problem påvirker ikke RAID 1 og RAID 10, igen fordi de er spejlede, ikke paritetsbårede, RAID-systemer, og deres resilver-proces er triviel, og systemets ydeevneforringelse er minimal og kortvarig. I det mest ekstreme tilfælde kan en paritetsresilver tage uger eller måneder, i løbet af hvilken tid systemerne opfører sig, som om de er offline – og på ethvert tidspunkt i denne proces er der potentiale for, at URE-fejl opstår som nævnt ovenfor, hvilket ville afslutte resilvering og tvinge en gendannelse fra backup alligevel. (Typiske resilver-operationer tager ikke uger, men tager mange timer, og det er langt fra ualmindeligt, at de tager dage.)

Vores afsluttende overblik kan koges ned til følgende (med den konventionelle betegnelse “hot spare” brugt igen): RAID 10 uden et “hot spare” er næsten altid et bedre valg end RAID 6 med et “hot spare.” RAID 6 uden et “hot spare” er altid bedre end RAID 5 med et “hot spare.” RAID 1 med yderligere spejlmedlem er altid bedre end RAID 1 med et “hot spare.” Så uanset hvilket RAID-niveau med et hot spare du beslutter dig for, skal du blot rykke ét niveau op i RAID-pålidelighed og droppe “hot spare'en” for at maksimere både ydeevne og pålidelighed til samme eller næsten samme pris.

Warm spares havde, ligesom paritetsbåret RAID, deres storhedstid. Det var faktisk, da paritetsbåret RAID stadig gav mening til udbredt brug – da URE-fejl var usandsynlige og diskpriser var høje – at warm spare-drev også gav mening. De var godt parrede: Når den ene gav mening, gjorde den anden det ofte også. Det, der ofte overses, er, at efterhånden som paritetsbåret RAID, især RAID 5, har mistet effektivitet, har det trukket warm spare'en med sig på uventede måder.