Hot Spare of een Hete Brij

Een veelgebruikte aanpak om een laag veiligheid aan RAID toe te voegen is het beschikbaar hebben van reserveschijf/-schijven zodat de vervangingstijd voor een defecte schijf tot een minimum wordt beperkt. De meest extreme vorm hiervan wordt aangeduid als het hebben van een “hot spare” – een reserveschijf die zich daadwerkelijk in de array bevindt maar ongebruikt blijft totdat de array een schijfdefect detecteert, op welk moment het systeem automatisch de defecte schijf uitschakelt en de hot spare inschakelt, net alsof een mens zojuist de ene schijf uit de array had gehaald en de andere erin had geplaatst, waardoor een resilver-operatie (een heropbouw van de array) zo snel mogelijk kan beginnen. Dit kan de tijd om een nieuwe schijf in te wisselen terugbrengen van uren of dagen naar seconden en kan in theorie een extreme toename in veiligheid bieden.

Ten eerste wil ik ingaan op wat ik persoonlijk als een fout in de naamgevingsconventies beschouw. Wat wij een hot spare noemen zou volgens mij eigenlijk een warm spare moeten heten, omdat hij klaarstaat om te gebruiken maar niet de noodzakelijke gegevens bevat om onmiddellijk te worden ingezet. Een reserveschijf die buiten de behuizing wordt bewaard, een die vereist dat een mens ingrijpt en de schijven handmatig verwisselt, zou een cold spare zijn. Om werkelijk een hot spare te zijn zou een schijf vol met gegevens moeten staan en zou hij daarom in zekere mate een deelnemend lid van de RAID-array zijn. Red Hat heeft een goed artikel over hoe deze terminologie van toepassing is op disaster recovery-sites ter referentie. Dit onderscheid is belangrijk omdat wat wij een hot spare noemen niet al gegevens bevat en niet onmiddellijk de defecte schijf vervangt, maar in plaats daarvan inspringt om onmiddellijk het proces te beginnen van het herstellen van de verloren schijf – een cruciaal onderscheid.

Om de concepten helder te houden zal ik vanaf hier wat leveranciers hot spares noemen aanduiden als “warm spares.” Dit zal binnenkort logisch worden.

Er zijn twee voornaamste zorgen rondom warm spares. De eerste is de ineffectieve aard van de warm spare in de meeste gebruiksscenario’s en de tweede is het risico van “geautomatiseerde array-vernietiging.”

De meeste mensen benaderen het warm spare-concept als een middel om het hoge risico op een secundair schijfdefect op een pariteits-RAID 5-array te beperken. RAID 5-arrays beschermen alleen tegen het defect raken van een enkele schijf binnen de array. Zodra een enkele schijf defect is geraakt blijft de array zonder enige vorm van pariteit achter en resulteert elk aanvullend schijfdefect in het volledige verlies van de array. RAID 5 wordt gekozen omdat het zeer lage kosten kent voor de gegeven capaciteit en betrouwbaarheid opoffert om deze kostenefficiëntie te bereiken. Omdat RAID 5 daarom riskant is in vergelijking met andere RAID-opties, zoals RAID 6 of RAID 10, is het gebruikelijk om een warm spare te implementeren teneinde de tijd dat de array in een gedegradeerde staat verkeert tot een minimum te beperken, zodat de array zichzelf zo snel mogelijk kan beginnen te resilveren.

De relevantere conclusie hier is dus dat warm spares over het algemeen worden gebruikt als buffer tegen het gebruik van minder betrouwbare RAID-arraytypen als kostenbesparende maatregel. Warm spares zijn aanzienlijk gebruikelijker in RAID 5-arrays, gevolgd door RAID 6-arrays. Beide worden boven RAID 10 gekozen vanwege kosten per capaciteit, niet vanwege betrouwbaarheid of prestaties. Er is één geval waarin het warm spare-idee werkelijk zinvol is voor toegevoegde betrouwbaarheid, en dat is RAID 10 met een warm spare, maar daar komen we nog op. Buiten dat scenario vind ik dat warm spares weinig zin hebben in de praktijk.

We beginnen met het onderzoeken van RAID 1 met een warm spare. RAID 1 bestaat uit twee schijven, of meer, in een mirror. Een warm spare toevoegen is fijn in die zin dat als een van de gespiegelde paren defect raakt, de warm spare onmiddellijk begint met het spiegelen van de resterende schijf en u binnen korte tijd weer beschermd bent. Dat is prachtig. Op één klein gebrek na: in plaats van een warm spare te gebruiken had diezelfde schijf van meet af aan aan de RAID 1-array toegevoegd kunnen worden, waar hij als tertiaire mirror zou hebben gefungeerd. In deze tertiaire mirror-hoedanigheid zou de schijf hebben bijgedragen aan de algehele prestaties van de array, met een leesprestatieverbetering van bijna vijftig procent terwijl de schrijfprestaties gelijk bleven, en zou hij onmiddellijke bescherming hebben geboden in geval van een schijfdefect in plaats van “zodra hij opnieuw gespiegeld is”-bescherming. In feite zou het een echte “hot spare” zijn geweest in plaats van een warm spare. Dus zonder ook maar een cent meer uit te geven zou het systeem betere schijfarrayprestaties en betere betrouwbaarheid hebben gehad, simpelweg door de extra schijf in een hete “in de array”-hoedanigheid te hebben in plaats van warm en stil te laten wachten tot de ramp toeslaat.

Bij RAID 5 zien we een nog dramatischere waarschuwing tegen het warm spare-concept, juist hier waar het gebruikelijker is dan waar dan ook. RAID 5 is enkelvoudige-pariteits-RAID met de mogelijkheid om, met behulp van de pariteit, elke schijf in de array die defect raakt opnieuw op te bouwen. Hier beginnen de echte problemen. Anders dan bij RAID 1, waar een herspiegeloperatie behoorlijk snel kan zijn, heeft een RAID 5-resilver (heropbouw) het vermogen om behoorlijk lang te duren. De warm spare zal niet helpen bij het beschermen van de array totdat dit resilverproces succesvol is voltooid – dit duurt doorgaans vele uren en gemakkelijk dagen en mogelijk weken of maanden, afhankelijk van de grootte van de array en hoe druk de array is. Als we diezelfde warm spare-schijf zouden nemen en hem in plaats daarvan de taak zouden geven lid te zijn van de array met een aanvullende pariteitsstripe, dan zouden we RAID 6 bereiken. Dezelfde set schijven die we voor RAID 5 plus warm spare hebben zou een RAID 6-array van exact dezelfde capaciteit creëren. Net als in het RAID 1-voorbeeld hierboven zou dit veel lijken op het hebben van een hot spare, waarbij de schijf deelneemt aan de array met actieve gegevens in plaats van stil te wachten tot een andere schijf defect raakt voordat hij ingrijpt om het proces van overname te beginnen. In deze hoedanigheid degradeert de array tot een RAID 5-equivalent in geval van een defect, maar zonder enige heropbouwtijd, dus de aanvullende schijf is onmiddellijk nuttig in plaats van pas na een mogelijk zeer langdurig resilverproces. Dus voor hetzelfde geld, dezelfde capaciteit, is de keuze om de schijven in RAID 6 op te zetten in plaats van RAID 5 plus warm spare een volledige overwinning.

We kunnen dit voorbeeld voortzetten met RAID 6 plus warm spare. Deze is iets minder gemakkelijk te definiëren, omdat er in de meeste RAID-systemen, met uitzondering van het enigszins ongebruikelijke RAIDZ3 van ZFS, geen drievoudig-pariteitssysteem beschikbaar is dat één stap boven RAID 6 staat (stel je voor dat er bijvoorbeeld een RAID 7 zou bestaan.) Als dat zo was, zou exact het argument dat voor RAID 5 plus warm spare werd gemaakt van toepassing zijn op RAID 6 plus warm spare. In de meerderheid van de gevallen moet RAID 6 met een warm spare zich verantwoorden tegenover een RAID 10-array. RAID 10 is performanter en veel betrouwbaarder dan een RAID 6-array, maar RAID 6 wordt over het algemeen gekozen om geld te besparen ten opzichte van RAID 10. Maar om de kwetsbaarheid van RAID 6 te compenseren worden soms warm spares ingezet. In sommige gevallen, zoals een kleine RAID 6-array van vijf schijven met een warm spare, is dit dollar voor dollar equivalent aan een RAID 10-array van zes schijven zonder warm spare. In grotere arrays wordt het kostenvoordeel van RAID 6 wel duidelijk, maar hoe groter de kostenbesparing, hoe groter het risicoverschil, aangezien pariteits-RAID-systemen het risico veel sneller met de arraygrootte verhogen dan op mirroring gebaseerde RAID-systemen zoals RAID 10. Elk bedrag dat vandaag wordt bespaard gebeurt met het risico op uitval of gegevensverlies morgen.

Waar een warm spare effectief van pas komt is in een RAID 10-array waar een warm spare-heropbouw een mirror-heropbouw is, zoals bij RAID 1, die geen pariteitsrisico’s met zich meebrengt, waar er geen logisch uitbreidings-RAID-systeem boven RAID 10 bestaat waarop we geld proberen te besparen door voor een kwetsbaarder systeem te kiezen. Hier kan het toevoegen van een warm spare zinvol zijn voor kritieke arrays, omdat er geen kostenefficiëntere manier is om dezelfde aanvullende betrouwbaarheid te verkrijgen. RAID 10 is echter zo betrouwbaar zonder warm spare dat elke onderneming die RAID 5 of RAID 6 met een warm spare overweegt logischerwijs bij eenvoudige RAID 10 zou stoppen, aangezien deze de betrouwbaarheid die zij eerder overwogen te accepteren al heeft overtroffen. Dus alleen ondernemingen die die kwetsbaardere systemen niet overwegen en op zoek zijn naar de meest robuuste mogelijke optie zouden logischerwijs naar RAID 10 plus warm spare kijken als hun oplossing.

Uitsluitend voor technische nauwkeurigheid: RAID 10 kan worden uitgebreid voor betere leesprestaties en een dramatische verbetering in betrouwbaarheid (maar met een kostenstijging van vijftig procent) door over te stappen op RAID 1-mirrors van drie schijven in zijn RAID 0-stripe in plaats van standaard RAID 1-mirrors van twee schijven, net zoals we in ons RAID 1-voorbeeld lieten zien. Dit is een niveau van betrouwbaarheid dat in de praktijk zelden wordt nagestreefd maar kan bestaan en is een optie. Normaal gesproken wordt dit beperkt door beperkingen in het aantal schijven in fysieke arraybehuizingen en doordat het slecht concurreert met het bouwen van een volledig aparte secundaire RAID 10-array in een andere behuizing en deze vervolgens op hoog niveau te spiegelen, waarmee effectief RAID 101 wordt gecreëerd – wat het effectieve resultaat is van veelvoorkomende, high-end opslagarrayclusters van vandaag.

Onze tweede zorg is die van “geautomatiseerde array-vernietiging.” Dit is alleen van toepassing op de pariteits-RAID-scenario’s van RAID 5 en RAID 6 (of het zeldzame RAID 2, RAID 3, RAID 4 en RAIDZ3.) Bij het warm spare-concept is het idee dat wanneer een schijf defect raakt de warm spare automatisch en onmiddellijk door de arraycontroller wordt ingewisseld en het proces van het resilveren van de array onmiddellijk begint. Als resilveren een volledig betrouwbaar proces was, zou dit uiteraard zeer welkom zijn. De realiteit is helaas heel anders.

Tijdens een resilverproces loopt een pariteits-RAID-array het risico dat er Unrecoverable Read Errors (UREs) opduiken. Als er een URE optreedt tijdens een enkelvoudige-pariteits-RAID-resilver (dat wil zeggen RAID 2 – 5), dan mislukt het resilverproces en is de array volledig verloren. Dit is cruciaal om te begrijpen omdat er geen aanvullende schijf defect is geraakt. Dus als de warm spare niet aanwezig was geweest, zou het resilveren niet zijn begonnen en zouden de gegevens nog intact en beschikbaar zijn – alleen niet zo snel als gebruikelijk en met het kleine risico van een secundair schijfdefect. URE-percentages zijn zeer hoog met de grote schijven van vandaag, en bij grote arrays kunnen de risico’s zo hoog worden dat ze tijdens een standaard resilveroperatie van “mogelijk” naar “verwacht” verschuiven.

Dus in veel gevallen kan de warm spare zelf eigenlijk de aanleiding zijn voor het verlies van gegevens in plaats van de redder van de gegevens zoals verwacht. Een array die het overleefd zou hebben kan door het resilverproces worden vernietigd voordat de mens die hem beheert zelfs maar wordt gewaarschuwd dat de eerste schijf defect is geraakt. Was er een mens bij betrokken geweest, dan hadden zij op zijn minst de stap kunnen nemen om een verse back-up van de array te maken voordat het resilveren werd gestart, wetende dat de nieuwste kopie van de gegevens beschikbaar zou zijn voor het geval het resilverproces mislukte. Het zou de mens ook in staat stellen te plannen wanneer het resilveren zou moeten beginnen, mogelijk wachtend tot de kantooruren voorbij zijn of het weekend is aangebroken, wanneer de array minder snel een zware belasting zal ondervinden.

Dubbele- en drievoudige-pariteits-RAID (respectievelijk RAID 6 en RAIDZ3) delen eveneens URE-risico’s, aangezien ook zij op pariteit zijn gebaseerd. Zij beperken dit risico via de aanvullende niveaus van pariteit en doen dit grotendeels succesvol. Het risico bestaat nog steeds, vooral in zeer grote RAID 6-arrays, maar de komende jaren blijven de risico’s over het algemeen vrij laag voor de meerderheid van de opslagarrays, totdat er veel grotere spindel-gebaseerde opslagmedia op de markt beschikbaar zijn.

Het grootste probleem met pariteits-RAID en het URE-risico is dat de drijfveer richting pariteits-RAID (bereid om aanvullende risico’s voor de gegevensintegriteit aan te gaan teneinde kosten te verlagen) dezelfde drijfveer is die een verhoogd URE-risico introduceert (de aanschaf van goedkopere, niet-enterprise SATA-harde schijven.) Ondernemingen die voor pariteits-RAID staan doen dit over het algemeen met grote, goedkope SATA-schijven, waarmee twee zeer gevaarlijke factoren samenkomen tot een explosieve combinatie. Het gebruik van niet-pariteits-RAID 1 of RAID 10 zal het probleem volledig elimineren, en het gebruik van zeer betrouwbare enterprise-SAS-schijven zal de risicofactor drastisch verminderen met een orde van grootte (geen uitdrukking, het is daadwerkelijk een verandering van één orde van grootte.)

Daarnaast is het tijdens resilveroperaties mogelijk dat de prestaties op pariteitssystemen zo drastisch verslechteren dat het neerkomt op een langdurige uitval. Het resilverproces, vooral op grote arrays, kan zo intensief zijn dat eindgebruikers geen onderscheid kunnen maken tussen een volledig defecte array en een resilverende array. In feite kan resilveren in zijn extreme vorm zo lang duren en zo verstorend zijn dat de kosten voor het bedrijf hoger kunnen zijn dan wanneer de array simpelweg volledig defect was geraakt en er in plaats daarvan een herstel vanuit back-up was uitgevoerd. Dit resilverprobleem treft RAID 1 en RAID 10 niet, nogmaals, omdat zij gespiegelde, geen pariteits-, RAID-systemen zijn en hun resilverproces triviaal is en de prestatievermindering van het systeem minimaal en kortstondig is. In zijn meest extreme vorm kan een pariteitsresilver weken of maanden duren, gedurende welke tijd de systemen zich gedragen alsof ze offline zijn – en op elk moment tijdens dit proces bestaat de mogelijkheid dat de hierboven genoemde URE-fouten opduiken, wat het resilveren zou beëindigen en alsnog het herstel vanuit back-up zou afdwingen. (Typische resilvers duren geen weken maar duren wel vele uren, en dat het dagen duurt is helemaal niet ongebruikelijk.)

Ons laatste overzicht kan worden teruggebracht tot het volgende (de conventionele term “hot spare” wordt opnieuw gebruikt): RAID 10 zonder een “hot spare” is bijna altijd een betere keuze dan RAID 6 met een “hot spare.” RAID 6 zonder een “hot spare” is altijd beter dan RAID 5 met een “hot spare.” RAID 1 met een aanvullend mirror-lid is altijd beter dan RAID 1 met een “hot spare.” Dus welk RAID-niveau met een hot spare u ook besluit te kiezen, ga simpelweg één niveau omhoog in RAID-betrouwbaarheid en laat de “hot spare” vallen om zowel prestaties als betrouwbaarheid te maximaliseren tegen gelijke of vrijwel gelijke kosten.

Warm spares hadden, net als pariteits-RAID, hun gloriedagen. Het was in feite toen pariteits-RAID nog zinvol was voor wijdverbreid gebruik – toen URE-fouten onwaarschijnlijk waren en schijfkosten hoog waren – dat warm spare-schijven eveneens zinvol waren. Zij waren goed gekoppeld; wanneer het ene zinvol was, was het andere dat vaak ook. Wat vaak over het hoofd wordt gezien is dat naarmate pariteits-RAID, vooral RAID 5, aan effectiviteit heeft ingeboet, het de warm spare op onverwachte wijze met zich heeft meegetrokken.