Historien om uppdelning av arrayer

Mycket av den inlärda kunskapen inom IT-fältet, särskilt inom SMB-fältet, uppstod i slutet av 1990-talet baserat på en rad faktorer. De största faktorerna var att allt mindre företag plötsligt rusade för att datorisera, att Microsoft hade fått Windows NT 4 så stabilt att det fanns en standardbas för all SMB-IT att samlas kring, att internetåldern äntligen hade fått fäste och att Microsoft introducerade sina certifierings- och utbildningsprogram som omformade kunskapsspridningen i branschen. Sammantaget skapade detta både ett behov av ny utbildning och bästa praxis och orsakade ett massivt utbrott av nytt tänkande, skrivande, dokumentation, utbildning, bästa praxis, tumregler etc.

Under några år utbildades nästan hela fältet på samma lilla kunskapsmängd och många tumregler blev de facto-standarder, och mycket av tidens kunskap lärdes in utantill och fördes vidare från mentor till praktikant i en cykel som flyttade mycket av den tekniska kunskapen från 1998 in i de oifrågasatta, huggna-i-sten-processerna år 2012. Vid den tiden var detta effektivt eftersom metoderna var relevanta, men det var för femton år sedan; teknik, ekonomi, användningsfall och kunskap har förändrats avsevärt sedan dess.

Ett av de bästa exemplen på detta var Microsofts berömda rekommendation för SQL Server: RAID 1 för operativsystemet, RAID 5 för databasfilerna och ytterligare en RAID 1 för loggarna. Denna konfiguration har bestått under nästan hela produktens livstid och marknadsfördes så väl att den har spridit sig till nästan alla aspekter av serverdesign inom SMB-området. Användningen av RAID 1 för operativsystemet och RAID 5 för data är så genomgripande att den ofta helt enkelt antas utan någon eftertanke om varför detta rekommenderades vid den tidpunkten.

Låt oss undersöka historien och se varför R1/5/1 var bra 1998 och varför det inte borde existera idag. Behåll lite perspektiv i åtanke; klyftan mellan när dessa rekommendationer först kom ut (så tidigt som 1995) jämfört med idag är enorm. Gå tillbaka, mentalt, till 1995 och tänk på den motsvarande klyftan vid den tiden. Det skulle ha varit som att i den tidiga internetåldern använda rekommendationer baserade på hemdatorbehoven hos den första vågen av Apple ][-ägare! Den 8-bitars hemdatoreran hade just så smått kommit igång 1978. Commodore var fortfarande två år från att släppa sin första hemdator (VIC-20) och skulle gå igenom hela Commodore- och Commodore Amiga-erorna och gå i konkurs och försvinna, allt före 1995. Apple ][+ var fortfarande ett år bort. Folk var precis på väg att börja använda analoga kassettbandspelare som lagring. COBOL och Fortran var de enda seriösa affärsspråken i bruk. I grund och botten är klyftan otrolig. Saker förändras.

Först måste vi titta på de faktorer som existerade i slutet av 1990-talet och som skapade behovet av vår historiska konfiguration.

1. Diskarna var små, mycket små. En stor databasarray kanske bestod av fyra 2,1 GB SCSI-diskar i en R5-array för bara ~6 GB användbart lagringsutrymme på en enda array. Feldomänen för paritets-RAID-fel var liten (jämfört med saker som URE-felfrekvenser.)
2. Anslutningstekniker för diskar var parallella och långsamma. Tidens hårddiskar var bara något långsammare än diskar är idag, men anslutningsteknikerna utgjorde en betydande flaskhals. Det var vanligt att dela upp trafiken för att möjliggöra minskade bussflaskhalsar.
3. SCSI-diskteknik var den enda som användes för servrar. Användningen av en PATA-disk (vid den tiden kallad IDE) i en server var otänkbar.
4. Diskar var dyra per gigabyte, så kostnadsbesparingar var den centrala frågan, samtidigt som kapaciteten skulle bibehållas, för praktiskt taget alla företag.
5. Filsystem var ömtåliga och fallerade oftare än diskar.
6. Hårdvaru-RAID krävdes och endast de grundläggande RAID-nivåerna 1 och 5 var allmänt tillgängliga. RAID 6 och RAID 10 var flera år från att vara åtkomliga för de flesta företag. RAID 0 bortses från eftersom det inte har någon redundans.
7. Lagringssystem delades sällan, om någonsin, mellan servrar, så åtkomsten var nästan alltid dedikerad till en enda begärningskö.
8. Lagringscacher var små eller existerade inte, vilket gjorde att begränsningar i diskåtkomst gick direkt vidare till operativsystemet. Detta innebar att man hade olika arrayer med olika egenskaper för att hantera olika blandningar av läs/skriv- eller slumpmässig/sekventiell åtkomst.
9. Diskfel var vanliga och den främsta angelägenheten vid design av lagringssystem.
10. Ofta begränsades arrayens storlek av fysiska begränsningar, så beslut om att dela upp arrayer fattades ofta av nödvändighet, inte av val.
11. En kombination av ovanstående faktorer innebar att RAID 1 var bäst för vissa delar av systemet där liten storlek var acceptabel och åtkomsten var mycket sekventiell eller skrivtung, och RAID 5 var bäst för andra där kapacitet vägde tyngre än tillförlitlighet och där åtkomsten var mycket slumpmässig och lästung.

Under de nästan två decennier som gått sedan de ursprungliga rekommendationerna släpptes har alla dessa faktorer förändrats. I vissa fall är förändringarna kaskadartade, där övergången från RAID 5 för allmänt bruk till RAID 10 för allmänt bruk sedan gör att de två vanliga arraytyperna, RAID 1 och RAID 10, delar åtkomstegenskaper, så behovet av eller önskan att använda den ena eller andra beroende på belastningstyp är borta.

1. Diskar är nu enorma. I stället för att kämpa för att klämma in det vi behöver på dem har vi i allmänhet överskottskapacitet. Enskilda diskar över en terabyte är vanliga, även i servrar. Feldomänerna för paritet är enorma (jämfört med saker som URE-felfrekvenser.)
2. Diskanslutningar är seriella och snabba. Diskanslutningarna är inte längre en flaskhals.
3. SATA är nu vanligt på servrar, vilket snedvrider de potentiella riskerna för URE på ett sätt som inte existerade tidigare.
4. Kapacitet är nu billigt men prestanda och tillförlitlighet är nu de centrala angelägenheterna för pengarna som spenderas.
5. Filsystem är mycket robusta idag och filsystemsfel är “bakgrundsbrus” i den större bilden av arrayens tillförlitlighet.
6. Hårdvaru-RAID och mjukvaru-RAID är båda alternativ idag och tillgängliga RAID-nivåer inkluderar många alternativ men, viktigast av allt, RAID 10 är allmänt tillgängligt.
7. Lagringssystem delas ofta, vilket gör sekventiell åtkomst ännu mindre vanlig.
8. Lagringscacher är vanliga och ofta mycket stora. Cacher på 512 MB och 1 GB anses normala idag, vilket gör att många arrayer från 1995 idag ryms helt i minnet på RAID-styrenheten. Med cacher som växer snabbt jämfört med lagringskapacitet och det senaste tillskottet av halvledardiskar (solid state) som L2-cache i lagring under de senaste två åren är det inte uteslutet att även ett litet företag har databaser och andra prestandakänsliga applikationer som körs helt från cache.
9. Diskfel är ovanliga och av trivial betydelse för design av lagringssystem (jämfört med andra feltyper.)
10. Arrayens storlek begränsas sällan av fysiska begränsningar.
11. Användningen av RAID 1 och RAID 10 som de huvudsakliga arraytyperna idag innebär att det inte finns någon fördel med att använda olika arraynivåer för prestandajustering.

Dessa faktorer belyser varför det uppdelade arraysystemet från 1995 var helt logiskt vid den tiden och varför det inte är logiskt idag. OBR10, dagens standard, var inte tillgängligt vid den tiden och var kostnadsmässigt oöverkomligt. RAID 5 var relativt säkert 1995, men inte idag. Nästan varje faktor som var inblandad i beslutsprocessen har förändrats dramatiskt under de senaste sjutton åren och kommer att fortsätta förändras när SSD blir vanligare tillsammans med automatisk nivåindelning (auto-tiering), ännu större cacher och rena SSD-lagringssystem.

Förändringen i lagringsdesign under de senaste två decennierna belyser också de faror som IT står inför när en stor del av fältet lär sig, som är vanligt inom ingenjörsvetenskapen, grundläggande “tumregler” eller “bästa praxis” utan att nödvändigtvis förstå de underliggande principer som driver dessa beslut, vilket gör det svårt att veta när man inte ska tillämpa dessa bästa praxis eller, ännu viktigare, när man ska inse att regeln inte längre gäller. Till skillnad från traditionell maskinteknik eller byggnadsteknik där nya framsteg och betydande faktorförändringar kan inträffa en gång eller möjligen aldrig under loppet av en karriär, förändras IT fortfarande snabbt nog för att fullständiga “omtänkanden” av grundläggande tumregler krävs flera gånger under en karriär. Kanske inte årligen, men en gång per decennium eller mer är nästan alltid nödvändigt.

Den nuvarande övergången från enkelbearbetning (uniprocessing) till flertrådade arkitekturer är ytterligare en liknande, betydande förändring som kräver att IT-fältet helt ändrar hur systemdesign hanteras.