21 Posts getaggt mit "Architektur"

Der Großteil dieses Blogs ist jeweils tief in ein einzelnes Thema eingestiegen — Compare-and-Swap, Multi-Key-Transaktionen, native Datenstrukturen, Streams, Watch, das darunterliegende Op-Log. Jeder Beitrag beantwortet „wie funktioniert dies". Dieser beantwortet eine andere, praktischere Frage: Wonach greifen Sie, wenn ein Problem vor Ihnen liegt?

Diese Frage ist wichtig, weil die falsche Wahl selten ein Absturz ist. Es ist ein System, das in der Demo funktioniert und dann unter Last ein Update verliert, tausend Schreiber durch einen Schlüssel schleust oder eine Fire-and-Forget-Benachrichtigung nutzt, wo ein dauerhaftes Log nötig war. Die Primitive hindern Sie nicht daran, sie falsch zu benutzen. Dies ist also ein Feldführer: das mentale Modell, das sie verbindet, eine Entscheidungstabelle, ein Gang durch jeden Zweig mit ehrlicher Eignung und ehrlicher Grenze und am Ende ein Flussdiagramm.

Die meisten verteilten Datenspeicher zwingen Sie, sich früh und endgültig zwischen zwei Welten zu entscheiden. Da ist der „echte" Store — ein Cluster, den Sie deployen, auf den Sie einen Client über das Netzwerk richten und mit dem Sie über ein Wire-Protokoll sprechen. Und da ist der „falsche" Store, zu dem Sie in Unit-Tests greifen: ein In-Memory-Dictionary, ein Mock, ein handgeschriebener Stub, der gerade genug der Schnittstelle implementiert, damit der Test kompiliert. Beide haben nichts gemeinsam. Ihr Test prüft das Verhalten des Stubs, nicht das des Stores, und die Lücke dazwischen ist genau der Ort, an dem sich Bugs verstecken.

Zaris hebt diese Entscheidung auf. Derselbe typisierte .NET-Client, der über TLS mit einem verteilten Cluster spricht, betreibt den Store auch eingebettet in Ihrem Prozess, ohne Socket, ohne Partition-Map und ohne Deployment — und zwar mit derselben Store-Engine, nicht mit einem Ersatz. Welchen von beiden Sie bekommen, wählen Sie mit einer einzigen Connection-String. Dieser Beitrag erklärt, wie das funktioniert, wofür es sich wirklich eignet und wo die harte Grenze verläuft, an der der Embedded-Modus endet und ein Cluster beginnt.

Es gibt eine Frage, die jeder Entwickler irgendwann an einen verteilten Store richtet, meist direkt nach einem verwirrenden Bug-Report: Wenn ich einen Wert schreibe und ihn sofort zurücklese, sehe ich dann garantiert, was ich geschrieben habe? Das klingt, als müsste es eine Ein-Wort-Antwort geben. Gibt es nicht — nicht für irgendeinen partitionierten, replizierten Store, und nicht für Zaris. Die ehrliche Antwort lautet „ja, innerhalb einer Partition, weil Lesevorgänge zum selben einzelnen Owner gehen wie Ihr Schreibvorgang" — und das Interessante ist alles, was in dieser Einschränkung steckt.

Dieser Beitrag ist das Konsistenzmodell von Zaris an einem Ort zusammengetragen. Über die Einzelteile haben wir separat geschrieben — optimistisches Compare-and-Swap, transparenter Retry bei Ownership-Churn, das wiederabspielbare Op-Log, das Replikate speist, Multi-Key-Transaktionen. Hier verbinden wir sie aus Sicht des Lesers und beantworten die einzige Frage, die an der Tastatur zählt: Was wird mir beim Lesen tatsächlich zugesichert? Einschließlich, und vor allem, wo die Zusicherung endet.

Lizenzierung ist der Teil eines Produkts, über den die meisten Ingenieure nie nachdenken wollen, und man sieht es. Das übliche Muster ist eine Zeitbombe: Ein Datum wird geprüft, und wenn es verstreicht, bestraft die Software Sie — sie wirft beim Start eine Exception, sie beschädigt oder löscht lokalen Zustand, um Sie am „Stehlen" zu hindern, oder sie stürzt schlicht ab und nimmt Ihre Daten mit. Dieses Design behandelt die eigenen Operatoren als Gegner, und es versagt genau in dem Moment, in dem Sie es sich am wenigsten leisten können: in der Produktion, nachdem die Uhr unbemerkt umgesprungen ist.

Zaris nimmt die entgegengesetzte Haltung ein. Die Lizenzprüfung ist der sicherheitskritischste Schalter eines verteilten Datenspeichers und wird entsprechend gebaut: eine einzige reine, deterministische Policy-Funktion, ein sanfter und vollständig umkehrbarer Durchsetzungspfad, der kein einziges Byte zerstört, und eine Uhr pro Maschine, die in dem Moment weiterläuft, in dem Sie einen Schlüssel aktivieren. Dieser Beitrag geht durch, wie dieser Lebenszyklus im ausgelieferten Code tatsächlich funktioniert — denn die interessante Ingenieursarbeit steckt darin, was er Ihnen verweigert anzutun.

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.

Es gibt eine Zahl, die sich jeder .NET-Performance-Ingenieur irgendwann merkt: 85.000 Bytes. Jede einzelne Allokation ab etwa dieser Größe landet nicht auf dem normalen Heap für kleine Objekte, sondern auf dem Large Object Heap (LOH). Der LOH ist ein anderes Tier. Er wird nur bei einer Gen-2-(vollständigen) Garbage Collection eingesammelt und standardmäßig nicht kompaktiert. Diese Kombination ist in Ordnung für einen großen Puffer, den man einmal allokiert und behält. Sie ist nicht in Ordnung für einen latenzarmen In-Memory-Store, der wiederholt große Werte schreibt und überschreibt.

Stellen Sie sich die Last vor: große serialisierte Blobs, umfangreiche JSON-Dokumente, Bilder, Protokoll-Payloads — gespeichert, aktualisiert, ersetzt, immer wieder. Jeder dieser großen Schreibvorgänge legt ein frisches Objekt auf dem LOH ab. Da der LOH nicht kompaktiert wird, verschmelzen freigegebene Bereiche nicht zu zusammenhängendem Speicher, sondern fragmentieren. Und weil jede Rückgewinnung eine vollständige Gen-2-Collection bedeutet, werden die Pausen länger und treten häufiger auf, genau dann, wenn der Working Set wächst. Für einen Store, dessen ganzes Versprechen niedrige Latenz ist, ist das die falsche Art von Überraschung.

Zaris liefert ein optionales Feature, das den LOH für solche Werte komplett umgeht. Es ist standardmäßig aus, und dieser Beitrag erklärt, was es tut, wie es funktioniert und — ebenso wichtig — wann Sie es einschalten sollten und wann nicht.

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.

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.

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.

Heute veröffentlichen wir Zaris 0.9.0 — und damit erreicht Zaris die allgemeine Verfügbarkeit. Es ist produktionsreif, plattformübergreifend und wird nun durch kommerziellen Support begleitet.

Falls Sie es noch nicht kennen: Zaris ist ein verteilter In-Memory-Key/Value-Store für .NET. Er ist schnell, repliziert und lässt sich über einen Browser, PowerShell oder direkt aus Ihrer Anwendung betreiben. Dieses Release ist der Höhepunkt dieser Arbeit — der Punkt, an dem aus einem „vielversprechenden Projekt“ etwas wird, das Sie in Produktion einsetzen können.