Når ingen redundans er mere pålidelig – myten om redundans

Risiko er et svært begreb, og det kræver en del træning, tanke og analyse at vurdere givne scenarier korrekt. Ofte, fordi risikovurderinger er så svære, erstatter vi risikoanalyse med blot at tilføje grundlæggende redundans og antage, at vi har afbødet risikoen tilstrækkeligt. Men meget ofte er det ikke tilfældet. Introduktionen af kompleksitet eller yderligere fejltilstande følger ofte med tilføjelsen af redundans, og disse nye former for fejl har potentiale til at tilføje mere risiko, end den tilføjede redundans fjerner. Lagringssystemer er særligt udsatte for disse beslutningsprocesser, hvilket er uheldigt, da få, om nogen, systemer er så modtagelige for fejl og vigtigere at beskytte.

RAID er et godt eksempel på, hvor mangel på holistisk risikotænkning kan føre til nogle mærkelige beslutninger. Hvis vi ser på et ikke ualmindeligt scenarie, vil vi se, hvor målet om at beskytte mod drevfejl faktisk kan føre til en stigning i risiko, selv når yderligere redundans tilføjes. I dette scenarie vil vi sammenligne et tolv-drev array bestående af tolv tre-terabyte SATA-harddiske i et enkelt array. Det er ikke ualmindeligt at høre om folk, der vælger RAID 5 til dette scenarie for at opnå “maksimal kapacitet og ydeevne” med “tilstrækkelig beskyttelse mod fejl.”

Ideen er, at RAID 5 beskytter mod tab af ét enkelt drev, som kan erstattes, og arrayet vil genopbygge sig selv, inden et andet drev fejler. Det er fantastisk i teorien, men de reelle risici ved et array af denne størrelse, seksogtyve terabyte drevkapacitet, kommer ikke fra flere drevfejl, som folk generelt mistænker, men fra en manglende evne til pålideligt at genopbygge arrayet efter en enkelt drevfejl eller fra en fejl i selve arrayet uden at nogen individuelle drev fejler. Risikoen for, at et andet drev fejler, er lav, ikke ikke-eksisterende, men ganske lav. Drev er i dag meget pålidelige. Når ét drev fejler, øger det sandsynligheden for, at et andet drev fejler, hvilket er veldokumenteret, men jeg ønsker ikke, at denne risiko skal aflede os fra at se på de sande risici – risikoen for en mislykket resilver-operation.

Det, der skræmmer os under en RAID 5-resilver-operation, er, at en unrecoverable read error (URE) kan opstå. Når det sker, standser resilver-operationen, og arrayet efterlades i en ubrugelig tilstand – alle data på arrayet er tabt. På almindelige SATA-drev er URE-raten 10^14, eller én gang for hver tolv terabyte læseoperationer. Det betyder, at et seks-terabyte array, der resilveres, har omtrent halvtreds procents chance for at ramme en URE og fejle. Halvtreds procents fejlchance er vanvittigt høj. Forestil dig, hvis din bil havde halvtreds procents chance for, at hjulene faldt af, hver gang du kørte. Så med et lille (efter nutidens standarder) seks-terabyte RAID 5-array med 10^14 URE SATA-drev, hvis vi mister et enkelt drev, har vi kun halvtreds procents chance for, at arrayet genoprettes, forudsat at drevet erstattes med det samme. Det inkluderer ikke risikoen for, at et andet drev fejler, kun risikoen for en URE-fejl. Det forudsætter også, at drevet er fuldstændig inaktivt ud over resilver-operationen. Hvis drevene bruges aktivt til andre opgaver på samme tid, begynder chancerne for, at noget galt sker, enten en URE eller et andet drevfejl, at stige dramatisk.

Med et tolv-terabyte array begynder chancerne for fuldstændigt datatab under en resilver-operation at nærme sig hundrede procent – hvilket betyder, at RAID 5 slet ingen funktionalitet har i det tilfælde. Der er altid en chance for overlevelse, men den er meget lav. Ved seks terabyte kan man sammenligne en resilver-operation med russisk roulette med én kugle og seks kamre, og man skal trykke på aftrækkeren tre gange. Med tolv terabyte skal man trykke seks gange! Det er ikke gode odds.

Men vi taler ikke om et tolv-terabyte array. Vi taler om et seksogtyve-terabyte array – som lyder stort, men dette er en størrelse, som nogen nemt kunne have hjemme i dag, for slet ikke at tale om i en virksomhed. Alle større serverproducenter såvel som næsten alle lavpris-storage-leverandører fremstiller sub-$10.000 lagringssystemer i denne kapacitetsrækkevidde i dag. At resilvere et RAID 5-array med én drevfejl på et seksogtyve-terabyte array er som at spille russisk roulette, én kugle, seks kamre og trykke på aftrækkeren atten gange! Dine data har ikke mange chancer. Dertil kommer den utrolige mængde tid, der er nødvendig for at resilvere et array af den størrelse, og risikoen for, at en anden disk fejler under det resilver-vindue, begynder at blive en ret betydelig trussel. Jeg har set estimater for resilver-tider stige til uger eller måneder på nogle systemer. Det er lang tid at køre uden at kunne miste endnu et drev. Når vi taler om timer eller dage, er risiciene ret lave, men stadig til stede. Når vi taler om uger eller måneder med kontinuerlig belastning, da resilver-operationer er ekstremt drevintensive, stiger fejlraterne dramatisk.

Med et array af denne størrelse kan vi effektivt antage, at tabet af et enkelt drev betyder tabet af hele arrayet, hvilket efterlader os uden nogen drevfejlbeskyttelse overhovedet. Hvis vi nu ser på et drev med samme eller bedre ydeevne og samme eller bedre kapacitet under RAID 0, som heller ikke har nogen beskyttelse mod drevtab, behøver vi kun at bruge elleve af de samme drev, som vi behøvede tolv af til vores RAID 5-array. Det betyder, at i stedet for tolv harddiske, som hver har omtrent tre procents chance for årlig fejl, har vi kun elleve. Det alene gør vores RAID 0-array mere pålideligt, da der er færre drev, der kan fejle. Vi har ikke kun færre drev, men der er heller ikke behov for at skrive paritetsblokken eller springe paritetsblokke over ved læsning, hvilket sænker, om end ganske lidt, den mekaniske slitage på RAID 0-arrayet ved samme udnyttelse og giver det en ganske lille yderligere pålideligheds edge. RAID 0-arrayet med elleve drev vil være identisk i kapacitet med tolv-drev RAID 5-arrayet, men vil have en smule bedre gennemstrømning og latens. En gevinst på alle fronter. Plus omkostningsbesparelsen ved ikke at behøve et ekstra drev.

Så det, vi ser her, er, at i store arrays (store i kapacitet, ikke i spindelantal) overstiger RAID 0 faktisk RAID 5 i visse scenarier. Ved brug af almindelige SATA-drev sker dette ved kapaciteter, som endda superbrugere hjemme og mange små virksomheder oplever. Hvis vi bevæger os til enterprise SATA-drev eller SAS-drev, så bliver kapaciteten, hvor dette sker, meget høj og er ikke en bekymring i dag, men vil være det om bare få år, når drevkapaciteterne bliver endnu større. Men dette fremhæver, hvor farlig RAID 5 er i de størrelser, vi ser i dag. Alle forstår de utrolige risici ved RAID 0, men det kan være svært at sætte i perspektiv, at RAID 5's problemer er så ekstreme, at det faktisk kan være mindre pålideligt end RAID 0.

At RAID 5 kan være mindre pålideligt end RAID 0 i et array af denne størrelse baseret på resilver-operationer alene er kun begyndelsen. I et massivt array som dette kan resilver-tiden tage så lang tid og påvirke drevene så meget, at en anden drevfejl begynder at blive en målbar risiko. Og så er der yderligere risici forårsaget af array-controller-fejl, der kan bruge resilver-algoritmer til at ødelægge et helt array, selv når ingen drevfejl er opstået. Da RAID 0 (eller RAID 1 eller RAID 10) ikke har resilver-algoritmer, lider de ikke af denne yderligere risiko. Disse er svære risici at kvantificere, men det vigtige er, at de er yderligere risici, der akkumuleres, når man bruger et mere komplekst system, når et enklere system, uden redundansen, var mere pålideligt fra starten.

Nu hvor vi har fastslået, at RAID 5 kan være mindre pålideligt end RAID 0, vil jeg påpege de åbenlyse farer ved RAID 0. RAID generelt bruges til at afbøde risikoen for, at en enkelt, isoleret harddisk fejler. Vi frygter alle, at et enkelt drev simpelthen fejler, og alle data går tabt. RAID 0, som er en stor stripe af drev uden nogen form for redundans, tager risikoen for datatab ved et enkelt drevfejl og multiplicerer den på tværs af et antal drev, hvor ethvert drev, der fejler, medfører totalt datatab for alle drev. Så i vores elleve-disk eksempel ovenfor, hvis nogen af de elleve diske fejler, er alt tabt. Det er tydeligt at se, hvorfor dette er dramatisk mere farligt end bare at bruge et enkelt drev alene.

Det, jeg forsøger at påpege her, er, at redundans ikke betyder pålidelighed. Bare fordi noget er redundant, som RAID 5, giver det ingen garanti for, at det altid vil være mere pålideligt end noget, der ikke er redundant.

Min yndlingsanalogi her er at se på huse i en tornado. I ét scenarie bygger vi et hus af mursten og mørtel. I det andet scenarie bygger vi to redundante huse, hvert bygget af halm (vores bygherrer er åbenbart grise). Når tornadoen (eller den store stygge ulv) kommer, hvad er så mest sandsynligt at efterlade os med et stående hus? Et enkelt murstenshus har nogle betydelige pålideligheds fordele frem for redundante halm-huse. Redundans betød ikke noget, pålidelighed betød noget i sidste ende.

Redundans er ofte vildledende, fordi det er let at kvantificere, men svært at kvalificere. Redundans er et sort-hvidt spørgsmål: Er det redundant? Ja eller nej. Enkelt. Pålidelighed er ikke så enkel. Pålidelighed handler om fejlrater og sandsynligheder. Det handler om statistik og analyse. Da det er svært at kvantificere pålidelighed på en meningsfuld måde, især når man sælger et projekt til forretningsfolk, bliver redundans ofte en simpel erstatning for dette komplekse begreb.

Konceptet om at bruge redundans til at aflede spørgsmål om pålidelighed ender også med at gælde for delsystemer på meget indviklede måder. I stedet for at gøre et “system” redundant er det blevet almindeligt at gøre et meget pålideligt og billigt delsystem redundant og behandle delsystemredundans som gældende for hele systemet. Det mest almindelige eksempel på dette er RAID-controllere i SAN-produkter. I stedet for at have et redundant SAN (dvs. to SAN'er) vil producenter ofte gøre den ene komponent, der ikke er redundant i normale servere, redundant og derefter kalde SAN'et redundant – dvs. et SAN, der indeholder redundans, hvilket slet ikke er det samme.

En god analogi her ville være at sammenligne at have redundante biler, dvs. to komplette, fungerende biler, og at have én bil med en ekstra vandpumpe i bagagerummet i tilfælde af, at den primære fejler. Det er klart, at en ekstra vandpumpe ikke er en dårlig ting. Men det er også en triviel mængde beskyttelse mod bilfejl sammenlignet med at have en anden bil klar. I ét tilfælde er hele systemet redundant, inklusive chassiset. I det andet gør vi kun én, meget pålidelig komponent redundant inde i chassiset. Det er ikke engang på niveau med at have en reservedæk, som i det mindste er en bilkomponent med en højere sandsynlighed for fejl.

Ligesom myten om RAID 5-pålidelighed og system/delsystem-pålidelighed behandles delte lagringsteknologier som SAN'er og NAS'er ofte på samme måde, især hvad angår virtualisering. Der er et almindeligt scenarie, hvor et virtualiseringsprojekt påbegyndes, og folk instinktivt panikker, fordi en enkelt virtualiseringsvært repræsenterer et enkelt fejlpunkt, hvor mange systemer alle vil fejle på én gang, hvis det fejler.

Brug af udtrykket “single point of failure” fremkalder en panikfølelse og er et godt middel til at styre en samtale. Men et SPOF, som vi kan lide at kalde det, er selv om vi gerne vil fjerne det, når det er muligt, ikke nødvendigvis verdens undergang. Tænk på vores murstenshus. Det er et SPOF. Vores to halm-huse er det ikke. Men en enkelt vindpust tager vores redundante løsninger ud hurtigere end vores pålidelige SPOF. At lede efter SPOF'er er en god måde at finde skrøbelighedspunkter i et system på, men man bør ikke føle, at hvert SPOF skal gøres redundant i hvert scenarie. De fleste virksomheder vil finde deres bedste værdi ved at have mange SPOF'er. Vores egentlige mål er pålidelighed til passende pris; redundans, som vi har set, er ingen erstatning for pålidelighed, det er blot et værktøj, vi kan bruge til at opnå pålidelighed.

Den teori, som mange mennesker følger, når de virtualiserer, er, at de tager deres virtualiseringsvært og siger “Denne vært er et SPOF, så jeg skal have to af dem og bruge High Availability-funktioner til at muliggøre transparent failover!” Dette er drevet af den førende virtualiseringsleverandør, der tjener penge primært ved at sælge dyre HA-tilføjelsesprodukter og sekundært ved at ejes af en stor storage-leverandør – så salg af unødvendig eller endda farlig yderligere delt storage er en stor monetær gevinst for dem og kan nemt være grunden til, at de har gået foran i virtualiseringsrummet fra starten. Redundante virtualiseringsvestre med delt storage lyder fantastisk, men kan være ekstremt fejlplaceret af flere grunde.

Den første grund er, at fjernelse af det oprindelige SPOF, virtualiseringsvæ rten, erstattes med et nyt SPOF, den delte storage. Dette opnår ingenting. Forudsat at vi bruger sammenlignelige kvalitetsservere og delt storage, har vi blot flyttet, hvor risikoen er, ikke ændret, hvor stor den er. Sandsynligheden for, at lagringssystemet fejler, er omtrent lig med sandsynligheden for, at den oprindelige server fejler. Men udover at flytte SPOF rundt som i et skalkespil har vi også gjort noget langt, langt værre – vi har introduceret kædede eller kaskaderende fejlafhængigheder.

I vores oprindelige scenarie havde vi én enkelt server. Hvis serveren fortsatte med at virke, var vi fine; hvis den fejlede, var vi ikke. Enkelt. Nu har vi to virtualiseringsvestre, én storage-server (SAN, NAS, hvad som helst) og et netværk, der forbinder dem. Vi har allerede fastslået, at risikoen for, at den delte storage fejler, er omtrent lig med vores samlede systemrisiko i det oprindelige scenarie. Men nu har vi de yderligere afhængigheder af netværket og de to front-end virtualiseringsnoder. Hver af disse komponenter er mere pålidelig end den skrøbelige delte storage (alt med mekaniske drev vil være skrøbeligt), men at de er lavere risiko er ikke problemet; problemet er, at risiciene er kombinatoriske.

Hvis nogen af disse tre komponenter (storage, netværk eller front-end-noderne) fejler, fejler alt. Løsningen på dette er at gøre den delte storage redundant alene og at gøre netværket redundant alene. Med tilstrækkeligt arbejde kan vi overvinde skrøbeligheden og risikoen, vi introducerede ved at tilføje delt storage, men den delte storage alene er ikke en form for risikobegrænsning, men en risiko i sig selv, som skal begrænses. Kompleksitetsspiralen begynder, og de omkostninger, der er forbundet med at bringe dette nye system op på niveau med pålideligheden af det oprindelige, enkle serversystem, kan være astronomiske.

Nu hvor vi har al denne redundans, har vi én mere risiko at bekymre os om. At administrere al denne redundans, alle disse bevægelige dele, kræver langt mere viden, kompetence og forberedelse end at administrere en simpel, enkelt server. Vi er gået fra en enkel løsning til en meget kompleks. I min egen anekdotiske erfaring er de reelle farer ved løsninger som denne ikke, at hardwaren fejler, men menneskelige fejl. Ikke blot er der gjort lidt for at undgå, at menneskelige fejl får dette nye system til at fejle, men vi har tilføjet utallige punkter, hvor et menneske utilsigtet kan bringe hele systemet, redundans og det hele, ned. Jeg har set det på første hånd; jeg har hørt rædselhistorierne. Jo mere komplekst systemet er, jo mere sandsynligt er det, at et menneske ved et uheld ødelægger det hele.

Det er afgørende, at vi som IT-professionelle træder tilbage og ser på komplette systemer og overvejer pålidelighed og risiko og tænker på redundans som blot et værktøj til brug i jagten på pålidelighed. Redundans i sig selv er ikke en universalløsning. Det er enkelhed heller ikke. Pålidelighed er et komplekst problem at tackle. At undgå simplificerede erstatninger er et vigtigt første skridt i bevægelsen fra at tildække pålidelighedsproblemer til at stå over for og løse dem.