Clusterbetrieb

Die Cloud-Variante läuft als mehrere identische Knoten hinter einem Loadbalancer. Drei Dinge müssen dafür geteilt werden.

1. Datenbank

Alle Knoten sprechen dieselbe Datenbank. Für den verteilten Betrieb ist das YugabyteDB (PostgreSQL-Protokoll, verteilte Ablage):

DNSE_DB_DSN=postgres://yugabyte@yb:5433/yugabyte
DNSE_DB_YB=on

Ohne DNSE_DB_YB=on wird die Verbindung als gewöhnliches PostgreSQL behandelt — der YugabyteDB-eigene Treiber bliebe ungenutzt.

Die Schema-Migration läuft beim Start. Sie soll einmal laufen: Beim Hochfahren eines frischen Clusters startet ein Knoten zuerst, die übrigen folgen, sobald er gesund ist.

2. Verschlüsselungsschlüssel

Alle Knoten brauchen denselben DNSE_ENCRYPTION_KEY. Sonst kann Knoten 2 nicht lesen, was Knoten 1 verschlüsselt geschrieben hat — Provider-Zugangsdaten wären je nach angefragtem Knoten kaputt.

3. Sessions

DNSE_VALKEY_ADDR=valkey:6379
DNSE_VALKEY_PASSWORD=…          # optional

Ohne Valkey lägen Sessions im Speicher des jeweiligen Prozesses: Eine Anmeldung auf Knoten 1 wäre auf Knoten 2 unbekannt, und der Benutzer flöge bei jedem Wechsel des Loadbalancers heraus. Mit Valkey gilt eine Session überall — für Mandanten- und Operator-Anmeldungen — und ein Logout wirkt sofort auf allen Knoten.

Valkey wird bewusst nicht gesichert: Sessions bedeuten im schlimmsten Fall eine neue Anmeldung, der dauerhafte Zustand liegt in der Datenbank.

Wie lange eine Anmeldung gilt und wie oft ihre Gültigkeit fortgeschrieben wird, steht in der Region-Konfiguration (session.ttl_hours, session.touch_interval_minutes) — siehe Regionenkatalog.

3.1 Über mehrere Regionen: ein Valkey-Cluster

Mit mehreren Regionen wird aus der einen Instanz ein Cluster, und DNSE_VALKEY_ADDR nennt mehrere Adressen:

DNSE_VALKEY_ADDR=vk-eu:6379,vk-na:6379,vk-apac:6379
DNSE_REGION=eu-central          # bestimmt, wo Anmeldungen dieses Knotens liegen

Jede Sitzung gehört der Region, in der sie entstand. Der Token trägt das sichtbar (eu-central~…), und der Speicherschlüssel bekommt die Region als Hash-Tag:

dnse:session:{eu-central}:eu-central~9f3a…

Alles in geschweiften Klammern bestimmt den Abschnitt (Slot). Damit liegen alle Sitzungen einer Region beisammen — und Schreibvorgänge landen von selbst beim Besitzer, weil der Client die Slot-Karte kennt. Ein Abmelden in einer fremden Region wirkt deshalb sofort und überall; gelesen wird trotzdem ortsnah, weil der Client unter den Knoten eines Slots den nächstgelegenen wählt.

Die Slot-Verteilung ist Handarbeit

Der Hash-Tag bindet eine Region an einen Slot — welcher Knoten diesen Slot hält, entscheidet aber der Aufbau des Clusters, nicht der Tag.

Ein einfaches valkey-cli --cluster create teilt die Slots gleichmäßig auf und weiß nichts von Regionen. In einem Aufbau mit drei Knoten kam dabei heraus: eu-central auf Knoten 3, na und apac gemeinsam auf Knoten 1, Knoten 2 leer. Das Ergebnis wäre Ortsbindung ohne Ortsbezug — alles beisammen, nur am falschen Ort.

Nach dem Aufbau also prüfen, welcher Knoten den Slot einer Region hält:

valkey-cli -p 6379 cluster keyslot 'dnse:session:{eu-central}:x'

und den Slot bei Bedarf gezielt auf den Knoten in dieser Region umziehen (cluster setslot … importing/migrating, migrate, dann auf allen Knoten cluster setslot … node <ziel>). Laufende Anmeldungen überstehen den Umzug — sie wandern mit.

Zwei Betriebsvorgaben gehören dazu, weil der Cluster-Bus hier über das WAN läuft: tls-cluster yes (oder ein Tunnel) — sonst liegen Sitzungen zwischen den Regionen im Klartext — und ein cluster-node-timeout, das an der tatsächlichen Laufzeit zwischen den Regionen gemessen und eher großzügig gesetzt ist. Sonst löst jede Delle in der Leitung eine Übernahme aus.

Bestehende Anmeldungen ohne Regionsmarke laufen unverändert weiter; sie behalten ihren alten Schlüssel und laufen von selbst aus. Eine Wanderung ist nicht nötig.

Hintergrundjobs im Cluster

Drift-Abgleich, Zertifikatsausstellung, Ablauf-Erinnerungen, Backup-Exporte und die Umzugs-Prüfung laufen als geplante Jobs. Jeder Knoten kann sie ausführen; ein Lease sorgt dafür, dass zu einer Zeit nur einer an einem Job arbeitet.

Achtung

Beim gleichzeitigen Start mehrerer Knoten greifen mehrere Prozesse auf dieselbe Job-Zeile zu. Das ist eingeplant: Wer den optimistischen Sperrkonflikt verliert, wertet das als Erfolg — ein anderer Knoten pflegt die Zeile gerade. Diese Toleranz kam aus einem echten Cluster-Fehlerbild und darf nicht „aufgeräumt” werden.

Testcluster

Für lokale Versuche gibt es einen fertigen Vier-Knoten-Aufbau mit YugabyteDB und Valkey: Testcluster.