Ein Ingenieur fragte, wie moderner Storage wirklich funktioniert, und die Antwort wurde schnell kompliziert
Manche Fragen schneiden durch das übliche Enterprise-Storage-Rauschen, weil sie klarer, schärfer und deutlich gefährlicher sind als der Streit um den besseren Anbieter, teure Lizenzen oder ein Dashboard, das nach dem Firmware-Update kaputtging. Diese war so eine: Wie funktioniert ein moderner Dual-Controller-SAN eigentlich unter der Haube?
Ein Software-Ingenieur bei einem Cloud-Anbieter beschloss, eine kleine Version dessen zu bauen, was Anbieter für ernsthaftes Geld verkaufen. Der Aufbau klang vertraut für jeden, der die Entwicklung moderner Arrays verfolgt: zwei x86-Plattformen, direkte 25-Gb-Verbindungen, dual-portierte NVMe-Laufwerke, NVMe over TCP oder RDMA, exponierte Namespaces und eine Topologie, inspiriert von switchlosen HA-Systemen wie dem HPE Alletra MP B10000. Der Ingenieur hatte bereits mit Mellanox OFED und SPDK experimentiert und es geschafft, NVMe-Namespaces gegenüber Hosts zu exponieren. Dann kam der schwierige Teil: Multipath, RAID, High Availability, Fencing, Failover, Metadaten und all die unsichtbare Maschinerie, die aus „ein paar schnellen Laufwerken im Netzwerk“ ein Storage-Array macht, dem Menschen vertrauen.
Jeder liebt das Architekturdiagramm, bis Konsistenz ins Spiel kommt
Das Verführerische an modernem Storage ist, dass das physische Design fast verständlich aussieht: zwei Controller, gemeinsame Laufwerke, schnelles Fabric, Host-Multipathing, eine Management-Schicht und irgendeine Art von verteiltem oder gespiegeltem Zustand. Ein sauberes Diagramm lässt das alles wie Lego für Erwachsene mit teureren Kabeln aussehen. Dabei verbirgt das Diagramm die eigentliche Arbeit. Storage muss Bytes korrekt bewegen, auch während Dinge ausfallen, lügen, um die Wette laufen, Timeouts erzeugen, neu starten und versuchen, Ihr Wochenende zu ruinieren, und das ist viel schwerer, als sie schnell zu bewegen.
Genau dort wurden die Kommentare interessant. Jemand widersprach sofort der Annahme, kommerzielle Arrays seien im Kern einfach Linux mit einer aufgeschraubten Management-Oberfläche. Das stimmt manchmal, aber längst nicht immer. Manche Anbieter setzen aus Lizenzgeschichtsgründen auf BSD. Andere nutzen BSD nur zum Bootstrapping, während die eigentliche Arbeit den herkömmlichen OS-Pfad umgeht, ähnlich wie ESX bestimmte Low-Level-Funktionen handhabt. Ein weiterer Kommentator mit Storage-Branchenhintergrund sagte, BSD sei überraschend verbreitet, und Systeme wie Hitachi VSP und Dell PowerMax seien nicht einfach Maschinen, die mit Linux-Treibern normale Linux-Dinge tun.
Diese Korrektur ist wichtig. Menschen stellen sich kommerziellen Storage oft als Open-Source-Sanitärtechnik mit hübscher Fassade und Supportvertrag vor, und manchmal trifft das zu. High-End-Arrays tragen aber oft Jahrzehnte an individueller Entwicklung, proprietärem Mikrocode, ungewöhnlichen Hardware-Annahmen und spezialisierten Datenpfaden mit sich, die sich nicht sauber in ein Standard-Linux-Denkmodell einordnen lassen.
Active-Active ist kein Wochenendprojekt
Die praktischste Antwort traf den Kern des DIY-Traums direkt. Wer ein Linux-basiertes SAN-Array bauen will, dessen wahrscheinliche Bausteine sind Device-Mapper für RAID oder Volume-Mapping, individuelle Metadaten zur Beschreibung des Disk-Layouts, vielleicht Clustered LVM, und dann Pacemaker plus Corosync für die HA-Koordination. Für Fencing werden Persistent Reservations auf den Laufwerken wichtig. Dieser Stack bringt einem mit Standardkomponenten von der Stange vielleicht ein Active-Passive-Array, aber wahrscheinlich kein echtes Active-Active-Storage-System. Der Abstand zwischen beiden ist gewaltig.
Active-Passive ist schon schwer. Ein Controller besitzt die Ressourcen. Der andere wartet, überwacht und übernimmt, wenn der erste ausfällt oder gefenct wird. Dort steckt reichlich technischer Schmerz: Failover-Timing, Split-Brain-Vermeidung, Zustandsreplikation, Schreibreihenfolge, Reservation-Handling, Verhalten des Client-Pfads und Recovery-Sequenzierung. Immerhin bleibt das Ownership-Modell dabei relativ einfach.
Active-Active klingt aus Marketingsicht sauberer. Beide Controller bedienen I/O, beide erscheinen nützlich, alles wirkt moderner. Echtes Active-Active bedeutet aber, dass beide Seiten sich ständig über Ownership, Reihenfolge, Cache-Zustand, Metadaten, ungesicherte Schreibvorgänge, Reservations, Rebuilds und Fehlerbehandlung einig sein müssen. Können beide Controller in dieselbe logische Struktur schreiben, wird Nebenläufigkeit zum Monster im Raum.
Ein Kommentator brachte es unverblümt auf den Punkt: Die meisten Arrays machen ohnehin kein echtes Active-Active. Dieser Satz verdient mehr Aufmerksamkeit, als er normalerweise bekommt, denn viel Enterprise-Storage-Marketing verwendet den Begriff locker. Manchmal bedeutet er, dass beide Controller eingeschaltet sind und unterschiedliche Volumes bedienen. Manchmal sind optimierte Pfade gemeint, manchmal ALUA-Verhalten, manchmal nur, dass beide Controller auf Backend-Medien zugreifen können. Dass beide gleichzeitig und vollständig symmetrisch dieselben Datenstrukturen beschreiben, folgt daraus nicht. Die Worte sind einfach, die Umsetzung ist es nicht.
Die langweiligen Teile sind dort, wo die Leichen begraben liegen
Storage-Ingenieure sind besessen von langweiligen Dingen, weil langweilige Dinge Daten zerstören: Metadaten, Superblöcke, Prüfsummen, Write Barriers, Flush-Semantik, Reservations, Fencing, Generation Counters, Split-Brain-Erkennung, stabile Identifikatoren, Import-Regeln, Replay-Logs und Dirty-Region-Tracking. Das klingt nach Implementierungsdetails, bis ein Controller mitten in einem Update stirbt und der überlebende Controller entscheiden muss, was Realität bedeutet.
Deshalb warnte ein Kommentar den ursprünglichen Bastler, tief über das Nebenläufigkeitsmodell und die Schichten der Datenintegrität nachzudenken. Laufwerke und SSDs können bei Schreibvorgängen lügen, sich bei Flushes danebenbenehmen oder Dinge tun, die technisch erlaubt, aber erschreckend sind, wenn die oberen Schichten perfekte Ehrlichkeit voraussetzen. Der Rat war, sich tief in ZFS einzuarbeiten. ZFS ist nicht unbedingt die Antwort für den Bau eines kommerziellen NVMe-oF-Arrays, lehrt aber die Art von Paranoia, die gute Storage-Systeme brauchen.
Dort liegt der Abstand zwischen einer Demo und einem Array. Eine Demo exponiert einen Namespace und besteht einen Benchmark. Ein Array übersteht schlechte Tage und weiß, was zu tun ist, wenn eine Disk Unsinn zurückgibt, ein Controller verschwindet, ein Host aggressiv erneut versucht, eine Interconnect flattert und ein Schreibvorgang bestätigt wurde, kurz bevor die Welt sich gespalten hat.
Menschen unterschätzen diese Lücke, weil der Happy Path so sauber aussieht. SPDK kann I/O schnell bewegen, Linux hat NVMe-Target-Support, RDMA kann brüllen, Multipath kann Clients mehr als einen Pfad sehen lassen, Pacemaker kann Ressourcen verschieben und Device-Mapper kann Block-Mappings bauen. All das ist real, und nichts davon erzeugt automatisch eine vertrauenswürdige Storage-Plattform. Man braucht trotzdem das meinungsstarke Gehirn, das alles zusammenhält.
Open-Source-Teile existieren, aber das Produkt ist der Klebstoff
Mehrere Kommentatoren wiesen auf echte Software-Bausteine hin. Modernes Linux enthält NVMe-Target-Support über nvmet. Corosync ist in HA-Stacks verbreitet. RSF-1 taucht in kommerziellen HA-Storage-Umgebungen auf. Pacemaker kann Failover koordinieren. Device-Mapper kann Block-Devices präsentieren und die Volume-Logik untermauern. dmsetup kann diese Mappings direkt manipulieren, oder ein Entwickler könnte über APIs einen eigenen Volume-Manager bauen, so wie LVM es tut. Das ergibt eine schöne Einkaufsliste und noch keine Lösung, denn das eigentliche Produkt ist der Klebstoff.
Wie entscheidet das System, welcher Controller einen Namespace besitzt? Wie veröffentlicht es diesen Zustand gegenüber Hosts? Wie koordiniert es Reservations auf dual-portierten NVMe-Laufwerken? Wie unterscheidet es Controller-Tod von Netzwerkpartition? Was passiert, wenn der HA-Link ausfällt, aber beide Controller noch leben? Wer fenct wen? Was, wenn Fencing fehlschlägt? Was, wenn beide Controller denken, der andere sei tot? Welche Metadaten liegen auf der Disk, wer darf sie aktualisieren, und wie werden sie versioniert? Wie funktioniert ein Rebuild, während I/O weiterläuft? Kann eine Seite veraltete Daten ausliefern, und wie beweist man, dass sie es nicht kann?
Deshalb sagte ein Kommentator, es brauche einen ganzen Software-Stack und das sei nicht Plug-and-Play. Man müsse eine Menge Dinge miteinander verweben, um zum Ergebnis zu kommen. Das ist untertrieben, aber zutreffend. Storage-Systeme ähneln weniger einzelnen Anwendungen und mehr Verträgen zwischen feindseligen Schichten, die einander kaum vertrauen.
Die Open-Source-Welt liefert mächtige Zutaten, und kommerzielle Arrays machen daraus eine Mahlzeit: manchmal mit offenen Teilen, manchmal mit proprietären, manchmal mit individuellen Kernel-Pfaden, Userspace-I/O-Engines, privaten Metadatenformaten und jahrelangen Fehlertests, die es nie in die Hochglanzbroschüre schaffen.
Kommerzielle Anbieter rücken das Geheimrezept nicht heraus
Eine Antwort sprach den leisen Teil laut aus: Wenn die Frage lautet, welche exakte Software ein kommerzielles NVMe-oF-Array unter der Haube nutzt, ist das vertraulich, und wer es weiß, wird es wahrscheinlich nicht teilen. Unhöflich ist das nicht, so funktioniert das Geschäft. Die Teile, die ein Enterprise-Array wertvoll machen, sind oft die langweiligen, kampferprobten Interna, die kein Anbieter nachgebaut sehen möchte.
Was ein Array ausmacht, ist sein Verhalten beim Failover, bei Upgrades und bei der Recovery, bei ungesichertem Cache und bei Reservations, auf der Management-Ebene, in der Telemetrie und in der Supportfähigkeit. UI und Treiber sind dabei der kleinere Teil. Kunden bemerken dieses Verhalten erst, wenn es versagt.
Der Instinkt des ursprünglichen Ingenieurs war trotzdem gut, denn eine vereinfachte Version nachzubauen ist eine der besten Lernmethoden. Die Lektion aus dem Thread ist, dass modernes SAN-Design aus einer Reihe sehr spezifischer Entscheidungen über Fehler besteht, und eine Einkaufsliste von Komponenten kann diese Entscheidungen nicht ersetzen. Jede Architektur muss dieselben Fragen beantworten. Was kann ausfallen? Wer bemerkt es? Wer entscheidet? Wer stoppt das Schreiben? Wer bedient weiter? Wer stellt hinterher die Wahrheit wieder her? Schlechte Systeme weichen diesen Fragen aus, gute Systeme kodieren Antworten, und großartige Systeme beweisen diese Antworten unter hässlichen Bedingungen.
Die Linux-versus-BSD-Debatte ist nicht die zentrale Frage
Der Streit darüber, ob Storage-Appliances Linux, BSD oder etwas Exotischeres nutzen, ist interessant, kann aber zur Ablenkung werden. Das Betriebssystem spielt eine Rolle bei Lizenzierung, Treibern, Bootprozess, Tooling und Ökosystem. Bei ernsthaften Storage-Arrays lautet die zentrale Design-Frage aber, wo der maßgebliche Datenpfad lebt. Welches OS bootet, ist zweitrangig.
Manche Systeme stützen sich stark auf OS-Storage-Stacks. Andere umgehen große Teile des Kernel-Pfads aus Gründen der Performance, Kontrolle oder Historie. Manche exponieren das Management über kleine Unix-artige Umgebungen, während der eigentliche I/O-Pfad in individuellen Modulen läuft. Manche nutzen intern Virtualisierung für Dienste. Ein Kommentator erwähnte, dass bhyve von Anbietern genutzt wird, um Management-, UI- und Datenverwaltungsfunktionen in kleinen BSD-Images auszuliefern. Ein anderer fand das lustig, weil NetApp bhyve erschaffen hat und es offenbar nicht so genutzt hat, wie andere es taten.
Dieser kleine Seitenpfad sagt viel aus. Storage-Anbieter sind pragmatisch. Sie nutzen wieder, was passt, sie erfinden, was nötig ist, und sie tragen alte Entscheidungen jahrzehntelang weiter, weil das Umschreiben funktionierenden Storage-Codes der Moment ist, in dem Erwachsene die Angst entdecken.
Ein Cloud-Ingenieur, der auf modernen NVMe-Storage schaut, erwartet vielleicht etwas Neues und Sauberes. In Wirklichkeit tragen die neuesten Arrays oft alte Ideen in schnelleren Fabrics. Reservations, Ownership, Fencing, Metadaten-Journaling, Prüfsummen, Cache-Kohärenz, Failover-Zustandsautomaten und Multipath-Richtlinien sind keine neuen Probleme. NVMe macht nur alles schneller, einschließlich der Konsequenzen, wenn man es falsch macht.
Multipath ist ein Vertrag zwischen Host und Array
Multipath wird oft als clientseitige Annehmlichkeit behandelt: mehrere Pfade von Hosts zu Storage-Geräten, bessere Resilienz, vielleicht besseres Balancing. In einem Dual-Controller-Array ist Multipath jedoch Teil eines größeren Vertrags zwischen Host, Fabric, Controller-Ownership und Failover-Semantik.
Der Host muss wissen, welche Pfade nutzbar sind. Das Array muss Pfade konsistent exponieren. Während eines Ausfalls müssen Pfade verschwinden, degradieren oder den Zustand auf eine Weise wechseln, die der Host versteht. Wenn ein Controller einen Namespace failovert, darf der Host nicht ewig auf einen toten Pfad schreiben, oder schlimmer, irgendwohin schreiben, wo es unsicher ist. Bei NVMe-oF spielt ANA-Verhalten eine Rolle, die im Geiste dem Umgang mit Pfadzuständen in älteren Multipath-Welten ähnelt, aber die größere Frage bleibt dieselbe: Woher wissen Clients, wo die Wahrheit gerade lebt?
Diese Frage hängt direkt mit HA zusammen, denn für HA reicht es nicht, zwei Boxen miteinander zu verbinden. Dazu gehören Konfigurationssynchronisation, Zustandssynchronisation, Klarheit über Fehlerdomänen und ein Fencing-Modell, das stark genug ist, um Split Brain zu verhindern. Ein Kommentator definierte es genau in diese Richtung: HA bedeutet Config- und State-Sync mit klaren Fehlerdomänen. Das klingt handlich, ist aber der Satz, an dem jedes DIY-Array irgendwann zerschellt. Zwei Controller aufzustellen ist einfach, eine kohärente Storage-Persönlichkeit daraus zu machen ist schwer.
Deshalb sind Storage-Ingenieure beruflich paranoid
Der Thread war erfrischend, weil er Storage als Engineering behandelte und nicht als Markenkrieg. Jemand scherzte sogar, es sei ein wirklich interessanter Storage-Beitrag und habe zehn Upvotes verdient. Diese Reaktion ergibt Sinn, denn die Frage ging direkt in den Maschinenraum der Branche: Was steckt unter den glänzenden Arrays? Die Antwort ist teils offene Technologie, teils proprietäre Geschichte, teils Schmerz verteilter Systeme und teils sehr teure Paranoia.
Ein DIY-Experiment mit modernem SAN kann definitiv viel lehren. Beginnen Sie mit Active-Passive. Nutzen Sie nvmet oder SPDK für die Target-Exposition. Studieren Sie Device-Mapper, LVM-Metadaten, Persistent Reservations, Pacemaker, Corosync und ZFS. Lernen Sie, wie sich Hosts verhalten, wenn Pfade flattern, ziehen Sie Kabel, töten Sie Controller, beschädigen Sie im Labor Metadaten und beobachten Sie, was passiert, wenn Annahmen zusammenbrechen. Dort beginnt die eigentliche Ausbildung.
Die Erkenntnis am Ende ist demütigend. Enterprise-Storage-Arrays sind teuer, weil Anbieter Margen mögen, und mehr noch, weil die langweiligen Teile schwer sind, die Fehlermatrix riesig ist und Kunden erwarten, dass Storage die eine Schicht ist, die nicht zuckt. Moderne NVMe-Fabrics haben die Geschwindigkeit verändert und die alten Dämonen nicht entfernt. Sie haben ihnen nur eine niedrigere Latenz gegeben.