De geschiedenis van het opsplitsen van arrays

Een groot deel van de routinekennis van het IT-vakgebied, en met name die van het mkb-segment, ontstond in de zeer late jaren negentig op basis van uiteenlopende factoren. De grootste factoren waren dat plotseling steeds kleinere bedrijven zich haastten om te computeriseren, Microsoft Windows NT 4 zo stabiel had gekregen dat er een standaardbasis was waar alle mkb-IT zich omheen kon centreren, het internettijdperk eindelijk vaste voet aan de grond had gekregen en Microsoft hun certificerings- en trainingsprogramma's introduceerde die de kennisverspreiding in de branche hervormden. Samengenomen creëerde dit zowel een behoefte aan nieuwe training en best practices als een enorme uitbarsting van nieuw denken, schrijven, documentatie, training, best practices, vuistregels, enzovoort.

Gedurende een paar jaar werd vrijwel het hele vakgebied opgeleid op dezelfde kleine kennisverzameling en werden veel vuistregels de facto standaarden, en veel van de kennis uit die tijd werd uit het hoofd geleerd en doorgegeven van mentor op stagiair, in een cyclus die veel van de technische kennis van 1998 verschoof naar de onbetwiste, in steen gebeitelde processen van 2012. Destijds was dit effectief omdat de praktijken relevant waren, maar dat was vijftien jaar geleden; technologie, economie, gebruiksscenario's en kennis zijn sindsdien aanzienlijk veranderd.

Een van de beste voorbeelden hiervan was de beroemde aanbeveling van Microsoft SQL Server: RAID 1 voor het besturingssysteem, RAID 5 voor de databasebestanden en nog een RAID 1 voor de logs. Deze opzet heeft vrijwel de gehele levensduur van het product standgehouden en werd zo goed gepromoot dat ze zich heeft verspreid naar bijna alle aspecten van serverontwerp in het mkb-segment. Het gebruik van RAID 1 voor het besturingssysteem en RAID 5 voor data is zo alomtegenwoordig dat het vaak simpelweg wordt aangenomen, zonder enige overweging waarom dit destijds werd aanbevolen.

Laten we de geschiedenis onderzoeken en zien waarom R1/5/1 in 1998 goed was en waarom het vandaag de dag niet zou moeten bestaan. Houd enig perspectief in gedachten: de kloof tussen het moment waarop deze aanbevelingen voor het eerst verschenen (al in 1995) vergeleken met nu, is immens. Ga, in gedachten, terug naar 1995 en denk na over de equivalente kloof in die tijd. Dat zou zijn geweest als het gebruiken van aanbevelingen in het vroege internettijdperk gebaseerd op de thuiscomputerbehoeften van de eerste lichting Apple ][-bezitters! Het 8bit-thuiscomputertijdperk was in 1978 nog maar net begonnen. Commodore was nog twee jaar verwijderd van het uitbrengen van hun eerste thuiscomputer (de VIC=20) en zou de gehele Commodore- en Commodore Amiga-tijdperken doorlopen en failliet gaan en verdwijnen, allemaal vóór 1995. De Apple ][+ was nog een jaar weg. Mensen stonden op het punt om analoge cassettedrives als opslag te gaan gebruiken. COBOL en Fortran waren de enige serieuze zakelijke talen die in gebruik waren. Kortom, de kloof is ongelofelijk. Dingen veranderen.

Eerst moeten we kijken naar de factoren die in de late jaren negentig bestonden en die de behoefte aan onze historische opzet creëerden.

1. Schijven waren klein, heel klein. Een grote database-array bestond mogelijk uit vier 2,1GB SCSI-schijven in een R5-array voor slechts ~6GB aan bruikbare opslagruimte op één enkele array. Het faaldomein voor het falen van parity RAID was minuscuul (vergeleken met zaken als URE-faalpercentages.)
2. Schijfverbindingstechnologieën waren parallel en traag. De harde schijven van die tijd waren slechts iets trager dan de schijven van vandaag, maar de verbindingstechnologieën vormden een aanzienlijk knelpunt. Het was gangbaar om verkeer op te splitsen om busknelpunten te verminderen.
3. SCSI-schijftechnologie was de enige die voor servers werd gebruikt. Het gebruik van een PATA (toen IDE genoemd) in een server was ondenkbaar.
4. Schijven waren duur per gigabyte, dus kostenbesparing was het sleutelvraagstuk, met behoud van capaciteit, voor vrijwel alle bedrijven.
5. Bestandssystemen waren kwetsbaar en faalden vaker dan schijven.
6. Hardware-RAID was vereist en alleen de basale RAID-niveaus 1 en 5 waren algemeen beschikbaar. RAID 6 en RAID 10 waren nog jaren verwijderd van toegankelijkheid voor de meeste bedrijven. RAID 0 wordt buiten beschouwing gelaten omdat het geen redundantie heeft.
7. Opslagsystemen werden zelden, of nooit, gedeeld tussen servers, dus de toegang was vrijwel altijd toegewijd aan één enkele aanvraagwachtrij.
8. Opslagcaches waren minuscuul of bestonden niet, waardoor de beperkingen van schijftoegang rechtstreeks werden doorgegeven aan het besturingssysteem. Dit betekende dat je verschillende arrays met verschillende eigenschappen moest hebben om verschillende mengsels van lees-/schrijf- of willekeurige/sequentiële toegang aan te kunnen.
9. Schijfuitval kwam vaak voor en was de voornaamste zorg bij het ontwerp van opslagsystemen.
10. Vaak werd de grootte van de schijfarray beperkt door fysieke beperkingen, zodat beslissingen over het opsplitsen van arrays vaak uit noodzaak werden genomen, niet uit keuze.
11. Een combinatie van bovenstaande factoren betekende dat RAID 1 het beste was voor sommige delen van het systeem waar een kleine omvang aanvaardbaar was en de toegang sterk sequentieel of schrijfintensief was, en RAID 5 het beste was voor andere delen waar capaciteit zwaarder woog dan betrouwbaarheid en waar de toegang sterk willekeurig en leesintensief was.

In de bijna twee decennia sinds de oorspronkelijke aanbevelingen werden uitgebracht, zijn al deze factoren veranderd. In sommige gevallen zijn de veranderingen cascaderend, waarbij de verschuiving van algemeen gebruik van RAID 5 naar algemeen gebruik van RAID 10 er vervolgens toe heeft geleid dat wat de twee gangbare arraytypes zouden zijn geweest, RAID 1 en RAID 10, dezelfde toegangseigenschappen delen, zodat de behoefte of wens om afhankelijk van het belastingstype het ene of het andere te gebruiken is verdwenen.

1. Schijven zijn nu enorm. In plaats van te worstelen om erop te persen wat we nodig hebben, hebben we over het algemeen overtollige capaciteit. Enkele schijven van meer dan een terabyte zijn gangbaar, zelfs in servers. Faaldomeinen voor parity zijn enorm (vergeleken met zaken als URE-faalpercentages.)
2. Schijfverbindingen zijn serieel en snel. De schijfverbindingen vormen niet langer een knelpunt.
3. SATA is nu gangbaar op servers, wat de potentiële risico's voor URE scheeftrekt op een manier die voorheen niet bestond.
4. Capaciteit is nu goedkoop, maar prestaties en betrouwbaarheid zijn nu de sleutelzorgen voor de uitgegeven euro's.
5. Bestandssystemen zijn tegenwoordig uiterst robuust en bestandssysteemfalen is “achtergrondruis” in het grotere geheel van arraybetrouwbaarheid.
6. Hardware-RAID en software-RAID zijn tegenwoordig beide opties en de beschikbare RAID-niveaus omvatten vele opties, maar, het allerbelangrijkst, RAID 10 is alomtegenwoordig beschikbaar.
7. Opslagsystemen worden vaak gedeeld, waardoor sequentiële toegang nog minder gangbaar is.
8. Opslagcaches zijn gangbaar en vaak zeer groot. Caches van 512MB en 1GB worden tegenwoordig als normaal beschouwd, waardoor veel arrays uit 1995 vandaag de dag volledig in het geheugen van de RAID-controller passen. Nu caches snel groeien vergeleken met opslagcapaciteit en met de recente toevoeging van solid-state schijven als L2-cache in opslag in de afgelopen twee jaar, is het niet ondenkbaar dat zelfs een klein bedrijf databases en andere prestatiegevoelige toepassingen volledig vanuit cache laat draaien.
9. Schijfuitval komt zelden voor en is van triviaal belang voor het ontwerp van opslagsystemen (vergeleken met andere faaltypes.)
10. De grootte van schijfarrays wordt zelden beperkt door fysieke beperkingen.
11. Het gebruik van RAID 1 en RAID 10 als de voornaamste arraytypes van vandaag betekent dat er geen voordeel is aan het gebruik van verschillende arrayniveaus voor prestatie-afstemming.

Deze factoren benadrukken waarom het opgesplitste arraysysteem van 1995 destijds volkomen logisch was en waarom het vandaag de dag geen zin heeft. OBR10, de huidige standaard, was destijds niet beschikbaar en te kostbaar. RAID 5 was in 1995 relatief veilig, maar vandaag de dag niet. Vrijwel elke factor die bij het beslissingsproces betrokken is, is in de afgelopen zeventien jaar drastisch veranderd en zal blijven veranderen naarmate SSD gangbaarder wordt, samen met auto-tiering, nog grotere caches en pure SSD-opslagsystemen.

De verandering in opslagontwerp gedurende de afgelopen twee decennia benadrukt ook de gevaren waarmee de IT wordt geconfronteerd doordat een groot deel van het vakgebied, zoals gangbaar is in de techniek, basale “vuistregels” of “best practices” leert zonder noodzakelijkerwijs de onderliggende principes te begrijpen die deze beslissingen sturen, waardoor het moeilijk wordt om te weten wanneer die best practices niet moeten worden toegepast of, nog belangrijker, wanneer te onderkennen dat de regel niet langer van toepassing is. In tegenstelling tot de traditionele werktuigbouwkunde of civiele techniek, waar nieuwe ontwikkelingen en significante factorveranderingen zich misschien eenmaal of mogelijk nooit voordoen gedurende een loopbaan, verandert de IT nog steeds snel genoeg dat volledige “heroverwegingen” van basale vuistregels meerdere malen gedurende een loopbaan vereist zijn. Misschien niet jaarlijks, maar eenmaal per decennium of vaker is vrijwel altijd noodzakelijk.

De huidige verschuiving van uniprocessing naar multithreaded architecturen is nog zo'n vergelijkbare, significante verandering die het IT-vakgebied dwingt om de wijze waarop systeemontwerp wordt aangepakt volledig te veranderen.