Historien om Array-opdeling

Meget af den indlærte viden inden for IT-feltet, især inden for SMB-feltet, opstod i de allersene 1990'ere baseret på en række faktorer. De største faktorer var, at stadig mindre og mindre virksomheder pludselig skyndte sig at computerisere, Microsoft havde gjort Windows NT 4 så stabilt, at der var et standardgrundlag for al SMB IT at centrere sig om, internetæraen var endelig slået igennem, og Microsoft introducerede deres certificerings- og træningsprogrammer, der omformede vidensformidlingen i branchen. Tilsammen skabte dette både et behov for ny uddannelse og bedste praksis og medførte en massiv bølge af ny tænkning, skrivning, dokumentation, træning, bedste praksis, tommelfingerregler og så videre.

I et par år blev næsten hele feltet uddannet på det samme lille vidensgrundlag, og mange tommelfingerregler blev de facto-standarder, og meget af tidens viden blev lært udenad og videregivet fra mentor til praktikant i en cyklus, der førte meget af den tekniske viden fra 1998 ind i de uomtvistede, fastsatte processer fra 2012. På det tidspunkt var det effektivt, fordi praksisserne var relevante, men det var femten år siden – teknologi, økonomi, anvendelsestilfælde og viden har ændret sig betydeligt siden da.

Et af de bedste eksempler på dette var den berømte Microsoft SQL Server-anbefaling om RAID 1 til operativsystemet, RAID 5 til databasefilerne og endnu en RAID 1 til loggene. Denne opsætning har bestået i næsten hele produktets levetid og var så godt promoveret, at den har spredt sig til næsten alle aspekter af serverdesign i SMB-segmentet. Brugen af RAID 1 til operativsystemet og RAID 5 til data er så udbredt, at den ofte blot forudsættes uden nogen overvejelse af, hvorfor dette blev anbefalet på det tidspunkt.

Lad os undersøge historien og se, hvorfor R1/5/1 var god i 1998, og hvorfor den ikke bør eksistere i dag. Hold noget perspektiv for øje – kløften mellem hvornår disse anbefalinger først kom ud (så tidligt som i 1995) sammenlignet med i dag er enorm. Gå mentalt tilbage til 1995 og tænk over den tilsvarende kløft på det tidspunkt. Det ville have været som at bruge anbefalinger i den tidlige internetalder baseret på hjemmecomputer­behov for de første ejere af Apple ][! 8-bit hjemmecomputeræraen var knap begyndt i 1978. Commodore var stadig to år fra at udgive deres første hjemmecomputer (VIC-20) og ville gennemgå hele Commodore- og Commodore Amiga-æraerne og gå konkurs og forsvinde inden 1995. Apple ][+ var stadig et år væk. Folk var lige ved at begynde at bruge analoge kassettedrev som lager. COBOL og Fortran var de eneste seriøse forretningsprogrammeringssprog i brug. Grundlæggende er kløften utrolig. Ting ændrer sig.

Først er vi nødt til at se på de faktorer, der eksisterede i de sene 1990'ere, som skabte behovet for vores historiske opsætning.

1. Diske var små, meget små. Et stort database-array kunne have bestået af fire 2,1 GB SCSI-diske i et R5-array for blot ~6 GB anvendeligt lagerplads på et enkelt array. Fejldomænet for paritetsfejl i RAID var lille (sammenlignet med ting som URE-fejlrater.)
2. Diskforbindelsesteknologier var parallelle og langsomme. Harddiskene på det tidspunkt var kun lidt langsommere end diske er i dag, men forbindelsesteknologierne repræsenterede en betydelig flaskehals. Det var almindeligt at opdele trafik for at muliggøre reducerede busflaskehalse.
3. SCSI-diskteknologi var den eneste, der blev brugt til servere. Brugen af en PATA (IDE som det hed på det tidspunkt) i en server var utænkelig.
4. Diske var dyre per gigabyte, så omkostningsbesparelser var det vigtigste spørgsmål, mens kapaciteten skulle opretholdes, for praktisk talt alle virksomheder.
5. Filsystemer var skrøbelige og fejlede oftere end diske.
6. Hardware-RAID var påkrævet, og kun grundlæggende RAID-niveauer på 1 og 5 var almindeligt tilgængelige. RAID 6 og RAID 10 var år fra at være tilgængelige for de fleste virksomheder. RAID 0 fraregnes, da det ikke har nogen redundans.
7. Lagersystemer var sjældent, hvis nogensinde, delt mellem servere, så adgang var næsten altid dedikeret til en enkelt anmodningskø.
8. Lagercaches var meget lille eller eksisterede ikke, hvilket betød, at diskadgangsbegrænsninger passerede direkte til operativsystemet. Dette betød, at man skulle have forskellige arrays med forskellige karakteristika til at håndtere forskellige læse/skrive- eller tilfældig/sekventiel adgangsmiks.
9. Diskfejl var almindeligt og den primære bekymring for lagerssystemdesign.
10. Ofte var diskarray-størrelse begrænset af fysiske begrænsninger, så array-opdelingsbeslutninger blev ofte truffet af nødvendighed, ikke af valg.
11. En kombination af ovenstående faktorer betød, at RAID 1 var bedst til visse dele af systemet, hvor lille størrelse var acceptabelt og adgang var stærkt sekventiel eller skrivetung, og RAID 5 var bedst til andre, hvor kapacitet vejede tungere end pålidelighed, og hvor adgang var stærkt tilfældig og læsetung.

I de næsten to årtier siden de oprindelige anbefalinger blev udgivet, har alle disse faktorer ændret sig. I nogle tilfælde er ændringerne kaskadevirkninger, hvor overgangen fra generelt anvendt RAID 5 til generelt anvendt RAID 10 derefter har medført, at de to der ville have været de fælles arraytyper, RAID 1 og RAID 10, deler adgangskarakteristika, så behovet for eller ønsket om at bruge den ene eller den anden afhængigt af belastningstype er forsvundet.

1. Diske er nu massive. I stedet for at kæmpe for at presse det vi har brug for ind på dem, har vi generelt overskydende kapacitet. Enkeltdiske over en terabyte er almindelige, selv i servere. Fejldomæner for paritet er massive (sammenlignet med ting som URE-fejlrater.)
2. Diskforbindelser er serielle og hurtige. Diskforbindelserne er ikke længere en flaskehals.
3. SATA er nu almindeligt på servere, hvilket skæver potentielle risici for URE på en måde, der ikke eksisterede tidligere.
4. Kapacitet er nu billig, men ydeevne og pålidelighed er nu de vigtigste bekymringer for penge brugt.
5. Filsystemer er meget robuste i dag, og filsystemfejl er “baggrundsstøj” i det større billede af array-pålidelighed.
6. Hardware-RAID og software-RAID er begge muligheder i dag, og tilgængelige RAID-niveauer inkluderer mange muligheder, men vigtigst af alt er RAID 10 allestedsnærværende tilgængeligt.
7. Lagersystemer er generelt delt, hvilket gør sekventiel adgang endnu mindre almindelig.
8. Lagercaches er almindelige og ofte meget store. 512 MB og 1 GB caches betragtes som normale i dag, hvilket gør mange arrays fra 1995 til at passe fuldstændigt ind i hukommelsen på RAID-controlleren i dag. Med caches, der vokser hurtigt sammenlignet med lagerkapacitet og den nylige tilføjelse af solid state-diske som L2-cache i lagring i de seneste to år, er det ikke utænkeligt for selv en lille virksomhed at have databaser og andre ydeevnefølsomme applikationer kørende fuldstændig fra cache.
9. Diskfejl er ualmindelige og en triviel bekymring for lagerssystemdesign (sammenlignet med andre fejltyper.)
10. Diskarray-størrelse er sjældent begrænset af fysiske begrænsninger.
11. Brugen af RAID 1 og RAID 10 som de primære arraytyper i dag betyder, at der ikke er nogen fordel ved at bruge forskellige array-niveauer til performance-tuning.

Disse faktorer fremhæver, hvorfor det opdelte arraysystem fra 1995 gav fuldkommen mening på det tidspunkt, og hvorfor det ikke giver mening i dag. OBR10, nutidens standard, var utilgængeligt på det tidspunkt og omkostningsforbudt. RAID 5 var relativt sikkert i 1995, men ikke i dag. Næsten alle faktorer involveret i beslutningsprocessen har ændret sig dramatisk i de sidste sytten år og vil fortsætte med at ændre sig, efterhånden som SSD bliver mere almindeligt sammen med auto-tiering, endnu større caches og rene SSD-lagersystemer.

Ændringen i lagerdesign over de seneste to årtier fremhæver også de farer, IT står over for, da en stor del af feltet lærer, som det er almindeligt i ingeniørfaget, grundlæggende “tommelfingerregler” eller “bedste praksis” uden nødvendigvis at forstå de underliggende principper, der driver disse beslutninger, hvilket gør det svært at vide, hvornår man ikke skal anvende disse bedste praksisser, eller endnu vigtigere, hvornår man skal erkende, at reglen ikke længere gælder. I modsætning til traditionel mekanisk eller civil ingeniørvidenskab, hvor nye fremskridt og betydelige faktorændringer måske sker én gang eller muligvis aldrig i løbet af en karriere, ændrer IT sig stadig hurtigt nok til, at komplette “gentænkninger” af grundlæggende tommelfingerregler er nødvendige adskillige gange i løbet af en karriere. Måske ikke hvert år, men én gang per årti eller oftere er næsten altid nødvendigt.

Den igangværende overgang fra uniprocessering til flertrådet arkitektur er en anden lignende, betydelig ændring, der kræver, at IT-feltet fuldstændigt ændrer, hvordan systemdesign håndteres.