One Big RAID 10 – en ny standard för serverlagring

I slutet av 1990-talet var den vedertagna tumregeln vid byggandet av en ny server att placera operativsystemet på en egen, liten RAID 1-array och separera ut applikationer och data till en separat RAID 5-array. Detta gjordes av flera skäl, av vilka många har glidit oss ur händerna, förlorade i tidens sand. De främsta drivkrafterna var att lagringskapacitet var extremt dyr, att diskar var små, att filsystem korrumperades regelbundet och att fysiska hårddiskar havererade i mycket hög grad jämfört med andra typer av fel. Människor drevs av ett behov av att skydda sig mot fysiska hårddiskhaverier, skydda sig mot filsystemskorruption och skaffa tillräcklig kapacitet för att möta sina behov.

Idag har lagringslandskapet förändrats. Filsystem är otroligt robusta och korruption från själva filsystemet är nästan oerhört och kan, tack vare teknologier som journalföring, nästan alltid korrigeras snabbt och effektivt, vilket skyddar slutanvändarna från dataförlust. Nästan ingen oroar sig för filsystemskorruption idag.

Moderna filsystem kan även hantera betydligt mer kapacitet än de tidigare kunde. Det var inte ovanligt i slutet av 1990-talet och början av 2000-talet att enkelt kunna göra en diskarray större än vad något enskilt filsystem kunde hantera. Idag är detta rimligen inte fallet, eftersom alla vanliga filsystem hanterar åtminstone många terabyte och ofta petabyte, exabyte eller mer av data.

Hårddiskar är mycket mer tillförlitliga än de var i slutet av 1990-talet. Felfrekvensen för att en hel disk havererar är mycket låg, även i billigare diskar. Så låg, faktiskt, att array-haverier (dataförlust i hela RAID-arrayen) primärt handlar om havererande arrayer snarare än om hårddiskhaverier. Vi byter inte längre ut hårddiskar i vild yra. Det är inte oerhört att stora arrayer löper hela sin livslängd utan att förlora en enda disk.

Kapaciteterna har skalat dramatiskt. Istället för 4,3 GB stora hårddiskar installerar vi 3 TB stora diskar. Nästan tusen gånger mer kapacitet på en enda spindel jämfört med för mindre än femton år sedan.

Dessa faktorer samverkar och skapar ett behov av ett dramatiskt annorlunda angreppssätt för utformning av serverlagring och en förändring av “tumregeln” om var man ska börja vid utformning av lagring.

Det gamla angreppssättet kan skrivas RAID 1 + RAID 5. RAID 1-utrymmet användes för operativsystemet medan RAID 5-utrymmet, förmodligen mycket större, användes för data och applikationer. Denna utformning delade upp de två lagringsbehoven och lade maximal kraft på att skydda operativsystemet (vilket var mycket svårt att återställa vid en katastrof och som data var beroende av för åtkomst) på högst tillförlitlig RAID 1. Billigare RAID 5, om än något riskablare, valdes vanligtvis för data eftersom kostnaden för att lagra data på RAID 1 var för hög i de flesta fall. Det var en avvägning som var rimlig vid den tiden.

Idag, med våra mycket annorlunda behov, krävs ett nytt angreppssätt, och detta nya angreppssätt kallas “One Big RAID 10” – vilket betyder en enda, stor RAID 10-array med operativsystem, applikationer och data lagrade tillsammans. Detta är förstås bara vad vi säger för att göra det smidigt; i ett system utan behov av prestanda eller kapacitet utöver en enda disk skulle vi säga “One Big RAID 1”, men många inkluderar RAID 1 i RAID 10-gruppen, så det är helt enkelt enklare att säga det förra.

För att vara ännu smidigare förkortar vi detta till OBR10.

Eftersom kostnaden för lagring har sjunkit avsevärt och istället för att vara en bristvara numera vanligtvis finns i överflöd, eftersom filsystem är otroligt tillförlitliga, eftersom RAID 1 och RAID 10 delar prestandaegenskaper, och eftersom array-haverier som utlöses av annat än diskhaverier har gått från bakgrundsbrus till primära orsaker till dataförlust, har övergången till RAID 10 och till att eliminera array-uppdelning blivit det nya standardangreppssättet.

Med RAID 10 har vi nu den högt tillgängliga och motståndskraftiga lagring som tidigare var förbehållen enbart operativsystemet tillgänglig för all vår data. Vi får fördelen av speglad RAID-prestanda plus fördelen av extra spindlar för all vår data. Vi får bättre utnyttjande av diskkapacitet och prestanda baserad på detta förbättrade utnyttjande.

Även den traditionella uppdelningen av loggfiler som normalt görs med databaser (den ökända metoden RAID 1 + RAID 5 + RAID 1) behövs inte längre eftersom RAID 10 bibehåller de optimala prestandaegenskaperna över all data. Med RAID 10 eliminerar vi nästan alla de faktorer som en gång fick oss att dela upp arrayer.

Den enda betydande faktorn, som ännu inte har nämnts och för vilken uppdelade arrayer traditionellt ansågs fördelaktiga, är åtkomstkonkurrens – behovet av att olika processer behöver åtkomst till olika delar av disken samtidigt, vilket får diskhuvudet att röra sig i ett mindre än idealiskt mönster och minskar diskprestandan. Konkurrens var en stor sak i slutet av 1990-talet när den gamla tumregeln utvecklades.

Idag finns diskkonkurrens fortfarande men har i stor utsträckning mildrats genom användningen av stora RAID-cachar. I slutet av 90-talet var diskcachar några megabyte i bästa fall och ofta obefintliga. Idag är 256 MB en pytteliten cache och genomsnittliga servrar levereras med 1–2 GB cache enbart på RAID-kortet. Vissa system börjar integrera ytterligare cachar baserade på solid state-diskar för att lägga till en sekundär cache utöver minnescachen på styrkortet. Dessa kan enkelt lägga till hundratals gigabyte extremt snabb cache som kan buffra nästan vilken spindeloperation som helst så att den inte behöver oroa sig för konkurrens. Frågan om konkurrens har alltså lösts på andra sätt genom åren men har, liksom andra teknikförändringar, i praktiken befriat oss från de traditionella behoven som krävde att vi delade upp arrayer.

Liksom array-konkurrens var ett annat, betydligt mindre vanligt skäl till att dela upp arrayer i slutet av 1990-talet att förbättra kommunikationsbussens prestanda på grund av begränsningarna i den tidens SCSI- och ATA-teknologier. Även dessa har eliminerats i och med övergången till seriella kommunikationsmekanismer, SAS och SATA, i moderna arrayer. Vi är inte längre begränsade till kapaciteten hos en enda buss för varje array och kan växa mycket större med mycket mer flexibilitet än tidigare. Busskonkurrens har nästan helt eliminerats.

Om det finns ett behov av att dela av utrymme för skydd, såsom tillväxt av loggfiler, kan detta uppnås genom partitionering snarare än genom fysisk array-uppdelning. I allmänhet vill du minimera partitionering eftersom det ökar omkostnaderna och minskar diskarnas förmåga att finjustera sig själva, men det finns fall där det är det bättre angreppssättet. Men det kräver inte att den underliggande fysiska lagringen delas upp som den traditionellt gjordes. Ännu bättre än partitionering, när det är tillgängligt, är logisk volymhantering som skapar partitionsliknande uppdelningar utan partitionernas begränsningar.

Så när allt kommer omkring är den nya tumregeln för serverlagring “One Big RAID 10.” Inget mer RAID 5, ingen mer array-uppdelning. Det handlar om tillförlitlighet, prestanda, enkel hantering och måttlig kostnadseffektivitet. Liksom alla tumregler gäller denna inte för varenda enskilt fall, men den gäller mycket bredare än den gamla standarden någonsin gjorde. RAID 1 + RAID 5 var som standard alltid ett försök att “klara sig” med något oönskat och att göra det bästa av en dålig situation. OBR10 är inte sådan. Den nya standarden är en önskad standard – det är så vi faktiskt vill köra, inte något vi har varit “fast” med.

När du utformar lagring för en ny server, börja med OBR10 och frångå det endast när det specifikt inte uppfyller dina tekniska behov. Du bör aldrig behöva motivera att använda OBR10, utan endast motivera att inte använda det.