Der DIY-SAN-Kaninchenbau: Ein Ingenieur fragte, wie moderner Storage wirklich funktioniert, und die Antwort wurde schnell kompliziert
Es gibt eine bestimmte Art von Frage, die durch das übliche Enterprise-Storage-Rauschen schneidet. Nicht „welcher Anbieter ist besser?“. Nicht „warum ist diese Lizenz so teuer?“. Nicht „warum ist das Dashboard nach dem Firmware-Update kaputtgegangen?“. Diese hier war klarer, schärfer und deutlich gefährlicher: 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. Irgendeine Art von verteiltem oder gespiegeltem Zustand. Ein sauberes Diagramm lässt alles wie Lego für Erwachsene mit teureren Kabeln aussehen. Aber dieses Diagramm verbirgt das eigentliche Problem: Bei Storage geht es nicht darum, Bytes schnell zu bewegen. Es geht darum, Bytes korrekt zu bewegen, während Dinge ausfallen, lügen, um die Wette laufen, Timeouts erzeugen, neu starten und versuchen, Ihr Wochenende zu ruinieren.
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 mag manchmal stimmen, aber nicht universell. 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. Manchmal stimmt das. Aber High-End-Arrays tragen oft Jahrzehnte an individueller Entwicklung, proprietärer Mikrocode, ungewöhnliche Hardware-Annahmen und spezialisierte Datenpfade mit sich, die sich nicht sauber in ein Standard-Linux-Denkmodell einordnen lassen.
Die erste brutale Lektion: 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 vielleicht ein Active-Passive-Array. Er bringt einem wahrscheinlich kein echtes Active-Active-Storage-System, allein mit Standardkomponenten von der Stange.
Das ist ein gewaltiger Unterschied.
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. Aber immerhin ist das Ownership-Modell relativ einfach.
Active-Active klingt aus Marketingsicht sauberer. Beide Controller bedienen I/O. Beide erscheinen nützlich. Beide tragen bei. Alles wirkt moderner. Aber echtes Active-Active bedeutet, 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. Viel Enterprise-Storage-Marketing verwendet den Begriff Active-Active locker. Manchmal bedeutet es, dass beide Controller eingeschaltet sind und unterschiedliche Volumes bedienen. Manchmal bedeutet es optimierte Pfade. Manchmal bedeutet es ALUA-Verhalten. Manchmal bedeutet es, dass beide Controller auf Backend-Medien zugreifen können, aber nicht zwangsläufig, dass beide gleichzeitig auf vollständig symmetrische Weise dieselben Datenstrukturen beschreiben.
Die Worte sind einfach.
Die Realität 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. 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, nicht unbedingt weil ZFS genau die Antwort für den Bau eines kommerziellen NVMe-oF-Arrays ist, sondern weil es die Art von Paranoia lehrt, die gute Storage-Systeme brauchen.
Das ist der Unterschied zwischen einer Demo und einem Array.
Eine Demo exponiert einen Namespace.
Ein Array übersteht schlechte Tage.
Eine Demo besteht einen Benchmark.
Ein Array 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. Device-Mapper kann Block-Mappings bauen. All das ist real. 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 klingt nach einer Liste.
Es ist keine Lösung.
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? 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.
Kommerzielle Arrays machen daraus eine Mahlzeit.
Manchmal mit offenen Teilen. Manchmal mit proprietären Teilen. 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, und genau das ist der Punkt
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. Das ist nicht unhöflich. Das ist das Geschäft. Die Teile, die ein Enterprise-Array wertvoll machen, sind oft die langweiligen, kampferprobten Interna, die kein Anbieter nachgebaut sehen möchte.
Es ist nicht nur die UI.
Es ist nicht nur „Linux plus Treiber“.
Es ist Verhalten.
Failover-Verhalten. Upgrade-Verhalten. Recovery-Verhalten. Verhalten bei ungesichertem Cache. Reservation-Verhalten. Verhalten der Management-Ebene. Telemetrie-Verhalten. Supportfähigkeits-Verhalten. Das Zeug, das Kunden nur bemerken, wenn es versagt.
Der Instinkt des ursprünglichen Ingenieurs war trotzdem gut. Eine vereinfachte Version nachzubauen ist eine der besten Lernmethoden. Aber die Lektion aus dem Thread ist, dass modernes SAN-Design keine Einkaufsliste von Komponenten ist. Es ist eine Reihe brutal spezifischer Entscheidungen über Fehler. 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.
Großartige Systeme beweisen diese Antworten unter hässlichen Bedingungen.
Die Linux-versus-BSD-Debatte verbirgt eine größere Wahrheit
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. Aber bei ernsthaften Storage-Arrays ist die zentrale Design-Frage nicht „welches OS bootet?“. Sie lautet „wo lebt der maßgebliche Datenpfad?“.
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. 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 keine Magie; es ist ein Vertrag
Multipath wird oft als clientseitige Annehmlichkeit behandelt. Mehrere Pfade von Hosts zu Storage-Geräten. Bessere Resilienz. Vielleicht besseres Balancing. Aber in einem Dual-Controller-Array ist Multipath 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.
HA ist nicht „zwei Boxen, die miteinander verbunden sind“. Es ist 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 mag einfach klingen, aber es ist der Satz, an dem jedes DIY-Array irgendwann zerschellt.
Zwei Controller sind einfach.
Eine kohärente Storage-Persönlichkeit ist schwer.
Deshalb sind Storage-Ingenieure beruflich paranoid
Der Thread war erfrischend, weil er Storage als Engineering behandelte, nicht als Markenkrieg. Jemand scherzte sogar, es sei ein wirklich interessanter Storage-Beitrag und habe zehn Upvotes verdient. Diese Reaktion ergibt Sinn. 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. Beobachten Sie, was passiert, wenn Annahmen zusammenbrechen. Dort beginnt die eigentliche Ausbildung.
Aber die tiefere Wahrheit ist demütigend. Enterprise-Storage-Arrays sind nicht nur teuer, weil Anbieter Margen mögen, obwohl sie das durchaus tun. Sie sind teuer, 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.
Sie haben die alten Dämonen nicht entfernt.
Sie haben ihnen nur eine niedrigere Latenz gegeben.