Når ingen redundans er mer pålitelig – Myten om redundans

Risiko er et vanskelig begrep, og det krever mye opplæring, tanke og analyse for å vurdere gitte scenarioer riktig. Ofte, fordi risikovurderinger er så vanskelige, erstatter vi risikoanalyse med ganske enkelt å legge til grunnleggende redundans og anta at vi har redusert risikoen tilstrekkelig. Men dette er svært ofte ikke tilfelle. Innføringen av kompleksitet eller ekstra feilmodi følger ofte med tillegg av redundans, og disse nye formene for feil har potensial til å legge til mer risiko enn den økte redundansen fjerner. Lagringssystemer er spesielt utsatt for disse beslutningsprosessene, noe som er uheldig ettersom få, om noen, systemer er så sårbare for feil og viktige å beskytte.

RAID er et godt eksempel på hvor mangel på helhetlig risikotankegang kan føre til noen merkelige beslutninger. Hvis vi ser på et ikke uvanlig scenario, vil vi se der målet om å beskytte mot diskfeil faktisk kan føre til økt risiko selv når ekstra redundans er lagt til. I dette scenariet vil vi sammenligne en tolv-disk array bestående av tolv tre-terabyte SATA harddisker i én enkelt array. Det er ikke uvanlig å høre om folk som velger RAID 5 for dette scenariet for å få “maksimal kapasitet og ytelse” mens de har “tilstrekkelig beskyttelse mot feil.”

Ideen her er at RAID 5 beskytter mot tap av én enkelt disk som kan erstattes, og arrayen vil gjenoppbygge seg selv før en andre disk svikter. Det er flott i teorien, men den reelle risikoen ved en array av denne størrelsen – trettiseks terabytes diskkapasitet – kommer ikke fra flere diskfeil slik folk generelt antar, men fra en manglende evne til å pålitelig gjenoppbygge arrayen etter en enkelt diskfeil, eller fra en feil i selve arrayen uten at individuelle disker svikter. Risikoen for at en andre disk svikter er lav – ikke ikke-eksisterende, men ganske lav. Disker i dag er svært pålitelige. Når én disk svikter, øker det sannsynligheten for at en andre disk svikter, noe som er godt dokumentert, men jeg vil ikke at denne risikoen skal lede oss bort fra å se på de sanne risikoene – risikoen for en mislykket resilver-operasjon.

Det som skremmer oss under en RAID 5 resilver-operasjon er at en unrecoverable read error (URE) kan oppstå. Når det skjer, stopper resilver-operasjonen og arrayen etterlates i en ubrukelig tilstand – alle data på arrayen er tapt. På vanlige SATA-disker er URE-raten 10^14, eller én gang per tolv terabytes leseoperasjoner. Det betyr at en seks-terabytes array som resilveres har en omtrent femti prosent sjanse for å treffe en URE og svikte. Femti prosent sjanse for feil er sinnssykt høyt. Tenk deg om bilen din hadde femti prosent sjanse for at hjulene falt av hver gang du kjørte den. Så med en liten (etter dagens standarder) seks-terabytes RAID 5-array som bruker 10^14 URE SATA-disker, hvis vi mister én enkelt disk, har vi bare femti prosent sjanse for at arrayen vil gjenopprettes, forutsatt at disken erstattes umiddelbart. Det inkluderer ikke risikoen for at en andre disk svikter, bare risikoen for en URE-feil. Det forutsetter også at disken er helt ledig bortsett fra resilver-operasjonen. Hvis diskene er opptatt med å brukes til andre oppgaver samtidig, begynner sjansene for at noe vondt skjer – enten en URE eller en andre diskfeil – å øke dramatisk.

Med en tolv-terabytes array begynner sjansene for fullstendig datatap under en resilver-operasjon å nærme seg hundre prosent – noe som betyr at RAID 5 ikke har noen funksjon i det hele tatt i det tilfellet. Det er alltid en sjanse for overlevelse, men den er svært lav. Ved seks terabytes kan du sammenligne en resilver-operasjon med et spill russisk rulett med én kule og seks kamre, og du må trekke avtrekkeren tre ganger. Med tolv terabytes må du trekke den seks ganger! Det er ikke gode odds.

Men vi snakker ikke om en tolv-terabytes array. Vi snakker om en trettiseks-terabytes array – som høres stor ut, men dette er en størrelse som noen lett kunne ha hjemme i dag, for ikke å snakke om i en bedrift. Alle større serverprodusenter, samt nesten alle lavkost-lagringsleverandører, lager sub-$10 000 lagringssystemer i dette kapasitetsområdet i dag. Å resilver en RAID 5-array med én enkelt diskfeil på en trettiseks-terabytes array er som å spille russisk rulett, én kule, seks kamre og trekke avtrekkeren atten ganger! Dataene dine har ikke mye sjanse. Legg til den utrolige mengden tid som trengs for å resilver en array av den størrelsen, og risikoen for at en andre disk svikter under det resilver-vinduet begynner å bli en ganske betydelig trussel. Jeg har sett estimater på resilver-tider som klatrer inn i uker eller måneder på noen systemer. Det er lang tid å kjøre uten å kunne miste en annen disk. Når vi snakker om timer eller dager, er risikoen ganske lav, men fortsatt til stede. Når vi snakker om uker eller måneder med kontinuerlig belastning – ettersom resilver-operasjoner er ekstremt diskintensive – klatrer feilratene dramatisk.

Med en array av denne størrelsen kan vi effektivt anta at tap av én enkelt disk betyr tap av hele arrayen, noe som etterlater oss uten noen form for diskfeilbeskyttelse i det hele tatt. Nå, hvis vi ser på en disk med samme eller bedre ytelse med samme eller bedre kapasitet under RAID 0, som heller ikke har noen beskyttelse mot disktap, trenger vi bare å bruke elleve av de samme diskene som vi trengte tolv av til RAID 5-arrayen. Det betyr at i stedet for tolv harddisker, der alle har omtrent tre prosent sjanse for årlig feil, har vi bare elleve. Det alene gjør RAID 0-arrayen mer pålitelig ettersom det er færre disker som kan svikte. Vi har ikke bare færre disker, men det er heller ikke behov for å skrive paritetsblokken eller hoppe over paritetsblokker ved lesing, noe som senker, i svært liten grad, det mekaniske slitasje og riv på RAID 0-arrayen for den samme bruken og gir den en svært liten ekstra pålitelighetsfordel. RAID 0-arrayen med elleve disker vil være identisk i kapasitet med tolv-disk RAID 5-arrayen, men vil ha noe bedre gjennomstrømming og forsinkelse. En seier på alle fronter. Pluss kostnadsbesparelsen ved ikke å trenge en ekstra disk.

Så det vi ser her er at i store arrayer (store i kapasitet, ikke i spindelantall) passerer RAID 0 faktisk RAID 5 i visse scenarioer. Når du bruker vanlige SATA-disker skjer dette ved kapasiteter som oppleves til og med av avanserte hjemmebrukere og av mange småbedrifter. Hvis vi går over til enterprise SATA-disker eller SAS-disker, blir kapasitetstallet der dette skjer svært høyt og er ikke en bekymring i dag, men vil være det om noen år når diskkapasitetene blir enda større. Men dette fremhever hvor farlig RAID 5 er i størrelsesordenene vi ser i dag. Alle forstår de utrolige risikoene ved RAID 0, men det kan være vanskelig å sette i perspektiv at RAID 5s problemer er så ekstreme at det faktisk kan være mindre pålitelig enn RAID 0.

At RAID 5 kan være mindre pålitelig enn RAID 0 i en array av denne størrelsen basert på resilver-operasjoner alene, er bare begynnelsen. I en massiv array som denne kan resilver-tiden ta så lang tid og påføre diskene slik belastning at sekundær diskfeil begynner å bli en målbar risiko også. Og så er det ytterligere risikoer forårsaket av array-kontrollerfeil som kan bruke resilver-algoritmer til å ødelegge en hel array selv om ingen diskfeil har oppstått. Ettersom RAID 0 (eller RAID 1 eller RAID 10) ikke har resilver-algoritmer, lider de ikke av denne ekstra risikoen. Disse er vanskelige risikoer å kvantifisere, men det som er viktig er at de er ekstra risikoer som akkumuleres når man bruker et mer komplekst system når et enklere system, uten redundansen, var mer pålitelig fra starten av.

Nå som vi har fastslått at RAID 5 kan være mindre pålitelig enn RAID 0, vil jeg påpeke de åpenbare farene ved RAID 0. RAID generelt brukes til å redusere risikoen for at én enkelt harddisk svikter. Vi frykter alle at en enkelt disk rett og slett svikter og alle data går tapt. RAID 0, som er en stor stripe av disker uten noen form for redundans, tar risikoen for datatap ved svikt i én enkelt disk og multipliserer den over et antall disker der enhver disk som svikter fører til totalt tap av data på alle disker. Så i elleve-disk-eksempelet ovenfor, hvis noen av de elleve diskene svikter, er alt tapt. Det er tydelig å se der dette er dramatisk mer farlig enn bare å bruke én enkelt disk.

Det jeg prøver å påpeke her er at redundans ikke betyr pålitelighet. Bare fordi noe er redundant, som RAID 5, gir ingen garanti for at det alltid vil være mer pålitelig enn noe som ikke er redundant.

Min favorittanalogi her er å se på hus i en tornado. I ett scenario bygger vi et hus av murstein og mørtel. I det andre scenariet bygger vi to redundante hus, begge av halm (våre byggmestere er griser, tilsynelatende). Når tornaden (eller den store stygge ulven) kommer, hvilken har størst sjanse for å etterlate oss med et stående hus? Tydeligvis har ett mursteinhus noen betydelige pålitelighetsfordeler over redundante halmhus. Redundans spilte ingen rolle – pålitelighet spilte rollen til slutt.

Redundans er ofte misvisende fordi det er lett å kvantifisere, men vanskelig å kvalifisere. Redundans er et svart-hvitt-spørsmål: Er det redundant? Ja eller nei. Enkelt. Pålitelighet er ikke så enkelt. Pålitelighet handler om feilrater og sannsynligheter. Det handler om statistikk og analyse. Ettersom det er vanskelig å kvantifisere pålitelighet på en meningsfull måte, spesielt når man selger et prosjekt til forretningsfolk, blir redundans ofte et enkelt substitutt for dette komplekse begrepet.

Konseptet med å bruke redundans til å avlede spørsmål om pålitelighet ender også opp med å gjelde for delsystemer på svært innviklede måter. I stedet for å gjøre et “system” redundant har det blitt vanlig å gjøre et svært pålitelig og lavkost delsystem redundant og behandle delsystemredundans som om den gjelder for hele systemet. Det vanligste eksemplet på dette er RAID-kontrollere i SAN-produkter. I stedet for å ha en redundant SAN (det vil si to SANer), vil produsenter ofte gjøre den ene komponenten som normalt ikke er redundant i vanlige servere redundant og deretter kalle SANen redundant – noe som betyr en SAN som inneholder redundans, som slett ikke er det samme.

En god analogi her ville være å sammenligne det å ha redundante biler, det vil si to komplette, fungerende biler, med å ha én bil med en reserve vannpumpe i bagasjerommet i tilfelle hovedpumpen svikter. En reserve vannpumpe er åpenbart ikke en dårlig ting. Men det er også en triviell mengde beskyttelse mot bilfeil sammenlignet med å ha en andre bil klar til bruk. I ett tilfelle er hele systemet redundant, inkludert karosseriet. I det andre gjør vi bare én, svært pålitelig komponent redundant inne i karosseriet. Det er ikke engang på nivå med å ha et reservedekk, som i det minste er en bilkomponent med høyere sannsynlighet for feil.

Akkurat som myten om RAID 5-pålitelighet og system/delsystem-pålitelighet, behandles delt lagrings-teknologier som SANer og NAS ofte på samme måte, spesielt med hensyn til virtualisering. Det er et vanlig scenario der et virtualiseringsprosjekt settes i gang og folk instinktivt panikker fordi en enkelt virtualiseringsvert representerer ett enkelt feilpunkt der, hvis den svikter, vil mange systemer alle svikte på en gang.

Å bruke begrepet “enkelt feilpunkt” skaper en panikkstemning og er et godt middel til å styre en samtale. Men et SPOF (single point of failure), som vi liker å kalle det, er ikke nødvendigvis slutten på verden selv om vi liker å fjerne det når vi kan. Tenk på mursteinshuset vårt. Det er et SPOF. Våre to halmhus er det ikke. Likevel tar en enkelt bris knekken på våre redundante løsninger raskere enn vår pålitelige SPOF. Å lete etter SPOFer er en god måte å finne skjørhetspunkter i et system, men ikke la det gi deg en følelse av at hvert SPOF må gjøres redundant i alle scenarioer. De fleste bedrifter vil finne sin beste verdi ved å ha mange SPOFer på plass. Vårt egentlige mål er pålitelighet til passende kostnad; redundans, som vi har sett, er ingen erstatning for pålitelighet, det er bare et verktøy vi kan bruke for å oppnå pålitelighet.

Teorien som mange følger ved virtualisering er at de tar virtualiseringsverten sin og sier “Denne verten er et SPOF, så jeg trenger to av dem og bruker High Availability-funksjoner for å tillate transparent failover!” Dette er drevet av den ledende virtualiseringsleverandøren som tjener penger primært ved å selge dyre HA-tillegsprodukter og sekundært ved å eies av en stor lagringsleverandør – så å selge unødvendig eller til og med farlig ekstra delt lagring er en stor pengegevinst for dem og kan lett være grunnen til at de har vært forkjempere for virtualiseringsrommet fra begynnelsen. Redundante virtualiseringsverts med delt lagring høres flott ut, men kan være svært misvisende av flere grunner.

Den første grunnen er at fjerning av det første SPOF-et, virtualiseringsverten, erstattes med et nytt SPOF, den delte lagringen. Dette oppnår ingenting. Forutsatt at vi bruker sammenlignbare kvalitetsservere og delt lagring, har vi bare flyttet risikoens plassering, ikke endret størrelsen på den. Sannsynligheten for at lagringssystemet svikter er omtrent like stor som sannsynligheten for at den opprinnelige serveren svikter. Men i tillegg til å flytte SPOF rundt som i et skallspill, har vi også gjort noe langt, langt verre – vi har introdusert kjedede eller kaskadefeile avhengigheter.

I vårt opprinnelige scenario hadde vi én enkelt server. Hvis serveren fortsatte å fungere, var vi gode; hvis den sviktet, var vi ikke det. Enkelt. Nå har vi to virtualiseringsverts, én enkelt lagringsserver (SAN, NAS, hva det nå er) og et nettverk som forbinder dem. Vi har allerede fastslått at risikoen for at den delte lagringen svikter er omtrent lik vår totale systemrisiko i det opprinnelige scenariet. Men nå har vi de ekstra avhengighetene av nettverket og de to front-end virtualiseringsnodene. Hver av disse komponentene er mer pålitelig enn den skjøre delte lagringen (alt med mekaniske disker vil være skjørt), men at de er lavere risiko er ikke poenget; poenget er at risikoene er kombinatoriske.

Hvis noen av disse tre komponentene (lagring, nettverk eller front-end-nodene) svikter, svikter alt. Løsningen på dette er å gjøre den delte lagringen redundant på sin egen hånd og å gjøre nettverket redundant på sin egen hånd. Med nok arbeid kan vi overvinne skjørheten og risikoen vi introduserte ved å legge til delt lagring, men den delte lagringen i seg selv er ikke en form for risikoreduksjon, men er en risiko i seg selv som må reduseres. Kompleksitetsspiralen begynner, og kostnaden forbundet med å bringe dette nye systemet opp på nivå med påliteligheten til det opprinnelige, enkle serversystemet kan være astronomisk.

Nå som vi har all denne redundansen, har vi én risiko til å bekymre oss for. Å administrere all denne redundansen, alle disse bevegelige delene, krever mye mer kunnskap, ferdigheter og forberedelse enn å administrere en enkel, enkelt server. Vi har gått fra en enkel løsning til en svært kompleks. I min egen anekdotiske erfaring kommer de reelle farene med løsninger som denne ikke fra at maskinvaren svikter, men fra menneskelige feil. Ikke bare er lite gjort for å unngå at menneskelige feil fører til at dette nye systemet svikter, men vi har lagt til utallige punkter der et menneske ved et uhell kan ta ned hele systemet, redundans og alt. Jeg har sett det på nært hold; jeg har hørt skrekkhistoriene. Jo mer komplekst systemet er, jo mer sannsynlig er det at et menneske ved et uhell vil ødelegge alt.

Det er kritisk at vi som IT-fagfolk tar et skritt tilbake og ser på komplette systemer og vurderer pålitelighet og risiko, og tenker på redundans rett og slett som et verktøy å bruke i jakten på pålitelighet. Redundans i seg selv er ingen universalløsning. Det er heller ikke enkelhet. Pålitelighet er et komplekst problem å ta tak i. Å unngå forenklede erstatninger er et viktig første skritt i å gå fra å dekke over pålitelighetsutfordringer til å konfrontere og løse dem.