Datenreplikation und Failover

Die Replikations-Architektur ist primär eine Backup- und Hochverfügbarkeits-Lösung, die für alle Anwendungen möglich ist. Dabei läuft die Anwendung auf einem Server und wird automatisch auf dem zweiten Server gestartet, wenn der erste Server ausfällt.

Mit den Möglichkeiten der Datei-basierten Datenreplikation ist diese Architektur besonders geeignet, Hochverfügbarkeit für Backend-Anwendungen mit kritischen Daten zu gewährleisten und diese somit vor Ausfall zu schützen.

Microsoft SQL Server.safe, MySQL.safe und Oracle.safe sind Beispiele für derartige Replikations-Module. Eigene Replikations-Module können basierend auf dem Generic Module Mirror.safe erstellt werden.

Der Sicherungsmechanismus arbeitet wie folgt:

Schritt 1: normaler Betrieb

: zur Vergrößerung bitte Anklicken

Die Server sind so konfiguriert, dass die Anwendungsdaten repliziert werden. Es gibt für beide Server keine besonderen Anforderungen an die Plattenorganisation.

Z.B.: Die zu replizierenden Daten befinden sich auf dem internen RAID5-Volume auf Server 1 und auf einer einfachen internen Festplatte auf Server 2.

Während auf Server 1 die Anwendung läuft, repliziert SafeKit die durch die Anwendung geänderten Daten. Es werden ausschließlich die Änderungen in Echtzeit über das Netzwerk repliziert. So wird der notwendige Datenverkehr begrenzt. Aufgrund der synchronen Replikation beim Schreiben der Daten auf beide Festplatten der Server gehen im Fall einer Störung keine Daten verloren.

Durch die synchrone Replikation wird garantiert, dass alle Daten, die auf eine Festplatte geschrieben werden, auf einem zweiten Server sofort verfügbar sind. Dies ist mit asynchroner Replikation nicht möglich.

Schritt 2: Ausfallabsicherung (Failover)

: zur Vergrößerung bitte Anklicken

Wenn Server 1 ausfällt, übernimmt Server 2: SafeKit schaltet die virtuelle Cluster-IP um und startet die Anwendung automatisch auf dem Server 2. Die Anwendung findet alle Daten genauso vor, wie sie auf Server 1 vor dem Ausfall vorlagen.

Die Umschaltzeit entspricht dabei der Fehlererkennungszeit (voreingestellt auf 30 Sekunden) plus der Startzeit der Anwendung. Im Unterschied zu Disk-Replikationslösungen gibt es keinen Zeitverzug bei der Wiederherstellung des Dateisystems und eventuell notwendiger Wiederherstellungs-Prozesse.

Schritt 3: Rückfallsicherung (Failback)

: zur Vergrößerung bitte Anklicken

Nachdem das Problem behoben wurde, das den Ausfall verursacht hat, wird Server 1 neu gestartet. Das ist notwendig, um den Ausgangszustand wiederherzustellen. SafeKit gleicht die Daten automatisch ab. Dabei werden nur die geänderten Daten von Server 2 ab dem Zeitpunkt aktualisiert, ab dem die Verbindung zu Server 1 unterbrochen war.

Dieser Abgleich findet statt, ohne die Anwendung zu unterbrechen, die auf Server 2 läuft. Dies ist eine Hauptfunktion von SafeKit. Damit unterscheidet es sich von anderen Anwendungen, die es erforderlich machen, die Anwendungen auf Server 2 anzuhalten, um Server 1 wieder zu synchronisieren.

Schritt 4: normaler Betrieb

: zur Vergrößerung bitte Anklicken

Nach dem Abgleich sind die Datenbestände wieder synchron, wie in Schritt 1. Das System ist wieder hochverfügbar. Auf Server 2 läuft die Anwendung und SafeKit repliziert die Datenänderungen auf den Backup-Server 1. Wenn die Anwendung wieder auf Server 1 laufen soll, kann ein „Switchover“-Befehl (automatisch oder manuell je nach Konfiguration) ausgeführt werden.

Synchrone, fehlertolerante Replikation ohne Datenverlust bei Ausfall eines Servers

Es gibt einen signifikanten Unterschied zwischen synchroner Replikation, wie sie SafeKit bietet, und asynchroner Replikation:

Mit asynchroner Replikation gehen alle Daten verloren, die im Moment des Absturzes noch nicht auf den Server 2 kopiert wurden. Davon sind dann insbesondere transaktionsbezogene Anwendungen betroffen, die bestimmte Aktionen verlieren können.
SafeKit eliminiert diesen Verlust von Daten im Fall eines Serverausfalls durch die synchrone Echtzeit-Replikation der geänderten Daten einer Anwendung.

Eine bestimmte Bandbreite ist im LAN ist notwendig, um die synchrone Datenreplikation zu implementieren. Dies ist besonders bei einem erweiterten LAN z.B. zwischen Rechenzentren an unterschiedlichen Standorten, zu beachten. Asynchrone Replikation kann vorzugsweise für Datenreplikation im langsamen WAN eingesetzt werden, um Daten über Distanzen von mehr als 100 km Entfernung zu sichern.