5 Datenreplikation gehört zu den folgenreichsten Infrastrukturentscheidungen Ihres Unternehmens. Richtig umgesetzt, überstehen Sie den Ausfall ganzer Rechenzentren und halten den Betrieb während Wartungsarbeiten aufrecht. Falsch umgesetzt, entdecken Sie katastrophale Fehlerbilder erst bei Vorfällen in der Produktion. Dieser Leitfaden behandelt Strategien für die Datenreplikation – von synchronen und asynchronen Modellen bis zu Architekturen nach dem Muster Active-Active oder Active-Passive – mit ihren Folgen für Ihre Recovery Time Objectives und Recovery Point Objectives sowie Empfehlungen für Workloads, bei denen ein Ausfall keine Option ist. Der grundlegende Zielkonflikt: Konsistenz vs. Verfügbarkeit Datenreplikation löst ein grundlegendes Problem: Wie stellen Sie sicher, dass Daten Ausfälle überstehen? Die Antwort – mehrere Kopien auf physisch getrennten Systemen – schafft ein neues Problem: die Kopien konsistent zu halten. Dieses Spannungsfeld prägt alle Replikationsstrategien. Synchrone Replikation wartet, bis alle Replikate einen Schreibvorgang bestätigt haben, bevor sie den Erfolg meldet. Das garantiert starke Konsistenz, erhöht aber die Schreiblatenz. Ist ein Replikat langsam oder nicht verfügbar, wird das gesamte System langsamer oder fällt aus. Asynchrone Replikation bestätigt Schreibvorgänge sofort und überträgt die Änderungen im Hintergrund. Das ermöglicht schnelle Schreibvorgänge und Fehlertoleranz. Es schafft jedoch eine Schwachstelle: Fällt das primäre System aus, bevor die Änderungen übertragen wurden, gehen diese Schreibvorgänge verloren. Während der Übertragung enthalten die Replikate veraltete Daten. Ihre Strategie sollte geschäftliche Anforderungen widerspiegeln, nicht theoretische Vorlieben. Ein Finanzsystem erfordert womöglich synchrone Replikation – die Latenz ist akzeptabel, weil verlorene Transaktionen katastrophal wären. Ein Content Delivery Network bevorzugt womöglich asynchrone Replikation – Benutzer akzeptieren eine Verzögerung bei der Verteilung, doch das System muss Millionen gleichzeitiger Anfragen bewältigen. Synchrone Replikation: wenn bei der Konsistenz keine Kompromisse möglich sind Bei synchroner Replikation werden Schreibvorgänge erst abgeschlossen, wenn alle Replikate (oder ein Quorum) sie bestätigt haben. Das garantiert Konsistenz, verursacht aber betriebliche Kosten. Ihre Infrastruktur wartet auf das langsamste Replikat der Gruppe. Bei einer Replikation über geografische Regionen hinweg wird das gesamte System durch die langsamste Verbindung begrenzt. Viele Unternehmen setzen synchrone Replikation innerhalb eines Rechenzentrums ein (niedrige Latenz, hohe Bandbreite) und asynchrone Replikation zu entfernten Standorten (höhere Latenz, begrenzte Bandbreite). Die eigentliche Stärke synchroner Replikation zeigt sich bei kaskadierenden Ausfällen. Fällt Ihr primäres Rechenzentrum vollständig aus, hat Ihr sekundäres bereits jeden bestätigten Schreibvorgang. Sie können sofort und ohne Datenverlust umschalten. Das ist unverzichtbar, wenn Datenverlust inakzeptabel ist. Synchrone Replikation erfordert jedoch eine sorgfältige Fehlerbehandlung. Was passiert, wenn ein Replikat nicht mehr verfügbar ist? Ihr System muss entscheiden: unbegrenzt warten (zulasten der Verfügbarkeit), das ausgefallene Replikat entfernen (vorübergehend zulasten der Dauerhaftigkeit) oder die Replikation vorübergehend herabstufen (mit geringerer Redundanz). Die meisten Produktionssysteme setzen auf quorumbasierte synchrone Replikation, bei der eine Mehrheit der Replikate Schreibvorgänge bestätigen muss. So kann ein Replikat ausfallen, ohne die Schreibvorgänge zu blockieren. Asynchrone Replikation: Optimierung für Performance und Fehlertoleranz Asynchrone Replikation bestätigt Schreibvorgänge sofort und überträgt sie im Hintergrund. Das entkoppelt die Schreiblatenz von der Replikationslatenz und ermöglicht schnellere Schreibvorgänge. Es wirft jedoch Fragen zum RPO (Recovery Point Objective) auf. Fällt Ihr primäres System aus, verlieren Sie alle noch nicht übertragenen Schreibvorgänge. Die Zeit zwischen dem Abschluss eines Schreibvorgangs und seiner Replikation bestimmt das RPO. Replizieren Sie alle 10 Sekunden, verlieren Sie höchstens 10 Sekunden. Replizieren Sie stündlich, verlieren Sie bis zu einer Stunde. Die meisten Produktionssysteme setzen auf asynchrone Replikation mit festgelegten Intervallen. Sie replizieren etwa alle 5 Minuten und garantieren so, dass ein Ausfall des primären Systems nicht mehr als 5 Minuten kostet. Dieses RPO eignet sich für viele Workloads und schafft eine klare Abwägung zwischen Replikationshäufigkeit (die Bandbreite verbraucht) und dem Risiko von Datenverlust. Asynchrone Replikation geht souverän mit dem Ausfall von Replikaten um. Ein langsames oder offline geschaltetes Replikat beeinträchtigt die Schreiblatenz nicht – das primäre System arbeitet weiter, und das Replikat holt nach seiner Wiederherstellung auf. Diese Resilienz macht asynchrone Replikation für Deployments über mehrere Rechenzentren mit unvorhersehbaren Bedingungen beliebt. Asynchrone Replikation bringt jedoch Komplexität mit sich: das Aufholen der Replikate nach einem Ausfall des primären Systems. Fällt das primäre System aus, während die Replikation hinterherhinkt, und schalten Sie auf ein Replikat um, wird dieses Replikat mit veralteten Daten zum neuen primären System. Kommt das ursprüngliche primäre System zurück, müssen Sie es mit dem Replikat abgleichen, das übernommen hat. Manche Systeme nutzen konfliktfreie replizierte Datentypen (CRDTs) oder Last-Write-Wins-Semantik. Andere erfordern manuelle Eingriffe, was die Wiederherstellung erschwert. Active-Passive- und Active-Active-Architekturen Neben der Wahl zwischen synchron und asynchron müssen Sie sich für ein Architekturmodell entscheiden: Active-Passive oder Active-Active. In einer Active-Passive-Architektur empfängt ein Replikat (das primäre) alle Schreibvorgänge. Sekundäre Replikate sind schreibgeschützt. Anwendungen lesen vom primären Replikat. Fällt es aus, schalten Sie auf ein sekundäres um. Active-Passive ist unkompliziert: Alle Schreibvorgänge gehen an einen Ort, was die Komplexität eines verteilten Konsenses vermeidet. Der Failover erfolgt jedoch nicht automatisch. Jemand muss den Ausfall erkennen, entscheiden, welches sekundäre Replikat hochgestuft wird, und die Anwendungen neu konfigurieren. Das dauert in der Regel einige Minuten. In diesem Zeitfenster ist Ihr System nicht verfügbar. Ihre RTO- und RPO-Ziele zu kennen, ist entscheidend, um Failover-Verfahren zu gestalten, die Ihren geschäftlichen Anforderungen entsprechen. In einer Active-Active-Architektur nehmen mehrere Replikate gleichzeitig Schreibvorgänge an. Anwendungen verteilen die Schreibvorgänge auf mehrere primäre Replikate. Jedes Replikat kann Lesezugriffe bedienen. Fällt ein primäres Replikat aus, arbeiten die anderen ohne Failover-Verfahren weiter. Active-Active ist komplexer, bietet aber eine bessere Verfügbarkeit. Ohne Single Point of Failure gibt es keine Verzögerungen durch einen Failover. Es entstehen jedoch Herausforderungen bei der Konsistenz. Nehmen zwei primäre Replikate gleichzeitig widersprüchliche Schreibvorgänge an – wie lösen Sie den Konflikt? Die Fachliteratur zu verteilten Systemen bietet Lösungen – Vektoruhren, Operational Transformation, kausale Konsistenz –, doch jede bringt betrieblichen Aufwand und Komplexität mit sich. Die meisten Active-Active-Systeme setzen auf Eventual Consistency: Replikate können vorübergehend auseinanderlaufen, gleichen sich mit der Zeit aber an. Anwendungen müssen tolerieren, dass sie leicht veraltete Daten lesen oder ein Schreibvorgang rückgängig gemacht wird, wenn ein Konflikt zugunsten eines anderen Replikats aufgelöst wird. Geografische Replikation und Deployments über mehrere Regionen Viele Unternehmen replizieren über geografische Regionen hinweg, um für Disaster Recovery gerüstet zu sein oder Daten näher an die Benutzer zu bringen. Geografische Replikation bringt Herausforderungen bei der Latenz mit sich. Die Lichtgeschwindigkeit begrenzt das Replikationstempo zwischen Kontinenten. Ein Schreibvorgang in US East kann allein wegen der Signallaufzeit im Netzwerk nicht in weniger als 130 ms nach Asien-Pazifik repliziert werden. Deshalb ist synchrone geografische Replikation selten praktikabel – jeder Schreibvorgang trägt die Latenz zwischen Kontinenten. Geografische Replikation nutzt stattdessen eine asynchrone Übertragung mit klar definierten RPO- und RTO-Zielen. Sie replizieren etwa alle 5 Minuten und tolerieren bis zu 5 Minuten Datenverlust. Für den Failover halten Sie womöglich ein manuelles Verfahren vor, das 30 Minuten benötigt, um eine entfernte Region zur primären zu machen. Für das Disaster Recovery ist das akzeptabel, für die Hochverfügbarkeit innerhalb einer Region nicht. Manche Unternehmen setzen auf hierarchische Replikation: synchrone Replikation innerhalb eines Rechenzentrums (Schutz vor dem Ausfall einzelner Knoten), asynchrone Replikation zwischen Rechenzentren in derselben Region (Schutz vor dem Ausfall eines Rechenzentrums) und langsamere asynchrone Replikation zwischen geografischen Regionen (Schutz vor regionalen Katastrophen). Das schafft mehrere Schutzebenen mit jeweils passendem RPO und RTO. RPO und RTO: Replikationsentscheidungen datenbasiert treffen Ihre Replikationsstrategie muss auf tatsächlichen geschäftlichen Anforderungen beruhen. Recovery Point Objective (RPO) ist der maximale Datenverlust, den Sie bei einem Ausfall tolerieren können, gemessen in Zeit. Liegt Ihr RPO bei 1 Stunde, muss die Replikation sicherstellen, dass kein Ausfall mehr als 1 Stunde Datenverlust verursacht. Das kann synchrone Replikation innerhalb eines Rechenzentrums (RPO von null) plus asynchrone Replikation an einen Backup-Standort alle 60 Minuten bedeuten. Recovery Time Objective (RTO) ist die maximale Zeit, die Sie ohne Zugriff auf Daten tolerieren können. Liegt Ihr RTO bei 15 Minuten, müssen die Failover-Mechanismen den Betrieb innerhalb von 15 Minuten wiederherstellen. Das kann einen automatisierten Failover und sofort verfügbare Standby-Kapazität erfordern. Unterschiedliche Workloads haben unterschiedliche Anforderungen. Ein kundennahes Zahlungssystem erfordert womöglich ein RPO von Sekunden und ein RTO von Minuten. Ein internes Analysesystem toleriert womöglich ein RPO von Stunden und ein RTO von Tagen. Regulatorische Anforderungen geben oft konkrete Ziele vor. Ihr Infrastrukturteam sollte RPO und RTO für jedes wichtige Datensystem dokumentieren und dann prüfen, ob die Architektur diese Ziele erreicht. Viele Unternehmen stellen bei Disaster-Recovery-Tests fest, dass die theoretischen RPO- und RTO-Werte nicht der Realität entsprechen – die Erkennung ist langsamer, der Failover dauert länger oder die Wiederherstellung enthält undokumentierte manuelle Schritte. Konsistenzmodelle und ihre Folgen für Anwendungen Unterschiedliche Replikationsmodelle bieten unterschiedliche Konsistenzgarantien. Starke Konsistenz: Alle Replikate haben identische Daten. Lesevorgänge sehen immer die jüngsten Schreibvorgänge. Mit synchroner Replikation erreichbar, aber auf Kosten der Latenz. Vereinfacht die Anwendungslogik, ist aber womöglich unnötig. Eventual Consistency: Replikate laufen vorübergehend auseinander, gleichen sich aber mit der Zeit an. Anwendungen sehen womöglich vorübergehend veraltete Daten. Bietet bessere Verfügbarkeit und Fehlertoleranz. Erfordert, dass Anwendungen vorübergehende Inkonsistenzen tolerieren. Kausale Konsistenz: Vorgänge behalten ihre kausale Reihenfolge. Hängt Schreibvorgang B von Schreibvorgang A ab, sehen alle Replikate A vor B. Konsistenter als Eventual Consistency, weniger aufwendig als starke Konsistenz. Für viele Anwendungen gut geeignet. Sitzungskonsistenz: Innerhalb einer Benutzersitzung sehen Anwendungen konsistente Daten. Verschiedene Sitzungen sehen womöglich unterschiedliche Versionen. Ein Kompromiss zwischen Konsistenz und Verfügbarkeit. Ihre Strategie sollte ausdrücklich festlegen, welches Konsistenzmodell Sie bieten. Anwendungen, die von starker Konsistenz ausgehen, aber mit letztlich konsistenter Replikation laufen, zeigen bei Ausfällen subtile Fehler. Umgekehrt tolerieren Anwendungen, die für Eventual Consistency entworfen sind, auseinanderlaufende Replikate, was den Replikationsaufwand verringert. Replikation im Unternehmen architektonisch planen Beantworten Sie für Ihr Unternehmen mehrere Fragen: Wie lauten die tatsächlichen RPO- und RTO-Anforderungen für jedes Datensystem? Welchen geografischen Umfang brauchen Sie – ein Rechenzentrum, mehrere Rechenzentren, mehrere Regionen? Wie viel Replikationslatenz können Sie tolerieren? Was passiert, wenn die Replikation in Verzug gerät? Wie testen Sie, ob die Replikation tatsächlich funktioniert? Die meisten großen Unternehmen setzen auf mehrstufige Ansätze: Replikation mit starker Konsistenz innerhalb eines Rechenzentrums (mit moderater Latenz für kritische Systeme), schwächere Konsistenz zwischen Rechenzentren (Auseinanderlaufen wird für bessere Fehlertoleranz akzeptiert) und asynchrone Replikation zwischen Regionen (optimiert für Disaster Recovery). Die Umsetzung einer Architektur für die Replikation über mehrere Standorte (auf Englisch) erfordert sorgfältige Planung und Tests. Dafür müssen Infrastruktur-, Anwendungs- und Betriebsteams zusammenarbeiten. Anwendungen müssen ihre Konsistenzanforderungen kennen. Die Infrastruktur muss die passende Replikation bereitstellen. Der Betrieb muss die Fehlerbilder verstehen und über getestete Wiederherstellungsverfahren verfügen. Zudem stellen ransomwareresistente Backup-Strategien sicher, dass sich kompromittierte Systeme wiederherstellen lassen. Wer die Hochverfügbarkeit aufrechterhält, schützt sich vor kaskadierenden Ausfällen. Wenn Sie Ihre Replikationsstrategie auf geschäftliche Anforderungen stützen und gründlich testen, wird aus der Datenreplikation statt theoretischer Infrastruktur ein praxistauglicher Resilienzmechanismus, der Ihr Unternehmen tatsächlich schützt. Weiterführende Artikel RTO vs. RPO: Die wichtigsten Unterschiede erklärt Hochverfügbarkeit (HA) Business-Continuity-Plan Den Ausfall eines Rechenzentrums überstehen: Planung für Resilienz DRaaS: Disaster Recovery as a Service Enterprise-Backup-Strategie Datenbeständigkeit vs. Datenverfügbarkeit (auf Englisch)
