DRBD Proxy / WAN-Erfahrungen

Ich möchte die Verwendung von DRBD für die Datenreplikation zwischen einem primären und einem sekundären Standort in Betracht ziehen. Der ursprüngliche Plan besteht darin, einen VPN-Tunnel zwischen den beiden einzurichten. Das primäre Ende verwendet einen Slice einer dualen T1-Verbindung und die Einstellung für den sekundären Standort auf einer Kabel- / DSL-Leitung.

Die Sekundärseite ist nur für DR vorhanden - sie wird "nie" wieder auf die Primärseite repliziert.

Hat jemand so etwas getan / müde / benutzt und was sind deine Erfahrungen damit?

Linbit hat auch ein (kostenpflichtiges) DRBD-Proxy-Produkt, das für den Betrieb über WAN-Verbindungen (Komprimierung, mehrere Peers) ausgelegt sein soll. Hat das jemand ausprobiert?

Ich kann nicht für DRBD-Proxy sprechen, aber die reguläre DRBD wird nicht so sehr mögen.

Selbst bei begrenzter Aktivität können Sie einen Dual-T1 (2x 1,5 Mbit / s; für runde Zahlen 300 KB / s) problemlos sättigen. 300 KB / s können allein durch Anwendungsprotokollierung belegt werden, geschweige denn durch interessante Aktionen auf Ihrem Server. Dies schließt eine synchrone Replikation ( Protokoll C ) aus, geschweige denn das Hinzufügen der Latenz über den VPN zur Gleichung.

Die asynchrone Replikation ( Protokoll A ) funktioniert möglicherweise technisch, aber ich würde erwarten, dass die sekundäre Replikation so weit veraltet ist, dass sie im Falle eines Fehlers nicht verwendet werden kann (die Replik kann tagsüber Stunden zurückliegen).

Speichersynchron ( Protokoll B ) hilft nicht, da es immer noch durch das Bandbreitenproblem eingeschränkt ist.

Ich gehe davon aus, dass DRBD Proxy weiterhin unter ähnlichen Problemen leiden wird, die hauptsächlich aufgrund der begrenzten Bandbreite zu Replikationsverzögerungen führen.

Ich empfehle Ihnen, Ihre DR-Strategie neu zu bewerten, um herauszufinden, gegen was Sie Abhilfe schaffen. Hardwarefehler oder Standortfehler.

Im Fall des Schutzes vor Standortfehlern können Sie bei Übertragungen mit geringerer Bandbreite / höherer Dichte bei einem Standort mit eingeschränkter Bandbreite (oder beiden) eine bessere Kilometerleistung erzielen. Einige Beispiele für diese Technik sind rsync (Over-the-Wire-Übertragungen beschränken sich auf Änderungen in Dateien zwischen Läufen - und nicht auf Änderungen pro Änderung - plus Protokollaufwand; können über SSH ausgeführt werden, um den Datenverkehr weiter zu verschlüsseln und zu komprimieren) und Versand von Datenbankprotokollen (das Übertragen komprimierter Datenbankprotokolle zur Wiedergabe auf der DR-Box benötigt möglicherweise weniger Bandbreite als das Übertragen eines vollständigen Datenbankspeicherauszugs).

Wenn Sie vor Hardwarefehlern schützen, funktioniert ein lokales DRBD-Replikat, das mit einer GigE-Frequenzweiche verbunden ist, einwandfrei, ermöglicht vollständig synchrone Aktualisierungen und ermöglicht die Online-Überprüfung, um zu beweisen, dass die Daten auf beiden Knoten konsistent sind. Sie können diese Option weiterhin mit einer eingeschränkten Dateireplikation auf einen DR-Standort kombinieren, um sich vor einem Ausfall des primären Standorts zu schützen.

DRBD-Proxy funktioniert einwandfrei, vorausgesetzt, Sie sättigen die T1-Verbindungen nicht ständig. Wir versenden viele 2-TB-Dateien über eine DRBD-Proxy-Verbindung (gewährt mit 100-Megabit-Link) ohne Probleme. Vorausgesetzt, Sie haben genügend RAM für den Proxy und die Anzahl der Schreibvorgänge ist nicht so hoch, dass Ihr T1 dies nicht bewältigen kann. Dies sollte einwandfrei funktionieren. Sie möchten jedoch den Async-Modus für die Replikation verwenden.