Historien om array-oppdeling

Mye av den innlærte kunnskapen i IT-bransjen, spesielt innen SMB-feltet, oppsto på slutten av 1990-tallet basert på en rekke faktorer. De største faktorene var at stadig mindre og mindre bedrifter plutselig skyndte seg å datamatisere seg, Microsoft hadde gjort Windows NT 4 så stabilt at det fantes et standardgrunnlag som all SMB-IT kunne sentreres rundt, internettepoken hadde endelig fått fotfeste, og Microsoft introduserte sine sertifiserings- og opplæringsprogrammer som omformet kunnskapsformidlingen i bransjen. Til sammen skapte dette både et behov for ny opplæring og beste praksis, og forårsaket en massiv eksplosjon av ny tenkning, skriving, dokumentasjon, opplæring, beste praksis, tommelfingerregler osv.

I noen år ble nesten hele bransjen opplært på det samme lille kunnskapssettet, og mange tommelfingerregler ble de facto standarder, og mye av datidens kunnskap ble lært utenat og overlevert fra mentor til lærling i en syklus som flyttet mye av den tekniske kunnskapen fra 1998 inn i de ubestridte, hugget-i-stein-prosessene fra 2012. På den tiden var dette effektivt fordi praksisene var relevante, men det var femten år siden – teknologi, økonomi, brukstilfeller og kunnskap har endret seg betydelig siden den gang.

Et av de beste eksemplene på dette var den berømte Microsoft SQL Server-anbefalingen om RAID 1 for operativsystemet, RAID 5 for databasefilene og en annen RAID 1 for loggene. Dette oppsettet har vedvart gjennom nesten hele produktets levetid og ble så godt fremmet at det har spredt seg til nesten alle aspekter av serverdesign i SMB-segmentet. Bruken av RAID 1 for operativsystemet og RAID 5 for data er så utbredt at den ofte rett og slett antas uten noen vurdering av hvorfor dette ble anbefalt på den tiden.

La oss undersøke historien og se hvorfor R1/5/1 var god i 1998 og hvorfor den ikke bør eksistere i dag. Behold litt perspektiv i minnet – gapet mellom når disse anbefalingene først kom ut (så tidlig som i 1995) sammenlignet med i dag er enormt. Gå tilbake, mentalt, til 1995 og tenk på det tilsvarende gapet på den tiden. Det ville ha vært som å bruke anbefalinger i den tidlige internettepoken basert på hjemmedatabehov for de første Apple ][-eierne! Den 8-biters hjemmedatamaskinæraen hadde så vidt begynt i 1978. Commodore var fortsatt to år unna å gi ut sin første hjemmedatamaskin (VIC-20) og ville gjennomgå hele Commodore- og Commodore Amiga-æraen og gå konkurs og forsvinne – alt før 1995. Apple ][+ var fortsatt et år unna. Folk var i ferd med å begynne å bruke analoge kassettstasjoner som lagring. COBOL og Fortran var de eneste seriøse forretningsspråkene i bruk. Gapet er med andre ord utrolig. Ting forandrer seg.

Først må vi se på faktorene som eksisterte på slutten av 1990-tallet og som skapte behovet for vårt historiske oppsett.

1. Diskene var små, veldig små. Et stort database-array kunne ha bestått av fire 2,1 GB SCSI-disker i et R5-array for bare ~6 GB brukbar lagringsplass på ett enkelt array. Feildomenet for paritetsfeil i RAID var lite (sammenlignet med ting som URE-feilrater).
2. Diskforbindelsesteknologiene var parallelle og trege. Harddiskene fra den tiden var bare litt tregere enn disker er i dag, men forbindelsesteknologiene representerte en betydelig flaskehals. Det var vanlig å dele trafikk for å redusere busflaskehalser.
3. SCSI-diskteknologi var den eneste som ble brukt til servere. Bruk av PATA (IDE som det ble kalt på den tiden) i en server var utenkelig.
4. Disker var dyre per gigabyte, så kostnadsbesparelse var det viktigste, mens man opprettholdt kapasitet, for praktisk talt alle virksomheter.
5. Filsystemer var skjøre og feilet oftere enn disker.
6. Maskinvare-RAID var påkrevd og bare de grunnleggende RAID-nivåene 1 og 5 var allment tilgjengelige. RAID 6 og RAID 10 var år unna å være tilgjengelige for de fleste bedrifter. RAID 0 ses bort fra da det ikke har noen redundans.
7. Lagringssystemer ble sjelden, om noensinne, delt mellom servere, så tilgangen var nesten alltid dedikert til én enkelt forespørselskø.
8. Lagringsbuffere var små eller eksisterte ikke, noe som gjorde at disktilgangsbegrensninger ble direkte overført til operativsystemet. Dette betydde at man måtte ha forskjellige arrayer med forskjellige egenskaper for å håndtere ulike lese-/skrive- eller tilfeldig/sekvensielle tilgangsmikser.
9. Diskfeil var vanlig og den primære bekymringen ved design av lagringssystemer.
10. Størrelsen på diskarray var ofte begrenset av fysiske begrensninger, så array-oppdeling ble ofte gjort av nødvendighet, ikke av valg.
11. En kombinasjon av faktorene ovenfor betydde at RAID 1 var best for noen deler av systemet der liten størrelse var akseptabelt og tilgangen var svært sekvensiell eller skrivtung, og RAID 5 var best for andre der kapasitet overskygget pålitelighet og der tilgangen var svært tilfeldig og lesetung.

I de nesten to tiårene siden de opprinnelige anbefalingene ble gitt ut, har alle disse faktorene endret seg. I noen tilfeller er endringene kaskaderende der overgangen fra generell bruk av RAID 5 til generell bruk av RAID 10 har ført til at de to vanlige arraytypene, RAID 1 og RAID 10, deler tilgangsegenskaper, slik at behovet for eller ønsket om å bruke den ene eller den andre avhengig av belastningstype er borte.

1. Disker er nå enorme. I stedet for å slite med å få plass til det vi trenger på dem, har vi generelt overkapasitet. Enkeltdisker på over en terabyte er vanlige, også i servere. Feildomener for paritet er massive (sammenlignet med ting som URE-feilrater).
2. Diskforbindelser er serielle og raske. Diskforbindelsene er ikke lenger en flaskehals.
3. SATA er nå vanlig på servere, noe som skjevfordeler potensielle risikoer for URE på en måte som ikke eksisterte tidligere.
4. Kapasitet er nå billig, men ytelse og pålitelighet er nå de viktigste bekymringene for pengene brukt.
5. Filsystemer er svært robuste i dag og filsystemfeil er «bakgrunnsstøy» i det større bildet av array-pålitelighet.
6. Maskinvare-RAID og programvare-RAID er begge alternativer i dag og tilgjengelige RAID-nivåer inkluderer mange alternativer, men viktigst av alt er RAID 10 allment tilgjengelig.
7. Lagringssystemer er vanligvis delte, noe som gjør sekvensiell tilgang enda mindre vanlig.
8. Lagringsbuffere er vanlige og ofte svært store. 512 MB og 1 GB buffere anses som normalt i dag, noe som gjør at mange arrayer fra 1995 ville få plass helt i minnet på RAID-kontrolleren i dag. Med buffere som vokser raskt sammenlignet med lagringskapasitet og den nylige tillegg av solid state-disker som L2-buffer i lagring de siste to årene, er det ikke utenkelig at selv en liten bedrift kan ha databaser og andre ytelsessensitive applikasjoner som kjøres helt fra buffer.
9. Diskfeil er uvanlige og av triviell bekymring for lagringssystemdesign (sammenlignet med andre feiltyper).
10. Størrelsen på diskarray er sjelden begrenset av fysiske begrensninger.
11. Bruken av RAID 1 og RAID 10 som de viktigste arraytypene i dag betyr at det ikke er noen fordel ved å bruke forskjellige array-nivåer for ytelsestuning.

Disse faktorene belyser hvorfor det delte arraysystemet fra 1995 ga perfekt mening på den tiden og hvorfor det ikke gir mening i dag. OBR10, dagens standard, var utilgjengelig på den tiden og kostnadsforbudende. RAID 5 var relativt trygt i 1995, men ikke i dag. Nesten alle faktorer involvert i beslutningsprosessen har endret seg dramatisk de siste sytten årene og vil fortsette å endres ettersom SSD blir mer vanlig sammen med automatisk nivådeling, enda større buffere og rene SSD-lagringssystemer.

Endringen i lagringsdesign de siste to tiårene belyser også farene IT-bransjen står overfor ettersom en stor del av bransjen lærer, som er vanlig innen ingeniørvitenskap, grunnleggende «tommelfingerregler» eller «beste praksis» uten nødvendigvis å forstå de underliggende prinsippene som driver disse beslutningene, noe som gjør det vanskelig å vite når man ikke skal anvende disse beste praksisene, eller enda viktigere, når man skal erkjenne at regelen ikke lenger gjelder. I motsetning til tradisjonell mekanisk eller byggteknisk ingeniørvitenskap, der nye fremskritt og betydelige faktorer kan forekomme én gang eller muligens aldri i løpet av en karriere, forandrer IT seg fortsatt raskt nok til at fullstendige «nytenkniger» av grunnleggende tommelfingerregler er nødvendige flere ganger i løpet av en karriere. Kanskje ikke årlig, men én gang per tiår eller mer er nesten alltid nødvendig.

Den nåværende overgangen fra uniprocessing til flertrådede arkitekturer er en annen tilsvarende, betydelig endring som krever at IT-bransjen fullstendig endrer hvordan systemdesign håndteres.