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.

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.

Testcluster

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