Daten-Diplomatie: Wie asynchrone Replikation Latenzprobleme bei KRITIS löst

In einer Multi-Region-Architektur für kritische Infrastrukturen (KRITIS) ist die Datenkonsistenz die größte technische Herausforderung. Während wir Rechenleistung (Kubernetes-Pods) problemlos verdoppeln können, lassen sich Daten nicht ohne Weiteres an zwei Orten gleichzeitig „live" halten. Die Lichtgeschwindigkeit setzt uns Grenzen: Jede synchrone Bestätigung eines Schreibvorgangs über hunderte Kilometer hinweg erzeugt Latenzen, die eine Anwendung instabil machen können.

Für eine resiliente Plattform nutzen wir daher eine differenzierte Strategie für verschiedene Datentypen - von relationalen Datenbanken über Caches bis hin zu Message Brokern.

1. PostgreSQL: Lokale Stabilität trifft regionale Ausfallsicherheit

Für die Kern-Datenbanken setzen wir auf ein zweistufiges Modell. Das Ziel: Maximale Schreibgeschwindigkeit im Normalbetrieb und minimaler Datenverlust im Katastrophenfall.

• Innerhalb der Region (Synchron): Innerhalb eines Standorts werden Daten synchron auf ein Standby-System repliziert. Fällt ein Datenbank-Server aus, übernimmt der zweite ohne Datenverlust (High Availability).
• Zwischen den Regionen (Asynchron): Die Replikation zum zweiten Standort erfolgt asynchron. Das bedeutet, die Anwendung in Frankfurt muss nicht warten, bis Berlin den Empfang der Daten bestätigt. Dies verhindert, dass Netzwerk-Latenzen zwischen den Städten die Performance der Nutzer bremsen.
• Failover-Strategie: Im Falle eines kompletten Standort-Ausfalls wird die asynchrone Replika in der gesunden Region zum neuen „Master" befördert. Durch moderne Tools minimieren wir den hierbei entstehenden „Lag" auf Millisekunden.

2. Redis: Session-Persistenz für nahtlose Übergänge

In KRITIS-Systemen darf ein Failover die Nutzererfahrung nicht zerstören. Wenn ein Techniker eines Netzbetreibers gerade eine Schalthandlung koordiniert und der Standort wechselt, darf er nicht ausgeloggt werden.

• Global Sessions: Wir replizieren Redis-Instanzen regionenübergreifend. Dadurch stehen Session-Daten, Authentifizierungs-Tokens und temporäre Zustände an beiden Standorten zur Verfügung.
• Nutzen: Schwenkt der Traffic durch ein Netzwerkereignis um, erkennt die Instanz in der neuen Region den Nutzer sofort wieder. Der Failover bleibt für den Menschen vor dem Bildschirm nahezu unsichtbar.

3. RabbitMQ: Robuste Kommunikation durch Federation

Für die Kommunikation zwischen verschiedenen Diensten und die Verarbeitung von Sensordaten nutzen wir Message Broker. Hier ist es entscheidend, dass Nachrichten nicht verloren gehen, wenn eine Leitung unterbrochen wird.

• Federation & Shovel: Über diese Mechanismen koppeln wir RabbitMQ-Cluster zwischen den Regionen. Nachrichten können so zwischen den Standorten „fließen".
• Pufferung: Fällt die Verbindung zwischen den Regionen kurzzeitig aus, puffert der lokale Cluster die Nachrichten und synchronisiert sie automatisch nach, sobald die Verbindung wieder steht. Das ist essenziell für die lückenlose Erfassung von Netzzustandsdaten.

4. Secrets und Zertifikate: Vault als globale Quelle

Ein oft vergessener Punkt beim Failover sind kryptografische Schlüssel und Passwörter. Ein Cluster, der zwar hochfährt, aber keinen Zugriff auf seine Datenbank-Passwörter hat, ist wertlos. Wir setzen auf eine replizierte HashiCorp Vault-Instanz. Alle Secrets werden verschlüsselt zwischen den Regionen abgeglichen, sodass der Rettungsanker-Standort zu jeder Zeit „handlungsfähig" ist.

Fazit: Konsistenz ist kein Zufall, sondern Design

Echte Georedundanz akzeptiert die physikalischen Grenzen des Netzwerks. Anstatt zu versuchen, alles überall gleichzeitig zu erzwingen, priorisieren wir: Lokale Performance für den Alltag, asynchrone Sicherheit für den Ernstfall. Durch diese geschichtete Datenarchitektur stellen wir sicher, dass die KRITIS-Plattform nicht nur verfügbar ist, sondern auch mit korrekten und aktuellen Daten arbeitet.

FAQ

Besteht bei asynchroner Replikation nicht das Risiko von Datenverlust? Ja, theoretisch können bei einem harten Standort-Crash die letzten Millisekunden an Daten verloren gehen (Recovery Point Objective > 0). Für KRITIS-Systeme ist dieser kontrollierte Trade-off jedoch meist sicherer als ein synchrones System, das bei jeder kleinsten Netzschwankung die gesamte Produktion anhält.

Wie wird die Datenkonsistenz nach einem Failover geprüft? Wir nutzen automatisierte Checksummen-Vergleiche und Point-in-Time-Recovery-Mechanismen. Zudem sorgen wir durch „Fencing" dafür, dass der alte (defekte) Master niemals gleichzeitig mit dem neuen Master schreibt (Split-Brain-Vermeidung).

Können wir auch NoSQL-Datenbanken wie MongoDB oder Cassandra nutzen? Absolut. Viele NoSQL-Systeme bringen native Multi-Region-Features mit. Die Wahl der Datenbank hängt immer vom spezifischen Anwendungsfall und den Konsistenz-Anforderungen Ihrer Applikation ab.

Was passiert, wenn die Verbindung zwischen den Standorten länger unterbrochen ist? Die Systeme gehen in einen „Queue"-Modus über. Sobald die Verbindung wiederhergestellt ist, findet ein „Re-Sync" statt. Die Plattform ist so designt, dass beide Standorte auch isoliert voneinander (island mode) ihre lokalen Aufgaben weiter erfüllen können.

Wie unterstützt ayedo beim Design der Datenebene? Wir analysieren Ihre Datenflüsse und definieren gemeinsam mit Ihnen die passenden RPO- und RTO-Ziele. Wir implementieren die Replikations-Pipelines und sorgen durch regelmäßige Failover-Tests dafür, dass die Theorie der Daten-Sicherheit in der Praxis auch wirklich standhält.