Én stor RAID 10 – en ny standard for serverlagring

På slutten av 1990-tallet var tommelfingerregelen for å bygge en ny server å plassere operativsystemet på sitt eget, lille RAID 1-array og skille ut applikasjoner og data i et separat RAID 5-array. Dette ble gjort av flere årsaker, hvorav mange har forsvunnet fra vår bevissthet, tapt i tidens sand. De viktigste drivkrefter var at lagringskapasitet var ekstremt dyr, disker var små, filsystemer ble ødelagt regelmessig og fysiske harddisker sviktet i mye høyere grad sammenlignet med andre typer feil. Folk ble drevet av behovet for å beskytte mot fysiske harddiskfeil, beskytte mot filsystemkorrupsjon og skaffe tilstrekkelig kapasitet til å dekke behovene sine.

I dag har lagringslandskapet endret seg. Filsystemer er utrolig robuste og korrupsjon fra selve filsystemet er nesten uhørt, og takket være teknologier som journalføring kan det nesten alltid korrigeres raskt og effektivt, slik at sluttbrukere beskyttes mot datatap. Nesten ingen bekymrer seg om filsystemkorrupsjon i dag.

Moderne filsystemer er også i stand til å håndtere langt mer kapasitet enn de kunne tidligere. Det var ikke uvanlig på slutten av 1990-tallet og begynnelsen av 2000-tallet å ha muligheten til å enkelt lage et diskarray som var større enn ethvert enkelt filsystem kunne håndtere. I dag er ikke dette et reelt problem, ettersom alle vanlige filsystemer håndterer mange terabyte som minimum, og ofte petabyte, eksabyte eller mer med data.

Harddisker er langt mer pålitelige enn de var på slutten av 1990-tallet. Feilrater for en hel disk som svikter er svært lave, selv i billigere disker. Så lave, faktisk, at arrayfeil (datatap i hele RAID-arrayet) primært er opptatt av sviktende arrayer, snarere enn svikt i harddisker. Vi skifter ikke lenger harddisker med vill abandon. Det er ikke uvanlig at store arrayer kjører hele levetiden sin uten å miste en eneste disk.

Kapasiteter har skalert dramatisk. I stedet for 4,3 GB harddisker installerer vi 3 TB-disker. Nesten tusen ganger mer kapasitet på en enkelt spindel sammenlignet med for mindre enn femten år siden.

Disse faktorene samles for å skape et behov for en dramatisk annerledes tilnærming til serverlagringsdesign og en endring av «tommelfingerregelen» for hvor man skal starte når man designer lagring.

Den gamle tilnærmingen kan skrives RAID 1 + RAID 5. RAID 1-plassen ble brukt til operativsystemet mens RAID 5-plassen, antatt mye større, ble brukt til data og applikasjoner. Dette designet delte de to lagringshensynene og la maksimal innsats i å beskytte operativsystemet (som var svært vanskelig å gjenopprette ved katastrofe og som data var avhengig av for tilgjengelighet) på det svært pålitelige RAID 1. Rimeligere RAID 5, om enn noe mer risikabelt, ble valgt, typisk for data fordi kostnaden ved å lagre data på RAID 1 var for høy i de fleste tilfeller. Det var en avveining som ga mening på den tiden.

I dag, med våre svært forskjellige hensyn, trengs en ny tilnærming, og denne nye tilnærmingen er kjent som «Én stor RAID 10» – som betyr et enkelt, stort RAID 10-array med operativsystem, applikasjoner og data alle lagret sammen. Selvfølgelig er dette bare hva vi sier for enkelhets skyld; i et system uten behov for ytelse eller kapasitet utover en enkelt disk ville vi si «Én stor RAID 1», men mange inkluderer RAID 1 i RAID 10-gruppen, så det er bare enklere å si det førstnevnte.

For å gjøre det enda enklere forkorter vi dette til OBR10.

Fordi kostnaden for lagring har falt betydelig og i stedet for å være en mangelvare er typisk i overflod i dag, fordi filsystemer er utrolig pålitelige, fordi RAID 1 og RAID 10 deler ytelsesegenskaper og fordi arrayfeil utløst av ikke-diskfeil har gått fra bakgrunnsstøy til primære årsaker til datatap, har overgangen til RAID 10 og eliminering av array-splitting blitt den nye standardtilnærmingen.

Med RAID 10 har vi nå den svært tilgjengelige og robuste lagringen som tidligere bare var reservert for operativsystemet, tilgjengelig for alle dataene våre. Vi får fordelen av speilt RAID-ytelse pluss fordelen av ekstra spindler for alle dataene våre. Vi får bedre utnyttelse av diskkapasitet og ytelse basert på den forbedrede utnyttelsen.

Selv den tradisjonelle splittingen av loggfiler som normalt gjøres med databaser (den beryktede RAID 1 + RAID 5 + RAID 1-tilnærmingen) er ikke lenger nødvendig fordi RAID 10 opprettholder optimale ytelsesegenskaper på tvers av alle data. Med RAID 10 eliminerer vi nesten alle faktorene som en gang fikk oss til å dele arrayer.

Den eneste betydelige faktoren, som ikke er nevnt, der delte arrayer tradisjonelt ble sett som fordelaktige, er tilgangskontensjon – behovet for at ulike prosesser trenger tilgang til ulike deler av disken samtidig, noe som forårsaker at diskhodet beveger seg rundt i et mindre enn ideelt mønster, noe som reduserer diskytelsen. Kontensjon var et stort problem på slutten av 1990-tallet da den gamle tommelfingerregelen ble utviklet.

I dag eksisterer diskkontensjon fortsatt, men er kraftig redusert gjennom bruk av store RAID-cacher. På slutten av 90-tallet var diskcacher noen få megabyte i beste fall og ofte ikke-eksisterende. I dag er 256 MB en liten cache og gjennomsnittlige servere distribueres med 1-2 GB cache på RAID-kortet alene. Noen systemer begynner å integrere ytterligere solid state-baserte cacher for å legge til en sekundær cache utover minnecachen på kontrolleren. Disse kan enkelt legge til hundrevis av gigabyte med ekstremt høyhastighets cache som kan buffre nesten enhver spindel-operasjon fra å måtte bekymre seg om kontensjon. Så problemet med kontensjon er løst på andre måter over årene, men har, som andre teknologiendringer, effektivt frigjort oss fra de tradisjonelle bekymringene som krevde at vi delte arrayer.

Som arraykontensjon er en annen, langt mindre vanlig grunn til å dele arrayer på slutten av 1990-tallet at det forbedret kommunikasjonsbussytelsen på grunn av begrensningene i tidens SCSI- og ATA-teknologier. Disse har også blitt eliminert med overgangen til seriell kommunikasjonsmekanismer, SAS og SATA, i moderne arrayer. Vi er ikke lenger begrenset til kapasiteten til en enkelt buss for hvert array og kan vokse mye større med mye mer fleksibilitet enn tidligere. Busskontensjon er nesten fullstendig eliminert.

Hvis det er behov for å skille ut plass for beskyttelse, for eksempel loggfilevekst, kan dette oppnås gjennom partisjonering snarere enn gjennom fysisk array-splitting. Generelt bør du minimere partisjonering ettersom det øker overhead og reduserer diskenes evne til å optimalisere seg selv, men det finnes tilfeller der det er den bedre tilnærmingen. Men det krever ikke at den underliggende fysiske lagringen deles slik den tradisjonelt har vært. Enda bedre enn partisjonering, når det er tilgjengelig, er logisk volumhåndtering som gjør partisjons-lignende separasjoner uten begrensningene til partisjoner.

Så til syvende og sist er den nye tommelfingerregelen for serverlagring «Én stor RAID 10.» Ikke mer RAID 5, ikke mer array-splitting. Det handler om pålitelighet, ytelse, enkel administrasjon og moderat kostnadseffektivitet. Som alle tommelfingerregler gjelder ikke dette for absolutt alle tilfeller, men det gjelder mye bredere enn den gamle standarden noen gang gjorde. RAID 1 + RAID 5, som standard, var alltid et forsøk på å «klare seg» med noe uønsket og å gjøre det beste ut av en dårlig situasjon. OBR10 er ikke slik. Den nye standarden er en ønsket standard – det er slik vi faktisk ønsker å kjøre, ikke noe vi er blitt «sittende fast» med.

Når du designer lagring for en ny server, start med OBR10 og beveg deg bare bort fra det når det spesifikt ikke møter dine teknologibehov. Du bør aldri måtte rettferdiggjøre bruken av OBR10, bare rettferdiggjøre å ikke bruke det.