Replikation: Wie viel Bandbreite braucht das Aufholen nach einem Ausfall?

Eine Replikationsverbindung muss nicht nur neue Änderungen übertragen. Nach einer Unterbrechung muss sie zusätzlich den Rückstand abbauen, während die Produktion weiterläuft. Für eine erste Planung gilt deshalb: benötigter Nutzdatendurchsatz = laufende Änderungsrate + Rückstand geteilt durch gewünschte Aufholzeit. Die Portgeschwindigkeit allein beantwortet diese Frage nicht. Entscheidend ist, welchen Durchsatz die Replikation zwischen den tatsächlichen Endpunkten nachhaltig erreicht.

Drei Betriebsphasen getrennt planen

• Erstbefüllung: Eine erste Datenbasis muss am zweiten Standort entstehen. Dafür gelten ein eigenes Datenvolumen und ein vereinbartes Zeitfenster.
• Normalbetrieb: Neue Änderungen müssen innerhalb des zulässigen Rückstands ankommen. Spitzen während Importen, Wartung oder Sicherungen gehören zum Lastprofil.
• Aufholen: Nach einer Unterbrechung konkurrieren aufgelaufene und neue Änderungen um dieselben Ressourcen. Eine Leitung, die im Normalbetrieb gerade ausreicht, hat hierfür keine Reserve.

Die konkrete Software bestimmt, was übertragen wird. NetApp beschreibt für die snapshotbasierte SnapMirror-Replikation eine initiale Basisübertragung und anschließende asynchrone Snapshot-Updates. Das ist kein universelles Modell für jede Replikation. Erfassen Sie bei Ihrem Produkt sowohl die fachliche Änderungsmenge als auch die tatsächlich übertragenen Bytes. Kompression, zusammengefasste Änderungen oder ein erforderlicher neuer Basisabgleich können die Mengen verändern.

Welche Messwerte gehören in die Rechnung?

Verwenden Sie für Änderungsrate, Rückstand und Durchsatz dieselbe Datenbasis. Ein Zähler für unkomprimierte Schreibdaten lässt sich nicht ohne Umrechnung mit komprimierten Netzwerkbytes vergleichen. Im folgenden Modell bezeichnet W die pro Sekunde neu zu replizierende Datenmenge, B den noch ausstehenden Bestand und C den effektiv verfügbaren Replikationsdurchsatz. Alle drei beziehen sich auf dieselben Nutzdaten; Protokoll-Overhead und anderer Verkehr sind in C bereits berücksichtigt.

• Änderungsrate über repräsentative Arbeitszyklen messen, nicht nur nachts oder als Tagesmittel. Spitzenhöhe und Dauer notieren.
• Rückstand in Bytes und Alter des nutzbaren Wiederherstellungspunkts getrennt erfassen. Ein kurzer Transfer bedeutet nicht automatisch einen aktuellen Datenstand.
• Erreichbaren Durchsatz mit realer Replikation und konkurrierenden Anwendungen prüfen. Portzähler, Softwarelimits und Ziel-Storage parallel beobachten.
• Einheiten eindeutig festlegen: In diesem Beitrag sind MB und GB dezimal; 1 MB/s entspricht 8 Mbit/s. MiB/s und GiB benötigen eine andere Umrechnung.

Auch der Begriff Lag ist produktspezifisch. Bei SnapMirror beschreibt NetApp ihn anhand des Snapshot-Zeitstempels und der Zeit am Ziel. Er ist nicht einfach die Dauer des letzten Transfers. Prüfen Sie die Definition des eingesetzten Zählers und synchronisierte Uhren, bevor Sie einen Alarmgrenzwert daraus ableiten.

Rechenbeispiel: Zwei Stunden Ausfall, eine Stunde zum Aufholen

Das folgende illustrative Planungsmodell ist keine Messung oder Zusage: Angenommen werden konstante 25 MB/s neu zu übertragende Nutzdaten, zwei Stunden ohne Übertragung und anschließend eine Stunde zum vollständigen Aufholen. Alle Änderungen bleiben verfügbar und müssen übertragen werden. Es gibt weder Kompressionseffekte noch einen neuen vollständigen Basisabgleich. Diese Annahmen müssen für eine reale Anwendung geprüft werden.

1. 1Rückstand berechnen: 25 MB/s × 7.200 s = 180.000 MB, also 180 GB.
2. 2Zusätzlichen Durchsatz zum Aufholen bestimmen: 180.000 MB ÷ 3.600 s = 50 MB/s.
3. 3Weiterlaufende Produktion addieren: 50 + 25 = 75 MB/s, entsprechend 600 Mbit/s Nutzdatendurchsatz.

600 Mbit/s sind hier keine bestellfertige Leitungsgröße. Hinzu kommen die Anforderungen an Protokoll-Overhead, parallelen Verkehr und betriebliche Reserve. Wie groß diese ausfallen, hängt von Ihrem Aufbau ab. Ein pauschaler Zuschlag ersetzt keine Messung. Umgekehrt beweist ein 1-Gbit/s-Port nicht, dass die Replikation 75 MB/s erreicht.

Die Gegenprobe macht die Reserve sichtbar: Erreicht dieselbe Replikation nur C = 40 MB/s, bleiben nach Abzug der laufenden W = 25 MB/s noch 15 MB/s für den Rückstand. 180.000 MB ÷ 15 MB/s ergeben 12.000 Sekunden, also drei Stunden und zwanzig Minuten. Bei C = W wird der Rückstand im Modell nicht kleiner; bei C < W wächst er. Allgemein gilt für konstante Raten und C > W: Aufholzeit = B ÷ (C − W).

Aufholzeit ist nicht dasselbe wie RPO oder RTO

Das Recovery Point Objective (RPO) beschreibt den tolerierten Datenverlust in zeitlicher Hinsicht. Das Recovery Time Objective (RTO) beschreibt die angestrebte Zeit bis zur Wiederherstellung des Dienstes. Die errechnete Aufholzeit beschreibt dagegen, wann eine zurückliegende Kopie unter den Modellannahmen wieder aktuell ist. Ein einstündiges Aufholziel bedeutet daher weder ein RPO von einer Stunde noch einen innerhalb einer Stunde wieder nutzbaren Dienst.

Synchrone Replikation wartet je nach Produkt auf Bestätigung vom Ziel und reagiert deshalb auf Latenz anders als asynchrone Übertragung. Beispielsweise nennt Microsoft für synchrone Storage Replica eine durchschnittliche Round-Trip-Latenz von höchstens 5 ms und ausreichend Bandbreite für die Schreiblast. Das ist eine produktspezifische Anforderung, kein allgemeiner L2-Grenzwert und keine Latenzzusage für eine bestimmte Strecke. Ein höherer Durchsatz beseitigt keine zu lange Bestätigungszeit.

Wenn mehr Bandbreite den Rückstand nicht behebt

Prüfen Sie zunächst, ob die Leitung überhaupt der begrenzende Faktor ist. NetApp dokumentiert beispielsweise globale und beziehungsbezogene Bandbreitenlimits, die zusammenwirken können. Ebenso gehören Lese- und Schreibleistung, Verarbeitung und die konfigurierte Übertragungsplanung auf die Prüfliste. Mehr Leitungskapazität kann einen niedrigeren Softwaregrenzwert nicht überschreiben.

Für TCP-basierte Übertragung nennt RFC 6349 unter anderem Path MTU, Round-Trip-Zeit, Engpassbandbreite und TCP-Fenster als relevante Größen. Ein Test mit vielen parallelen Verbindungen kann einen anderen Durchsatz zeigen als die tatsächliche Anwendung. Prüfen Sie daher neben dem Transport auch die Replikation selbst. Eine größere MTU nur an einem Endgerät einzustellen ist kein belastbarer Optimierungsnachweis.

Abnahme: den Wiederanlauf mitprüfen

1. 1Ein autorisiertes Testfenster mit Lastgrenzen und Abbruchkriterien vereinbaren. Keine unangekündigte Sättigung einer produktiven Verbindung.
2. 2Den Normalbetrieb bei repräsentativer Last messen: Änderungsrate, Durchsatz, Rückstand und Zustand der Anwendung dokumentieren.
3. 3Einen definierten Rückstand in einer geeigneten Testumgebung erzeugen. Danach bei weiterlaufenden Änderungen messen, wie schnell er tatsächlich schrumpft.
4. 4Prüfen, ob genügend Log- oder Snapshot-Aufbewahrung vorhanden ist. Falls die Software nach langer Unterbrechung neu initialisieren muss, gilt die einfache Rückstandsrechnung nicht mehr.
5. 5Den vorgesehenen Ersatzweg und die Rückrichtung einbeziehen. Nach einem Standortwechsel können Daten in die andere Richtung fließen; dokumentieren Sie dafür ein eigenes Lastprofil.
6. 6Den Wiederherstellungspunkt und einen echten Anwendungsvorgang am Ziel kontrollieren. Ein leerer Übertragungspuffer allein ist noch kein bestandener Wiederanlauftest.

Mit diesen Angaben eine Standortverbindung anfragen

Nennen Sie beide Übergabepunkte, Replikationsprodukt und Modus, gemessene Änderungsraten, geplante Erstbefüllung, tolerierte Unterbrechung und gewünschte Aufholzeit. Ergänzen Sie parallele Dienste, Verschlüsselung, MTU, RPO/RTO und Anforderungen an den Ersatzweg. Damit lassen sich Kapazität und Abnahmekriterien konkret abstimmen. Ob L2 erforderlich ist oder geroutete IP-Erreichbarkeit genügt, ergibt sich aus der Anwendung; der Transport allein garantiert keinen Wiederherstellungszeitpunkt.