Wanneer Geen Redundantie Betrouwbaarder Is – De Mythe van Redundantie

Risico is een lastig concept en het vereist veel training, nadenken en analyse om gegeven scenario’s correct te beoordelen. Vaak vervangen we, omdat risicobeoordelingen zo lastig zijn, risicoanalyse door simpelweg basale redundantie toe te voegen en aan te nemen dat we het risico op gepaste wijze hebben beperkt. Maar zeer vaak is dit niet het geval. De introductie van complexiteit of aanvullende foutmodi gaat vaak gepaard met de toevoeging van redundantie, en deze nieuwe vormen van falen hebben het potentieel om meer risico toe te voegen dan de toegevoegde redundantie wegneemt. Opslagsystemen zijn bijzonder gevoelig voor deze beslissingsprocessen, wat ongelukkig is aangezien weinig, indien enige, systemen zo vatbaar zijn voor falen en belangrijker om te beschermen.

RAID is een uitstekend voorbeeld van waar een gebrek aan holistisch risicodenken tot enige vreemde besluitvorming kan leiden. Als we naar een niet ongebruikelijk scenario kijken, zullen we zien waar het doel van bescherming tegen schijfdefecten daadwerkelijk kan leiden tot een toename van risico, zelfs wanneer aanvullende redundantie wordt toegepast. In dit scenario vergelijken we een array van twaalf schijven bestaande uit twaalf SATA-harde schijven van drie terabyte in één enkele array. Het is niet ongebruikelijk om te horen dat mensen voor dit scenario RAID 5 kiezen om “maximale capaciteit en prestaties” te verkrijgen terwijl zij “adequate bescherming tegen falen” hebben.

Het idee hier is dat RAID 5 beschermt tegen het verlies van een enkele schijf, die vervangen kan worden, waarna de array zichzelf zal heropbouwen voordat een tweede schijf defect raakt. Dat is in theorie geweldig, maar de werkelijke risico’s van een array van deze grootte, zesendertig terabyte aan schijfcapaciteit, komen niet voort uit meerdere schijfdefecten zoals mensen over het algemeen vermoeden, maar uit een onvermogen om de array betrouwbaar te heropbouwen na een enkel schijfdefect, of uit een defect van de array zelf zonder dat er individuele schijven defect raken. Het risico dat een tweede schijf defect raakt is laag, niet onbestaand, maar behoorlijk laag. Schijven zijn vandaag de dag zeer betrouwbaar. Zodra één schijf defect raakt vergroot dit wel de waarschijnlijkheid dat een tweede schijf defect raakt, wat goed gedocumenteerd is, maar ik wil niet dat dit risico ons afleidt van het kijken naar de werkelijke risico’s – het risico van een mislukte resilveroperatie.

Wat er gebeurt dat ons afschrikt tijdens een RAID 5-resilveroperatie is dat er een unrecoverable read error (URE) kan optreden. Wanneer dit gebeurt stopt de resilveroperatie en blijft de array in een onbruikbare staat achter – alle gegevens op de array zijn verloren. Op gangbare SATA-schijven bedraagt het URE-percentage 10^14, oftewel eens per twaalf terabyte aan leesoperaties. Dat betekent dat een array van zes terabyte die wordt geresilverd een kans van ongeveer vijftig procent heeft om een URE te treffen en te falen. Een kans van vijftig procent op falen is krankzinnig hoog. Stel je voor dat je auto een kans van vijftig procent had dat de wielen eraf vielen elke keer dat je ermee reed. Dus met een kleine (naar de maatstaven van vandaag) RAID 5-array van zes terabyte die gebruikmaakt van SATA-schijven met een URE van 10^14, hebben we, als we een enkele schijf zouden verliezen, slechts een kans van vijftig procent dat de array zich zal herstellen, aangenomen dat de schijf onmiddellijk wordt vervangen. Dat omvat niet het risico dat een tweede schijf defect raakt, alleen het risico van een URE-fout. Het gaat er ook van uit dat de schijf volledig inactief is, afgezien van de resilveroperatie. Als de schijven tegelijkertijd druk worden gebruikt voor andere taken, dan beginnen de kansen dat er iets ergs gebeurt, hetzij een URE hetzij een tweede schijfdefect, dramatisch toe te nemen.

Bij een array van twaalf terabyte beginnen de kansen op volledig gegevensverlies tijdens een resilveroperatie de honderd procent te benaderen – wat betekent dat RAID 5 in dat geval geen enkele functionaliteit heeft. Er is altijd een overlevingskans, maar die is zeer laag. Bij zes terabyte kun je een resilveroperatie vergelijken met een spelletje Russische roulette met één kogel en zes kamers waarbij je drie keer de trekker moet overhalen. Bij twaalf terabyte moet je hem zes keer overhalen! Dat zijn geen goede kansen.

Maar we hebben het niet over een array van twaalf terabyte. We hebben het over een array van zesendertig terabyte – wat groot klinkt, maar dit is een omvang die iemand vandaag de dag gemakkelijk thuis zou kunnen hebben, laat staan in een bedrijf. Elke grote serverfabrikant, evenals vrijwel alle goedkope opslagleveranciers, maken vandaag de dag opslagsystemen van onder de $10.000 in dit capaciteitsbereik. Het resilveren van een RAID 5-array met een enkel schijfdefect op een array van zesendertig terabyte is als het spelen van Russische roulette, één kogel, zes kamers en achttien keer de trekker overhalen! Je gegevens maken niet veel kans. Voeg daaraan toe de enorme hoeveelheid tijd die nodig is om een array van die grootte te resilveren en het risico dat een tweede schijf defect raakt tijdens dat resilvervenster begint een tamelijk aanzienlijke bedreiging te worden. Ik heb schattingen gezien van resilvertijden die op sommige systemen oplopen tot weken of maanden. Dat is een lange tijd om te draaien zonder dat je nog een schijf kunt verliezen. Wanneer we het over uren of dagen hebben zijn de risico’s vrij laag, maar nog steeds aanwezig. Wanneer we het over weken of maanden van voortdurende mishandeling hebben, aangezien resilveroperaties extreem schijfintensief zijn, stijgen de faalpercentages dramatisch.

Bij een array van deze grootte kunnen we er in feite van uitgaan dat het verlies van een enkele schijf het verlies van de volledige array betekent, waardoor we helemaal geen bescherming tegen schijfdefecten meer hebben. Als we nu kijken naar een schijf met dezelfde of betere prestaties met dezelfde of betere capaciteit onder RAID 0, dat eveneens geen bescherming tegen schijfverlies heeft, hoeven we slechts elf van dezelfde schijven te gebruiken waarvan we er twaalf nodig hadden voor onze RAID 5-array. Wat dit betekent is dat we in plaats van twaalf harde schijven, elk met een kans van ongeveer drie procent op jaarlijks falen, er slechts elf hebben. Dat alleen al maakt onze RAID 0-array betrouwbaarder, aangezien er minder schijven zijn die defect kunnen raken. We hebben niet alleen minder schijven, maar er is ook geen noodzaak om het pariteitsblok te schrijven, noch om pariteitsblokken over te slaan bij het teruglezen, wat de mechanische slijtage op de RAID 0-array voor hetzelfde gebruik, zij het uiterst gering, verlaagt en het een zeer licht aanvullend betrouwbaarheidsvoordeel geeft. De RAID 0-array van elf schijven zal identiek zijn in capaciteit aan de RAID 5-array van twaalf schijven, maar zal een iets betere doorvoer en latentie hebben. Een overwinning op alle fronten. Plus de kostenbesparing van het niet nodig hebben van een aanvullende schijf.

Dus wat we hier zien is dat in grote arrays (groot in capaciteit, niet in aantal spindels) RAID 0 in bepaalde scenario’s daadwerkelijk RAID 5 voorbijstreeft. Bij het gebruik van gangbare SATA-schijven gebeurt dit bij capaciteiten die zelfs door powerusers thuis en door veel kleine bedrijven worden ervaren. Als we overstappen op enterprise-SATA-schijven of SAS-schijven, dan wordt het capaciteitsgetal waarbij dit optreedt zeer hoog en is het vandaag de dag geen zorg, maar zal het dat over slechts enkele jaren wel zijn wanneer schijfcapaciteiten nog groter worden. Maar dit benadrukt hoe gevaarlijk RAID 5 is in de groottes die we vandaag de dag zien. Iedereen begrijpt de ongelofelijke risico’s van RAID 0, maar het kan lastig zijn om in perspectief te plaatsen dat de problemen van RAID 5 zo extreem zijn dat het daadwerkelijk minder betrouwbaar zou kunnen zijn dan RAID 0.

Dat RAID 5 alleen al op basis van resilveroperaties minder betrouwbaar zou kunnen zijn dan RAID 0 in een array van deze grootte is nog maar het begin. In een enorme array als deze kan de resilvertijd zo lang duren en zo'n tol eisen van de schijven dat een tweede schijfdefect ook een meetbaar risico begint te worden. En dan zijn er nog aanvullende risico’s veroorzaakt door fouten in de arraycontroller die resilveralgoritmen kunnen gebruiken om een hele array te vernietigen, zelfs wanneer er geen schijfdefect heeft plaatsgevonden. Aangezien RAID 0 (of RAID 1 of RAID 10) geen resilveralgoritmen hebben, lijden zij niet onder dit aanvullende risico. Dit zijn lastig te kwantificeren risico’s, maar wat belangrijk is, is dat het aanvullende risico’s zijn die zich opstapelen bij het gebruik van een complexer systeem, terwijl een eenvoudiger systeem, zonder de redundantie, vanaf het begin betrouwbaarder was.

Nu we hebben vastgesteld dat RAID 5 minder betrouwbaar kan zijn dan RAID 0, zal ik wijzen op de voor de hand liggende gevaren van RAID 0. RAID wordt in het algemeen gebruikt om het risico te beperken dat een enkele, op zichzelf staande harde schijf defect raakt. We vrezen allemaal dat een enkele schijf simpelweg defect raakt en alle gegevens verloren gaan. RAID 0, dat een grote stripe van schijven is zonder enige vorm van redundantie, neemt het risico van gegevensverlies van een enkele schijf die defect raakt en vermenigvuldigt dit over een aantal schijven, waarbij het defect raken van welke schijf dan ook totaal gegevensverlies op alle schijven veroorzaakt. Dus in ons voorbeeld met elf schijven hierboven gaat, als een van de elf schijven defect raakt, alles verloren. Het is duidelijk te zien waar dit dramatisch gevaarlijker is dan het gebruik van slechts een enkele schijf, helemaal op zichzelf.

Wat ik hier probeer aan te tonen is dat redundantie geen betrouwbaarheid betekent. Alleen omdat iets redundant is, zoals RAID 5, biedt het geen garantie dat het altijd betrouwbaarder zal zijn dan iets dat niet redundant is.

Mijn favoriete analogie hier is om te kijken naar huizen in een tornado. In het ene scenario bouwen we een huis van baksteen en mortel. In het tweede scenario bouwen we twee redundante huizen, beide van stro (onze bouwers zijn blijkbaar varkens.) Wanneer de tornado (of de boze wolf) langskomt, welke laat ons waarschijnlijker achter met een overeind staand huis? Het is duidelijk dat één huis van baksteen en mortel enkele aanzienlijke betrouwbaarheidsvoordelen heeft ten opzichte van redundante strohuizen. Redundantie deed er niet toe, betrouwbaarheid deed er uiteindelijk toe.

Redundantie is vaak misleidend omdat het gemakkelijk te kwantificeren maar lastig te kwalificeren is. Redundantie is een zwart-of-witvraag: Is het redundant? Ja of nee. Eenvoudig. Betrouwbaarheid is niet zo eenvoudig. Betrouwbaarheid gaat over faalpercentages en waarschijnlijkheden. Het gaat over statistiek en analyse. Aangezien het lastig is om betrouwbaarheid op een betekenisvolle manier te kwantificeren, vooral bij het verkopen van een project aan de bedrijfsmensen, wordt redundantie vaak een eenvoudige vervanger voor dit complexe concept.

Het concept van het gebruik van redundantie om vragen over betrouwbaarheid te omzeilen blijkt ook op zeer ingewikkelde wijze van toepassing op subsystemen. In plaats van een “systeem” redundant te maken is het gebruikelijk geworden om een zeer betrouwbaar, en goedkoop, subsysteem redundant te maken en de redundantie van het subsysteem te behandelen alsof deze op het hele systeem van toepassing is. Het meest voorkomende voorbeeld hiervan zijn RAID-controllers in SAN-producten. In plaats van een redundante SAN te hebben (wat twee SAN's betekent), zullen fabrikanten vaak die ene component die in normale servers niet vaak redundant is redundant maken en de SAN vervolgens redundant noemen – wat een SAN betekent die redundantie bevat, wat helemaal niet hetzelfde is.

Een goede analogie hier zou zijn om het hebben van redundante auto's, wat twee complete, werkende auto's betekent, te vergelijken met het hebben van een enkele auto met een reserve-waterpomp in de kofferbak voor het geval de hoofdpomp defect raakt. Het is duidelijk dat een reserve-waterpomp geen slechte zaak is. Maar het is ook een triviale hoeveelheid bescherming tegen autopech vergeleken met het hebben van een tweede auto die klaarstaat. In het ene geval is het hele systeem redundant, inclusief het chassis. In het andere maken we slechts één, zeer betrouwbare component redundant binnen het chassis. Het staat niet eens op gelijke voet met het hebben van een reserveband die, op zijn minst, een autocomponent is met een hogere waarschijnlijkheid van falen.

Net als de mythe van de betrouwbaarheid van RAID 5 en de betrouwbaarheid van systeem/subsysteem, worden gedeelde opslagtechnologieën zoals SAN's en NAS vaak op dezelfde manier behandeld, vooral met betrekking tot virtualisatie. Er is een veelvoorkomend scenario waarin een virtualisatieproject wordt ondernomen en mensen instinctief in paniek raken omdat een enkele virtualisatiehost een single point of failure vormt waar, als deze defect raakt, vele systemen tegelijkertijd zullen falen.

Het gebruik van de term “single point of failure” veroorzaakt een gevoel van paniek en is een uitstekend middel om een gesprek te sturen. Maar een SPOF, zoals wij het graag noemen, hoewel iets wat we graag verwijderen wanneer mogelijk, hoeft niet het einde van de wereld te zijn. Denk aan ons bakstenen huis. Het is een SPOF. Onze twee strohuizen zijn dat niet. Toch maakt een enkel briesje sneller een einde aan onze redundante oplossingen dan aan onze betrouwbare SPOF. Het zoeken naar SPOF's is een uitstekende manier om punten van kwetsbaarheid in een systeem te vinden, maar voel niet dat elke SPOF in elk scenario redundant moet worden gemaakt. De meeste bedrijven zullen hun beste waarde vinden met vele SPOF's aanwezig. Ons werkelijke doel is betrouwbaarheid tegen passende kosten; redundantie is, zoals we hebben gezien, geen vervanger voor betrouwbaarheid, het is simpelweg een hulpmiddel dat we kunnen gebruiken om betrouwbaarheid te bereiken.

De theorie die veel mensen volgen bij het virtualiseren is dat zij hun virtualisatiehost nemen en zeggen “Deze host is een SPOF, dus ik moet er twee van hebben en High Availability-functies gebruiken om transparante failover mogelijk te maken!” Dit wordt aangewakkerd doordat de toonaangevende virtualisatieleverancier zijn geld ten eerste verdient met het verkopen van dure HA-add-onproducten en ten tweede met het in handen zijn van een grote opslagleverancier – dus het verkopen van onnodige of zelfs gevaarlijke aanvullende gedeelde opslag is een grote financiële overwinning voor hen en zou gemakkelijk de reden kunnen zijn dat zij de virtualisatieruimte vanaf het begin hebben gepropageerd. Redundante virtualisatiehosts met gedeelde opslag klinkt geweldig, maar kan om verschillende redenen uiterst misleidend zijn.

De eerste reden is dat het verwijderen van de initiële SPOF, de virtualisatiehost, wordt vervangen door een nieuwe SPOF, de gedeelde opslag. Dit bereikt niets. Aangenomen dat we servers en gedeelde opslag van vergelijkbare kwaliteit gebruiken, is het enige wat we hebben gedaan het verplaatsen van waar het risico zit, niet het veranderen van hoe groot het is. De waarschijnlijkheid dat het opslagsysteem faalt is ongeveer gelijk aan de waarschijnlijkheid dat de oorspronkelijke server faalt. Maar naast het rondschuiven van de SPOF als in een schelpenspel hebben we ook iets veel, veel ergers gedaan – we hebben geketende of cascaderende faalafhankelijkheden geïntroduceerd.

In ons oorspronkelijke scenario hadden we een enkele server. Als de server bleef werken zaten we goed, als hij faalde zaten we slecht. Eenvoudig. Nu hebben we twee virtualisatiehosts, een enkele opslagserver (SAN, NAS, wat dan ook) en een netwerk dat ze met elkaar verbindt. We hebben al vastgesteld dat het risico dat de gedeelde opslag faalt ongeveer gelijk is aan ons totale systeemrisico in het oorspronkelijke scenario. Maar nu hebben we de aanvullende afhankelijkheden van het netwerk en de twee front-end virtualisatieknooppunten. Elk van deze componenten is betrouwbaarder dan de kwetsbare gedeelde opslag (alles met mechanische schijven zal kwetsbaar zijn), maar dat zij een lager risico hebben is niet het probleem; het probleem is dat de risico’s combinatorisch zijn.

Als een van deze drie componenten (opslag, netwerk of de front-end knooppunten) faalt, dan faalt alles. De oplossing hiervoor is om de gedeelde opslag op zichzelf redundant te maken en om het netwerk op zichzelf redundant te maken. Met voldoende werk kunnen we de kwetsbaarheid en het risico overwinnen die we hebben geïntroduceerd door gedeelde opslag toe te voegen, maar de gedeelde opslag op zichzelf is geen vorm van risicobeperking maar is zelf een risico dat moet worden beperkt. De spiraal van complexiteit begint en de kosten die gepaard gaan met het op gelijke voet brengen van dit nieuwe systeem met de betrouwbaarheid van het oorspronkelijke, enkele-server-systeem kunnen astronomisch zijn.

Nu we al deze redundantie hebben, hebben we nog één risico om ons zorgen over te maken. Het beheren van al deze redundantie, al deze bewegende delen, vereist veel meer kennis, vaardigheid en voorbereiding dan het beheren van een eenvoudige, enkele server. We zijn van een eenvoudige oplossing naar een zeer complexe overgegaan. In mijn eigen anekdotische ervaring komen de werkelijke gevaren van oplossingen als deze niet voort uit het falen van de hardware, maar uit menselijke fouten. Niet alleen is er weinig gedaan om te voorkomen dat menselijke fouten dit nieuwe systeem doen falen, maar we hebben ontelbare punten toegevoegd waar een mens per ongeluk het hele systeem, inclusief alle redundantie, plat zou kunnen leggen. Ik heb het uit de eerste hand gezien; ik heb de horrorverhalen gehoord. Hoe complexer het systeem, hoe waarschijnlijker het is dat een mens per ongeluk alles kapotmaakt.

Het is van cruciaal belang dat wij als IT-professionals een stap terug doen en naar complete systemen kijken en betrouwbaarheid en risico overwegen en redundantie simpelweg beschouwen als een hulpmiddel om te gebruiken bij het nastreven van betrouwbaarheid. Redundantie zelf is geen wondermiddel. Eenvoud evenmin. Betrouwbaarheid is een complex probleem om aan te pakken. Het vermijden van simplistische vervangingen is een belangrijke eerste stap in de overgang van het toedekken van betrouwbaarheidsproblemen naar het onder ogen zien en oplossen ervan.