16 Posts getaggt mit "Betrieb"

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.

Einen verteilten Store auf Kubernetes zu bringen, ist einfach. Ihn dort mit aktiviertem TLS, von außerhalb des Clusters erreichbar und mit einem Client, der sich tatsächlich verbindet bereitzustellen, ist der Punkt, an dem die meisten Anleitungen stillschweigend aufhören. Zaris liefert ein Helm-Chart, und wir haben den gesamten Weg — einschließlich der abgesicherten, extern erreichbaren Konfiguration — End-to-End auf einem lokalen Cluster validiert.

Dieser Beitrag ist diese Anleitung. Wir führen sie auf kind (Kubernetes-in-Docker) aus, damit Sie jeden Schritt auf einem Laptop nachvollziehen können, und wählen bewusst den schwierigeren Weg: TLS aktiviert, Zertifikate mit den richtigen Subject Alternative Names, externer Zugriff an und ein Client, der sich über den abgesicherten Endpunkt verbindet. Wir nennen das die Model-B-Konfiguration — extern erreichbar und abgesichert, im Gegensatz zu einem rein internen Cluster.

Eine Korrektheitsregel bringt fast jedes erste Deployment ins Stolpern, und sie hat nichts mit Zertifikaten zu tun: Der Store-Name in Ihrem Connection String muss mit der clusterId des Deployments übereinstimmen. Wir zeigen genau, wo das zuschlägt. Alles andere ist auf einem Produktions-Cluster identisch — kind bietet lediglich einen sauberen Wegwerf-Ort, um es zu beweisen.

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.