Sichere Daten mit OSL Storage Cluster

Transkript

1 Sichere Daten mit OSL Storage Cluster Alternative Konzepte für die Datensicherung und Katastrophenvorsorge Dipl.-Ing. Torsten Pfundt

2 Gliederung Voraussetzungen für die Konzepte und Lösungen restorefreies Recovery Hochgeschwindigkeits-Backup und -Restore OSL Storage Cluster und Disaster Recovery Vorstellung der integrierten Lösungen für Oracle und Networker

3 Grundlage für die vorgestellten Konzepte: OSL Storage Universen (XDM) Produktion Backup typische Rechenzentren haben Server und Storage, die logisch oder physisch in mehrere Sektionen aufgeteilt werden (Produktion, Backup und Test) Tap e Library In vielen Fällen gibt es Beziehungen: - Testsysteme sind Kopien der Produktionssysteme - Backup ist vollständige Kopie des Produktionssystems - Beim Produktionsausfall kann das Backup direkt gestartet werden (kein Restore erforderlich)... Test OSL Storage Universen spiegeln die Zuordnung von Resourcen zu speziellen Nutzungsprofilen wieder Universe 1 (test) Universe 0 (production) Universe 2 (backup) Clone Objekte in anderen Universen können jederzeit erstellt werden, sie erhalten den gleichen Namen wie die Quelle Storage Cluster kennt die Beziehungen zwischen Objekten in verschiedenen Universen oracle origloga origlogb oradata oracle origloga origlogb oradata oracle origloga origlogb oradata Volle Integration in das Betriebssystem - einfache Identifikation durch den gleichen Namen - Zugriff zu jeder Zeit und von jedem Host aus

4 Serverseitige Virtualisierung OSL Storage Cluster und EAS (Encapsulated Application Setup) Trennung von Knoten, Betriebssystem und Applikationen global eindeutige Pfade (Mountpunkte) für die Applikationen Freie Migration der Applikationen zwischen den Cluster Knoten einfacher Austausch von (defekten) Knoten Vereinfachung des Backup Mit XDM erhält man sofort startbare Backup-Applikation / (Universe 0) XDM Copy / (Universe 1) App 1 App 2 App 3 App 1 App 2 App 3 Fs_1 Fs_2 Fs_3 Fs_1 Fs_2 Fs_3 Fs_1_1 Fs_2_1 Fs_3_1 Fs_1_1 Fs_2_1 Fs_3_1 Fs_1_2 Fs_2_2 Fs_3_2 Fs_1_2 Fs_2_2 Fs_3_2 Fs_1_3 Fs_2_3 Fs_3_3 Fs_1_3 Fs_2_3 Fs_3_3 Compute Nodes Backup Node

5 Restorefreies Recovery durch Daten Replikation Applikations-Spiegelung für Backup und Disaster Recovery online Datenspiegelung Recovery»Vorschau«durch Start der Backup Spiegel-Applikation restorefreies Recovery online reverse Synchronisation SAN VIF LAN User / Client

6 Restorefreies Recovery durch Daten Replikation Applikations-Spiegelung für Backup und Disaster Recovery online Datenspiegelung Recovery»Vorschau«durch Start der Backup Spiegel-Applikation restorefreies Recovery online reverse Synchronisation SAN VIF LAN User / Client

7 Hochgeschwindigkeitsbackup mit serverseitiger Virtualisierung App 1 Fs_1 Fs_1_1 Fs_1_2 Fs_1_3 Compute Node 1 App 2 Fs_2 Fs_2_1 Fs_2_2 Fs_2_3 Compute Node 2 App 3 Fs_3 Incremental Sync (5-20 min/d) Fs_3_1 Fs_3_2 Fs_3_3 Compute Node 3 Enterprise RAID extrem kurzes Backup für Produktiv-Hosts High-Speed Streaming zum Band keine zusätzliche Belastung der Produktiv- Hosts während des Backup to tape startbares Image der Applikationen im Backup Universum App 1 Fs_1 Fs_1_1 Fs_1_2 App 2 Fs_2 Fs_2_1 Fs_2_2 App 3 Fs_3 Fs_3_1 Fs_3_2 Backup Node > 400 MB/s Fs_1_3 Fs_2_3 Fs_3_3

8 Hochgeschwindigkeitsrestore mit serverseitiger Virtualisierung App 1 Fs_1 Fs_1_1 Fs_1_2 App 2 Fs_2 Fs_2_1 Fs_2_2 App 3 Fs_3 Fs_3_1 Fs_3_2 Enterprise RAID Sofortiger Restart kein Restore vom Band notwendig Vorschau möglich Fs_1_3 Fs_2_3 Fs_3_3 High-Speed Streaming vom Band für Restores Compute Node 1 Compute Node 2 Compute Node 3 resync zum Enterprise Storage nachdem die Applikation bereits gestartet ist App 1 Fs_1 Fs_1_1 Fs_1_2 App 2 Fs_2 Fs_2_1 Fs_2_2 App 3 Fs_3 Fs_3_1 Fs_3_2 > 200 MB/s Backup Node Fs_1_3 Fs_2_3 Fs_3_3

9 Integrierte Lösung für Oracle und Networker beispielhafte Realisierung

10 Integrierte Lösung für Oracle und Networker Vergleich mit dauerhaft synchronisierten Spiegeln Produktiv-RZ Enterprise RAID z.b. SRDF Backup-RZ Enterprise RAID Vorteile: sehr schneller Failover möglich, wenn das Produktiv-RZ ausfällt (ohne Recover) universelles Konzept + unabhängig von Hosts Nachteile: bei logischen Fehlern der Datenbank auch sofortige Replikation der Fehler (Restore vom Band notwendig) teurer Enterprise-Storage auch im Backup- RZ dauerhafte (»teure«) Verbindung zwischen den RZs jeder Ausfall des Links kann entfernten Spiegel für Recovery komplett unbrauchbar machen (erst nach Resync gesicherter Stand) SRDF Handling nicht trivial (hinsichtlich Anbindung Host) Enterprise RAID Simple RAID Vorteile: restorefreies Recovery bei logischen Datenbank-Fehlern (roll forward bis zu jedem beliebigen Punkt) günstiger Storage im Backup-RZ keine dauerhafte Verbindung notwendig (nur noch etwa 30 min/d) einfache Hostanbindung integrierte Host-Failover-Fähigkeiten Nachteil: Datenbank-Recover bei Ausfall des Produktiv-RZ notwendig (jedoch ohne Restore vom Band) hostabhängig, individuelle Steuerung und Monitoring

11 Integrierte Lösung für Oracle und Networker restorefreie Recover Funktionalität 0 1 0:00 Stand 0:00 Tag 1 8h 0 2 8:00 8h :00 DB-Fehler 18:00 8h 0 2 0:00 Stand 0:00 Tag 2 DB-Fehler bemerkt um 05:00 roll forward Oracle DB (ohne Restore vom Band) (aufsetzend auf dem 16:00 Uhr Stand mit den Archive-Logs bis 17:59 vorfahren)

12 Integrierte Lösung für Oracle und Networker OSL Storage Cluster Werkzeuge für Integration mit Oracle und Networker nsrdvamsave: erstellt das Backup (Trigger ist das Networker Kommando»savegroup«) dvpresplit /dvpostsplit (Applikation) nsrdvamarchsave: macht Backup der Archiv- Filesysteme wenn nötig (»save«) nsrdvamrestore: macht ein interaktives performantes Point-in-time restore (»recover«pro Tape) nsrdvamarchrestore: Restore der Archiv-Filesysteme wenn nötig (»recover«) roll_forward_oracle: ermöglicht ein flexibles Roll forward von Oracle Datenbanken (unabhängig vom Networker) Modi: komplett oder until <time> Backup-Applikation Networker Restore-Applikation Networker

13 Vorteile / Nachteile Vorteile: Gegenüber dauerhaft synchronisierten Spiegeln (z.b. SRDF) werden Fehler der Produktiv-Applikation nicht automatisch mit repliziert Verbindung zum entfernten Standort muss nicht mehr dauerhaft sein (nur noch ca. 30 min) Durch roll forward z.b. bei Oracle Datenbanken kann das Backup bis zu dem Fehler-Zeitpunkt vorgefahren werden (mit anschliessendem Resync auf das Produktiv-Universum) Für das Backup/Restore Universum können auch günstige RAID-Systeme (eventuell mehrere) ausreichen High Speed Streaming vom/zum Band (keine IO-Belastung der Produktiv-Hosts) zentralisiertes Backup (dedizierter Backup-Knoten) konfigurierbar Einfache Einbindung der Storage Devices in das Betriebssystem (bei Snapshot-Lösungen oder dauerhaft synchronen Spiegeln (SRDF) ist dies nicht gegeben) integrierte Disaster-Recovery-Funktionalität (bei Snapshots nicht gegeben) offen für Kombination mit anderen Technologien Nachteile: mit Snapshot-Lösungen können kurzfristig mehr Backup-Stände gespeichert werden, weil hier für gewisse Zeit geringerer Platzbedarf Hostabhängigkeit

14 Vielen Dank für Ihre Aufmerksamkeit! Dipl.-Ing. Torsten Pfundt