42 Posts getaggt mit "Clustron"

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.

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.

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.

Zaris 1.x speicherte Werte. Zaris 2.0.0 speichert Collections. Hashes, Listen, Sets und Sorted Sets sind nun erstklassige, serverseitige Typen mit echten, typisierten .NET-APIs — und, ebenso wichtig, sie verhalten sich wie alles andere im Store.

Genau diesen letzten Punkt machen viele falsch. In vielen Systemen sind „Datenstrukturen“ eine clientseitige Illusion: Eine Bibliothek serialisiert ein Dictionary in einen Blob, schreibt es per Put und nennt das einen Hash. Das funktioniert, bis zwei Clients gleichzeitig dieselbe Collection anfassen oder bis Sie fragen, was bei einem Failover passiert. In Zaris ist ein Hash ein Hash auf dem Server. Er liegt auf der Partition, die seinen Key besitzt, repliziert auf das Replikat dieser Partition und überlebt den Verlust eines Nodes genau so wie ein einfacher Key.

Heute veröffentlichen wir Zaris 2.0.0 — das größte Release seit der allgemeinen Verfügbarkeit von Zaris und das erste mit einem Major-Versionssprung. Es macht aus Zaris, einem schnellen, replizierten Key/Value-Store, einen vollwertigen Datenstruktur-Server: native Hashes, Listen, Sets, Sorted Sets, Pub/Sub und Redis Streams, alle auf dieselbe Weise partitioniert und repliziert wie Ihre Keys bereits.

Und es öffnet die Tür für alle anderen. Jeder Node kann nun ein Redis-Protokoll-Frontend (RESP) bereitstellen, sodass eine Anwendung in Python, Ruby, Java, Go — jeder Sprache mit einem Redis-Client — auf Zaris zeigen und es als Drop-in nutzen kann, ohne natives SDK und ohne eine Zeile umzuschreiben.

Die Versionsnummer ist eine 2 und keine 1.x, und das hat einen Grund: 2.0.0 ändert das Wire-Protokoll. Lesen Sie den Upgrade-Hinweis unten, bevor Sie es ausrollen.

Zaris ist ein verteilter Key/Value-Store, der nativ für .NET gebaut wurde. Seine erstklassigen Clients sprechen ein effizientes binäres Protokoll, und wenn Ihr Stack .NET ist, ist das der Pfad, den Sie wollen — echte Async-APIs, .NET-Typen, Koordinationsprimitive, Drop-ins für IDistributedCache und HybridCache.

Die meisten Systeme bestehen aber nicht nur aus .NET. Da gibt es einen Python-Dienst für Datenarbeit, einen Go-Sidecar, einen Ruby-Job-Runner, ein Node-Gateway. Sie alle auf einen neuen Client umzuschreiben, nur um einen neuen Store auszuprobieren, kommt nicht in Frage. Deshalb kann in 2.0.0 jeder Zaris-Node zusätzlich einen Redis-Protokoll-Listener (RESP2) bereitstellen: Richten Sie einen bestehenden Redis-Client darauf und nutzen Sie Zaris als Drop-in-Key/Value-Store, in jeder Sprache, ohne eine Zeile Client-Code zu ändern.

Dieser Beitrag beschreibt, wie dieses Frontend tatsächlich funktioniert — das Routing-Modell, das Datenmodell, die Failover-Modelle und genau, welche Befehle dabei und welche nicht dabei sind.

Redis ist schnell. Es ist aber auch, konstruktionsbedingt, auf dem Datenpfad single-threaded: eine Event-Loop, ein Core, ein Befehl nach dem anderen. Das ist ein wirklich gutes Design — es macht Redis leicht nachvollziehbar und beseitigt eine ganze Kategorie von Nebenläufigkeitsfehlern. Aber es hat eine Obergrenze, die sich nicht mit Hardware kaufen lässt. Geben Sie einer Engine mit einer einzigen Event-Loop eine 4-Core-, eine 8-Core- oder eine 32-Core-Maschine, und der Lese-Durchsatz landet an derselben Stelle. Die zusätzlichen Cores bleiben ungenutzt.

Zaris geht den anderen Weg. Keys sind partitioniert, und jede Partition hat einen Besitzer, sodass Lesezugriffe auf verschiedene Keys auf verschiedenen Cores landen und gleichzeitig laufen. Das Ergebnis ist ein Durchsatz, der sich beim Hinzufügen von Cores bewegt — statt einer flachen Linie ein Anstieg.