Die Geschichte des Array-Splittings

Ein Großteil des angelernten Wissens im IT-Bereich, insbesondere im SMB-Bereich, entstand in den ausgehenden 1990er-Jahren auf der Grundlage einer Reihe von Faktoren. Die wichtigsten Faktoren waren, dass plötzlich immer kleinere Unternehmen sich beeilten, ihre Abläufe zu computerisieren, dass Microsoft Windows NT 4 so stabil gemacht hatte, dass es eine einheitliche Grundlage gab, um die sich die gesamte SMB-IT zentrieren konnte, dass das Internet-Zeitalter endlich Fuß gefasst hatte und dass Microsoft seine Zertifizierungs- und Schulungsprogramme einführte, welche die Wissensverbreitung in der Branche neu gestalteten. Zusammengenommen erzeugte dies sowohl einen Bedarf an neuen Schulungen und Best Practices als auch einen massiven Schub an neuem Denken, Schreiben, Dokumentation, Schulung, Best Practices, Faustregeln und so weiter.

Über einige Jahre hinweg wurde nahezu das gesamte Fachgebiet auf denselben kleinen Wissensbestand geschult, und viele Faustregeln wurden zu De-facto-Standards, und ein Großteil des damaligen Wissens wurde auswendig gelernt und von Mentor zu Praktikant weitergegeben, in einem Kreislauf, der einen Großteil des technischen Wissens von 1998 in die unhinterfragten, in Stein gemeißelten Prozesse von 2012 überführte. Damals war dies wirksam, weil die Praktiken relevant waren, doch das war vor fünfzehn Jahren; Technologie, Wirtschaft, Anwendungsfälle und Wissen haben sich seither erheblich verändert.

Eines der besten Beispiele hierfür war die berühmte Empfehlung von Microsoft für SQL Server: RAID 1 für das Betriebssystem, RAID 5 für die Datenbankdateien und ein weiteres RAID 1 für die Logs. Diese Konfiguration hat nahezu die gesamte Lebensdauer des Produkts überdauert und wurde so erfolgreich propagiert, dass sie sich in nahezu alle Aspekte des Serverdesigns im SMB-Bereich ausgebreitet hat. Die Verwendung von RAID 1 für das Betriebssystem und RAID 5 für Daten ist so weit verbreitet, dass sie häufig einfach vorausgesetzt wird, ohne dass man sich Gedanken darüber macht, warum dies seinerzeit empfohlen wurde.

Untersuchen wir die Geschichte und sehen wir, warum R1/5/1 im Jahr 1998 gut war und warum es heute nicht mehr existieren sollte. Behalten Sie dabei etwas Perspektive im Hinterkopf: Der Abstand zwischen dem ersten Aufkommen dieser Empfehlungen (bereits 1995) und heute ist gewaltig. Versetzen Sie sich gedanklich zurück ins Jahr 1995 und denken Sie an den entsprechenden Abstand zu jener Zeit. Das wäre so gewesen, als hätte man im frühen Internet-Zeitalter Empfehlungen verwendet, die auf den Heimcomputer-Bedürfnissen der ersten Generation von Apple-][-Besitzern beruhten! Die Ära der 8-Bit-Heimcomputer steckte 1978 gerade erst in den Anfängen. Commodore war noch zwei Jahre von der Veröffentlichung seines ersten Heimcomputers (dem VIC=20) entfernt und sollte die gesamte Ära von Commodore und Commodore Amiga durchlaufen, in Konkurs gehen und verschwinden – und das alles noch vor 1995. Der Apple ][+ war noch ein Jahr entfernt. Die Menschen begannen gerade erst, analoge Kassettenlaufwerke als Speicher zu nutzen. COBOL und Fortran waren die einzigen ernsthaften Geschäftssprachen, die im Einsatz waren. Im Grunde ist der Abstand unfassbar. Die Dinge verändern sich.

Zunächst müssen wir die Faktoren betrachten, die in den ausgehenden 1990er-Jahren bestanden und den Bedarf für unsere historische Konfiguration schufen.

1. Die Laufwerke waren klein, sehr klein. Ein großes Datenbank-Array bestand vielleicht aus vier 2,1-GB-SCSI-Laufwerken in einem R5-Array für gerade einmal ~6 GB nutzbaren Speicherplatz auf einem einzelnen Array. Der Fehlerbereich für einen Ausfall von Paritäts-RAID war winzig (verglichen mit Größen wie URE-Ausfallraten).
2. Die Laufwerksanbindungstechnologien waren parallel und langsam. Die Festplatten jener Zeit waren nur geringfügig langsamer als heutige Laufwerke, doch die Anbindungstechnologien stellten einen erheblichen Engpass dar. Es war üblich, den Datenverkehr aufzuteilen, um Bus-Engpässe zu verringern.
3. Die SCSI-Laufwerkstechnologie war die einzige, die für Server verwendet wurde. Der Einsatz eines PATA-Laufwerks (damals IDE genannt) in einem Server war undenkbar.
4. Laufwerke waren pro Gigabyte teuer, sodass Kosteneinsparung bei gleichzeitigem Erhalt der Kapazität für praktisch alle Unternehmen das zentrale Anliegen war.
5. Dateisysteme waren fragil und fielen häufiger aus als Laufwerke.
6. Hardware-RAID war erforderlich, und nur die grundlegenden RAID-Level 1 und 5 waren allgemein verfügbar. RAID 6 und RAID 10 waren für die meisten Unternehmen noch Jahre von der Zugänglichkeit entfernt. RAID 0 wird ausgeklammert, da es keine Redundanz bietet.
7. Speichersysteme wurden selten, wenn überhaupt, von mehreren Servern gemeinsam genutzt, sodass der Zugriff fast immer einer einzigen Anforderungswarteschlange vorbehalten war.
8. Speicher-Caches waren winzig oder existierten gar nicht, sodass die Beschränkungen des Laufwerkszugriffs unmittelbar an das Betriebssystem weitergegeben wurden. Dies bedeutete, dass man unterschiedliche Arrays mit unterschiedlichen Eigenschaften benötigte, um verschiedene Mischungen aus Lese-/Schreib- oder Zufalls-/Sequenzzugriffen zu bewältigen.
9. Laufwerksausfälle waren häufig und das zentrale Anliegen beim Design von Speichersystemen.
10. Häufig war die Größe eines Laufwerks-Arrays durch physische Beschränkungen limitiert, sodass Entscheidungen zum Array-Splitting oft aus Notwendigkeit und nicht aus freier Wahl getroffen wurden.
11. Eine Kombination der oben genannten Faktoren bedeutete, dass RAID 1 für manche Teile des Systems am besten geeignet war, bei denen eine geringe Größe akzeptabel war und der Zugriff stark sequenziell oder schreiblastig war, während RAID 5 für andere am besten geeignet war, bei denen die Kapazität die Zuverlässigkeit überwog und bei denen der Zugriff stark zufällig und leselastig war.

In den nahezu zwei Jahrzehnten seit der Veröffentlichung der ursprünglichen Empfehlungen haben sich all diese Faktoren verändert. In einigen Fällen handelt es sich um Kaskadeneffekte, bei denen der Wechsel vom allgemein verwendeten RAID 5 zum allgemein verwendeten RAID 10 dann dazu führt, dass die beiden gängigen Array-Typen, RAID 1 und RAID 10, dieselben Zugriffseigenschaften aufweisen, sodass die Notwendigkeit oder der Wunsch, je nach Lasttyp das eine oder das andere zu verwenden, entfällt.

1. Laufwerke sind heute riesig. Anstatt damit zu kämpfen, das Benötigte auf ihnen unterzubringen, verfügen wir in der Regel über überschüssige Kapazität. Einzellaufwerke mit über einem Terabyte sind verbreitet, selbst in Servern. Die Fehlerbereiche für Parität sind gewaltig (verglichen mit Größen wie URE-Ausfallraten).
2. Laufwerksanbindungen sind seriell und schnell. Die Laufwerksanbindungen stellen keinen Engpass mehr dar.
3. SATA ist heute auf Servern verbreitet und verschiebt die potenziellen Risiken für UREs in einer Weise, die zuvor nicht bestand.
4. Kapazität ist heute günstig, doch Leistung und Zuverlässigkeit sind nun die zentralen Anliegen für die eingesetzten Mittel.
5. Dateisysteme sind heute äußerst robust, und Dateisystemausfälle sind im Gesamtbild der Array-Zuverlässigkeit lediglich “Hintergrundrauschen”.
6. Hardware-RAID und Software-RAID sind heute beide Optionen, und zu den verfügbaren RAID-Leveln zählen viele Möglichkeiten, doch am wichtigsten ist, dass RAID 10 allgegenwärtig verfügbar ist.
7. Speichersysteme werden heute häufig gemeinsam genutzt, wodurch sequenzieller Zugriff noch seltener wird.
8. Speicher-Caches sind heute üblich und oft sehr groß. Caches von 512 MB und 1 GB gelten heute als normal, sodass viele Arrays aus dem Jahr 1995 heute vollständig in den Speicher auf dem RAID-Controller passen. Da Caches im Vergleich zur Speicherkapazität rasch wachsen und in den letzten zwei Jahren Solid-State-Laufwerke als L2-Cache im Speicher hinzugekommen sind, ist es nicht abwegig, dass selbst ein kleines Unternehmen Datenbanken und andere leistungssensible Anwendungen vollständig aus dem Cache heraus betreibt.
9. Laufwerksausfälle sind selten und für das Design von Speichersystemen von untergeordneter Bedeutung (verglichen mit anderen Ausfalltypen).
10. Die Größe eines Laufwerks-Arrays ist nur noch selten durch physische Beschränkungen limitiert.
11. Die Verwendung von RAID 1 und RAID 10 als heute vorherrschende Array-Typen bedeutet, dass es keinen Vorteil mehr bietet, unterschiedliche Array-Level zur Leistungsoptimierung einzusetzen.

Diese Faktoren verdeutlichen, warum das System mit aufgeteilten Arrays von 1995 zu jener Zeit vollkommen sinnvoll war und warum es heute keinen Sinn mehr ergibt. OBR10, der heutige Standard, war damals nicht verfügbar und unbezahlbar. RAID 5 war 1995 relativ sicher, heute jedoch nicht mehr. Nahezu jeder am Entscheidungsprozess beteiligte Faktor hat sich in den letzten siebzehn Jahren drastisch verändert und wird sich weiter verändern, da SSDs zusammen mit Auto-Tiering, noch größeren Caches und reinen SSD-Speichersystemen immer verbreiteter werden.

Der Wandel im Speicherdesign über die letzten zwei Jahrzehnte verdeutlicht zudem die Gefahren, denen die IT begegnet, da ein großer Teil des Fachgebiets – wie es in der Technik üblich ist – grundlegende “Faustregeln” oder “Best Practices” erlernt, ohne notwendigerweise die zugrunde liegenden Prinzipien zu verstehen, die diese Entscheidungen bestimmen, was es schwierig macht zu erkennen, wann diese Best Practices nicht anzuwenden sind oder – noch wichtiger – wann zu erkennen ist, dass die Regel nicht mehr gilt. Anders als im traditionellen Maschinen- oder Bauingenieurwesen, wo neue Fortschritte und bedeutende Faktoränderungen im Laufe einer Karriere möglicherweise nur einmal oder gar nie auftreten, verändert sich die IT noch immer schnell genug, dass im Laufe einer Karriere mehrfach ein vollständiges “Umdenken” grundlegender Faustregeln erforderlich ist. Vielleicht nicht jährlich, aber einmal pro Jahrzehnt oder häufiger ist es fast immer notwendig.

Der gegenwärtige Wandel von der Einzelverarbeitung hin zu mehrfädigen Architekturen ist eine weitere ähnliche, bedeutende Veränderung, die es erfordert, dass das IT-Fachgebiet die Handhabung des Systemdesigns vollständig umgestaltet.