25 Posts getaggt mit "Verteilte Systeme"

Die meisten Wege, einem verteilten Datenspeicher eine Authentifizierung vorzuschalten, enden damit, ein zweites verteiltes System zu seinem Betrieb hinzuzufügen: einen Auth-Dienst, den man aufrufen muss, eine Session-Datenbank, die repliziert werden muss, einen Token-Introspection-Endpunkt, den jeder Node auf dem Hot Path erreichen muss. Sie haben den Store gesichert und sich eine neue Verfügbarkeitsabhängigkeit und eine neue Latenzquelle eingekauft.

Zaris geht einen anderen Weg, und zwar einen bewusst langweiligen: ein Signaturschlüssel pro Cluster und Tokens, die jeder Node selbst verifizieren kann. Ein Token ist ein JWT, signiert mit dem privaten Schlüssel des Clusters; jeder Manager und jeder Node hält die öffentliche Hälfte und prüft die Signatur offline — kein Aufruf an einen Auth-Server, kein Quorum, kein Datenbank-Lookup. Security ist standardmäßig aus, und ein Cluster mit ausgeschalteter Security verhält sich exakt wie ein ungesicherter. Dieser Beitrag handelt davon, was sich einschaltet, wenn Sie sie aktivieren: die Form des Tokens, das Rollen-und-Scope-Modell, die beiden Ebenen, auf denen die Durchsetzung tatsächlich stattfindet, und — weil das Gegenteil vorzutäuschen der Weg zu einem falschen Sicherheitsgefühl ist — die betrieblichen Grenzen, die man leicht falsch macht.

Zwei sehr unterschiedlich aussehende Ereignisse in einem verteilten Store sind im Kern dasselbe Problem. Das erste: Ein Replikat fällt hinter seinen Primary zurück — eine GC-Pause, eine langsame Platte, eine kurze Netzwerkpartition — und hält nun eine veraltete Kopie einer Partition, der es irgendwann entsprechen muss. Das zweite: Eine Partition wird einem Node zugewiesen, der sie nie gehalten hat, und dieser Node muss den gesamten Datenbestand vom aktuellen Owner übernehmen. Das eine ist Replikationsverzug; das andere ist Migration. Sie haben unterschiedliche Auslöser, unterschiedliche Betreiber, unterschiedliche Ausfallgeschichten.

Doch die Frage, die beide beantworten müssen, ist identisch: Wie konvergiere ich zur aktuellen Wahrheit dieser Partition, ohne Schreibzugriffe einzufrieren, während ich es tue? Zaris beantwortet beide mit einem einzigen Mechanismus — einem nach Revision geordneten Operations-Log pro Segment, wiedergegeben ab einem bekannten Punkt. Dieser Beitrag handelt von diesem Log: wie es auf dem Schreibpfad aufgebaut wird, wie es begrenzt wird, damit es nicht unbegrenzt wächst, wie es wiedergegeben wird und warum dasselbe Substrat sowohl ein zurückgefallenes Replikat als auch einen brandneuen Owner zur Konvergenz bringt.

Zaris 2.0.1 ist da. Es ist ein Drop-in-Upgrade von 2.0.0 — dasselbe Wire-Protokoll, dieselbe Client-API, dieselben On-Disk- und In-Memory-Formate — und es bietet zwei Gründe zum Upgrade: Es macht den Ownership- und Recovery-Pfad des Clusters bei Ausfällen spürbar langlebiger, und es gibt Zaris ein sauberes, integriertes Trial-und-Lizenz-Modell, mit dem Sie es reibungslos evaluieren und produktiv betreiben können.

Der Happy Path eines verteilten Key/Value-Stores lässt sich leicht richtig umsetzen. Ein Schreibvorgang landet auf dem Primary, wird an die Replikate gestreamt, alle sind sich einig, weiter geht's. Wäre das die ganze Geschichte, wäre Langlebigkeit ein gelöstes Problem, und dieser Beitrag würde nicht existieren.

Die schweren Probleme liegen in den Nahtstellen — den kurzen, unbequemen Momenten, in denen sich der Cluster mitten in einem Übergang befindet. Ein Node startet mitten in einer Partitionsmigration neu. Ein Replikat fällt weit hinter den Active zurück, von dem es kopiert, und dann geht dieser Active per Failover an jemand anderen. Der Besitz einer Partition wechselt auf einen neuen Node, während noch Schreibvorgänge zum alten unterwegs sind. Jedes davon ist ein Fenster: eine Spanne von wenigen Sekunden, in der ein bestätigter Schreibvorgang — einer, dem der Client als erfolgreich gemeldet wurde — stillschweigend verschwinden kann, wenn die Übergabe nicht exakt stimmt. Nicht weil die Storage-Engine fehlerhaft wäre, sondern weil zwei Teile des Systems für einen Moment uneins darüber waren, wer die Wahrheit besitzt.

In diesem Beitrag geht es darum, wie Zaris diese Fenster schließt — und, worauf es wirklich ankommt, wie wir uns davon überzeugt haben, dass es funktioniert: indem wir den Cluster zwölf Stunden am Stück unter kontinuierlichem, gezieltem Chaos betrieben haben.

Die Kapazität stimmt nie lange. Der Traffic wächst, ein Launch steht an, eine Saison endet — und der Store, den Sie im letzten Quartal dimensioniert haben, ist entweder überlastet oder halb leer. Ob das eine lästige Pflicht oder eine Krise ist, entscheidet eine einfache Frage: Können Sie die Größe eines laufenden Stores ändern, ohne ihn herunterzufahren?

Bei Zaris lautet die Antwort ja, mit einer wichtigen Asymmetrie, die man gleich zu Beginn ehrlich benennen sollte. Das Hochskalieren — das Hinzufügen von Servern — ist die einfache, sichere, verlustfreie Richtung und geschieht live, während der Store weiter bedient. Das Herunterskalieren — das Entfernen von Servern — wird ebenfalls unterstützt, ist aber ein bewusster, überwachter Vorgang, weil die Daten eines ausscheidenden Servers zuerst irgendwohin müssen.

Dieser Beitrag behandelt beide Richtungen: einen Store mit Add-ZrServer vergrößern, ihn mit Remove-ZrServer verkleinern, warum das Herunterskalieren einen Drain braucht und welche Rolle die Web-Konsole spielt.

Die Hälfte der „funktioniert in Dev, bricht in Prod"-Verbindungsfehler hat dieselbe Ursache: Die Verbindungsdetails wurden an drei Stellen auf drei verschiedene Arten geschrieben. In der appsettings.json stand eine Host-Liste, im Betriebshandbuch wurde eine andere in eine PowerShell-Sitzung kopiert, und der Connection String, den jemand aus einem Wiki kopiert hat, enthielt ein veraltetes Token.

Zaris nimmt diese ganze Problemklasse mit einem einzigen, plattformunabhängigen Connection-String-Format vom Tisch. Exakt derselbe String funktioniert, wenn Ihre .NET-Anwendung ihn aus der Konfiguration liest, wenn ein Operator ihn einem PowerShell-Cmdlet übergibt und wenn jemand ihn direkt aus der Web-Konsole kopiert. Eine kanonische Schreibweise, überall.

Dieser Beitrag zerlegt den String Teil für Teil, zeigt alle drei Verwendungsarten und plädiert für die wichtigste Regel in der Produktion: Legen Sie niemals ein rohes Token in den String.

Der sicherste Weg, TLS zu umgehen, ist, allen ein einziges Vertrauensmodell aufzuzwingen. Ein Entwickler, der einen Store auf dem Laptop betreibt, möchte keine CA aufsetzen. Eine Bank mit einem Offline-Root in einem HSM möchte nicht, dass Ihr Tool überhaupt Zertifikate ausstellt. Liefern Sie einen Store aus, der nur eines davon kennt, schaltet die Hälfte Ihrer Nutzer die Sicherheit ab, um ihre Arbeit zu erledigen.

Deshalb entscheidet Zaris nicht für Sie. Das TLS-Vertrauen ist über vier Certificate-Authority-Modi hinweg steckbar, von selbstsigniert ohne Konfiguration bis hin zu Zertifikaten, die Sie vollständig außerhalb des Systems bereitstellen. Sie wählen den Modus, der zur PKI passt, die Sie ohnehin betreiben, und Zaris fügt sich ein, statt von Ihnen einen Umbau zu verlangen. TLS ist keine Einheitslösung, und genau deshalb wird Sicherheit so oft aufgeschoben, wenn man es so behandelt.

Betreiben Sie Zaris in Kubernetes, ist der Normalfall einfach: In-Cluster-Clients erreichen die Pods über ihre internen Adressen — Pod-IPs und Cluster-DNS-Namen wie zaris-0.zaris.svc —, und alles wird sauber geroutet. Sobald ein Client außerhalb des Clusters läuft, bricht das zusammen. Eine externe Anwendung kann zaris-0.zaris.svc oder eine Pod-IP nicht anwählen; diese Namen und Adressen werden nur innerhalb des Cluster-Netzwerks aufgelöst und geroutet.

Das ist keine Eigenheit von Zaris, sondern die grundlegende Trennung zwischen dem internen Netzwerk des Clusters und der Außenwelt. Am stärksten trifft sie topologiebewusste Clients. Ein Redis-Client im Cluster-Modus oder jeder Client, der Nodes ermittelt und pro Key routet, lädt eine Topologie-Map vom Server und verbindet sich mit den darin enthaltenen Adressen. Sind diese Adressen intern, erhält ein externer Client eine Map voller Endpunkte, die er nie erreichen kann.

Zaris löst das mit Advertised Addresses, umgesetzt als per-Listener-„Boundary View".

Zaris stellt ein Redis-Protokoll-Frontend (RESP) bereit, sodass jeder Redis-Client in jeder Sprache auf einen Zaris-Cluster zeigen und ihn als Drop-in-Store nutzen kann. Doch „jeder Redis-Client" verbirgt ein reales Problem: Die Redis-Client-Ökosysteme sind sich nicht einig, wie die Topologie ermittelt wird oder wie man reagiert, wenn ein Node verschwindet. Ein einfacher Client erwartet einen einzelnen, stabilen Endpunkt. Ein Sentinel-basierter Client erwartet, einen Discovery-Dienst fragen zu können: „Wer ist der Master?" Ein Client im Cluster-Modus erwartet Hash-Slots und MOVED/ASK-Redirects.

Würde ein Store nur einen dieser Dialekte sprechen, blieben ganze Client-Klassen außen vor. Deshalb unterstützt das Zaris-RESP-Frontend drei Failover-Modelle, die jeweils dazu passen, wie eine bestimmte Familie von Redis-Clients bereits arbeitet. Sie wählen das Modell pro Deployment; der Client verhält sich genau so, wie er es gegenüber echtem Redis tun würde.

Vorab ein ehrlicher Hinweis, der alles Folgende prägt: Alle drei Modelle sitzen vor demselben replizierten, partitionierten Zaris-Store. Das gewählte Modell ändert die Semantik von Discovery und Redirects — also wie ein Client einen Node findet und was er tut, wenn dieser ausfällt —, nicht aber, wo Ihre Daten tatsächlich liegen.

Zaris spricht bereits in Collections — Hashes, Listen, Sets und Sorted Sets, die auf dem Server liegen und wie jeder andere Key repliziert werden. Streams sind die fünfte Art, und sie ist diejenige, die aus Zaris vom Store ein Stück Messaging-Infrastruktur macht.

Ein Zaris-Stream ist ein echtes Append-only-Log: Einträge erhalten monoton steigende IDs, Sie können Bereiche lesen, und Sie können Consumer Groups anbinden, sodass ein Pool von Workern das Log untereinander aufteilt, pro Consumer ausstehende Einträge verfolgt und bestätigt, was verarbeitet wurde. Sie können außerdem einen blockierenden Lesezugriff ausführen — ein Consumer parkt und wartet, bis neue Einträge eintreffen, statt in einer Schleife zu hämmern.

Und weil es eine native Zaris-Collection ist, wird das Log genau wie alles andere partitioniert und repliziert. Ein Stream übersteht ein Node-Failover, und genau dafür greift man überhaupt erst zu dauerhaftem Messaging.