Hyper-V
Failover von Oracle Datenbanken mit aktiver SnapMirror Synchronisierung
Änderungen vorschlagen
PDFs
Der Hauptgrund für das Hosten einer Oracle-Datenbank auf SnapMirror Active Sync ist die Bereitstellung eines transparenten Failovers bei geplanten und ungeplanten Storage-Ereignissen.
SnapMirror Active Sync unterstützt zwei Arten von Storage Failover-Operationen: Geplant und ungeplant, welche jeweils auf ein geringfügig unterschiedliches Verfahren funktionieren. Ein geplantes Failover wird manuell vom Administrator initiiert, um eine schnelle Umschaltung auf einen Remote-Standort zu ermöglichen, während der ungeplante Failover automatisch vom Mediator am dritten Standort initiiert wird. Der primäre Zweck eines geplanten Failovers ist die Durchführung inkrementeller Patches und Upgrades, Durchführung von Disaster-Recovery-Tests oder die Einführung einer formellen Richtlinie für den Wechsel zwischen Standorten während des ganzen Jahres, um die volle aktive Synchronisierungsfunktion zu belegen.
Die Diagramme zeigen die Vorgänge während des normalen Failover und Failback-Vorgangs an. Zur einfachen Illustration zeigen sie eine replizierte LUN. In einer tatsächlichen Konfiguration mit SnapMirror für aktive Synchronisierung basiert die Replizierung auf Volumes, bei denen jedes Volume eine oder mehrere LUNs enthält. Zur Vereinfachung des Bilds wurde jedoch die Volume-Ebene entfernt.
Normaler Betrieb
Im normalen Betrieb kann auf eine LUN entweder über das lokale oder Remote-Replikat zugegriffen werden. Die rote Linie zeigt den optimierten Pfad an, wie von ALUA angekündigt, und das Ergebnis sollte sein, dass IO bevorzugt über diesen Pfad gesendet wird.
Die grüne Linie ist ein aktiver Pfad, aber es käme zu einer höheren Latenz, da I/O auf diesem Pfad über den aktiven SnapMirror Synchronisierungspfad geleitet werden müsste. Die zusätzliche Latenz hängt von der Geschwindigkeit der Verbindung zwischen Standorten ab, die für die aktive SnapMirror Synchronisierung verwendet wird.
Ausfall
Wenn die aktive gespiegelte Kopie aufgrund eines geplanten oder ungeplanten Failover nicht mehr verfügbar ist, ist sie offensichtlich nicht mehr nutzbar. Das Remote-System verfügt jedoch über ein synchrones Replikat, und es sind bereits SAN-Pfade zum Remote-Standort vorhanden. Das Remote-System kann E/A für diese LUN bedienen.
Failover
Durch Failover wird die Remote-Kopie zur aktiven Kopie. Die Pfade werden von „aktiv“ in „aktiv/optimiert“ geändert und I/O-Vorgänge werden weiterhin ohne Datenverlust verarbeitet.
Reparieren
Sobald das Quellsystem wieder einsatzbereit ist, kann die SnapMirror Active Sync Replizierung neu synchronisieren, aber in die andere Richtung ausführen. Die Konfiguration ist jetzt im Wesentlichen dieselbe wie der Startpunkt, mit Ausnahme, dass die Active-Mirror-Standorte gespiegelt wurden.
Failback
Auf Wunsch kann ein Administrator ein Failback durchführen und die aktive Kopie der LUN(s) zurück auf die ursprünglichen Controller verschieben.