Disaster Recovery

Hier wird von einer komplett redundanten Auslegung aller beteiligten RZ-Komponenten ausgegangen. Insbesondere bei großen Unternehmen mit 24/7 Verfügbarkeitsanforderung wird dieses Ziel mit dem Aufbau eines räumlich getrennten zweiten Rechenzentrums erreicht, das bei Ausfall des primären (z.B. bei einem Stromausfall) die wichtigen Anwendungen hostet. OSL hat es sich zur Aufgabe gemacht auch Disaster Recovery Probleme effizient und einfach zu lösen.

Alle großen Speicherhersteller bieten in verschiedenen Formen auch DR-Lösungen an. Dabei wird meistens von einem großen Produktiv-RAID-System ausgegangen, das wenigstens in Teilen permanent an einen anderen Standort (Notfall-RZ) gespiegelt wird. Sollte nun das Produktiv-RAID-System ausfallen, soll das Notfall-RZ übernehmen. Prinzipiell kann damit schon ein Großteil der gewünschten Ausfallsicherheit abgebildet werden. Leider verkompliziert es die Handhabung der gesamten RZ-Umgebung erheblich, insbesondere durch eine Zuordnung Anwendung ↔ LUN des RAID-Systems, die nicht immer einfach herzustellen ist. Gleiche Probleme kennt man schon von Backup- bzw. Restore-Konzepten, wo im Ernstfall leider viel zu oft kein schneller Wiederanlauf möglich ist.
Als besonders kritisch stellen sich Datenbank-Systeme dar, da neben der reinen Datenbank auch Logarchive, Onlinelogs und Controlfiles (z.B. bei Oracle) bis zum Ausfallzeitpunkt vorhanden sein müssen, damit ein Wiederanlauf ohne Transaktionsverlust möglich wird. Durch die permanente Spiegelung hat man auch das zusätzliche Problem der sofortigen Replikation von Datenbankfehlern auf das entfernte Speichersystem. Die gespiegelten Daten sind mit einem Schlag unbrauchbar.


Ein ganzheitliches Konzept für große Datenbanken/SAP-Systeme mit OSL Storage Cluster
Der OSL Storage Cluster bietet insbesondere für große Datenbanken/SAP-Systeme eine Lösung, die Disaster Recovery, Backup-to-Disk, Backup-to-Tape und Instant Recovery vereinigt. Eine ausgewogene Kombination synchroner und asynchroner Spiegel gewährleistet maximalen Schutz vor typischen Ausfall- und Fehlersituationen. Unsere Lösung zeichnet sich aus durch:

  • "schnellen Wiederanlauf für Datenbanken" - vor allem für große Datenbanken oft ein Problem
  • beeindruckende Performance und
  • geringe Hardwareanforderungen und damit auch deutliche Kostenreduzierungen.

Der ganz große Vorteil gegenüber allen anderen am Markt befindlichen Lösungen ist die Applikationsorientierung. Man definiert im OSL Storage Cluster Anwendungen mit allen notwendigen Ressourcen (virtuelle Interfaces, Filesysteme, Start-, Stop- und Break-Prozeduren, usw.) und erhält damit für jede Anwendung ein administratives Objekt, das mit einfachen Befehlen auf allen Cluster-Knoten gestartet und auch verwaltet werden kann.


Applikationsspiegel zu Disaster Recovery Zwecken als Instant Recovery
Zu dieser bestehenden Anwendung können nun wiederum mit einem einfachen Befehl Spiegel-Applikationen (XDM) erstellt werden. Durch das Universen-Konzept von OSL haben Produktiv- und Backup-Applikationen den gleichen Namen, sie unterscheiden sich lediglich durch das Universum. So behält man auch bei vielen Anwendungen den Überblick. Durch eine sinnvolle Verteilung der Universen kann man neben dauerhaft synchronisierten Spiegelapplikationen auch Backups auf Disk zu definierten Zeitpunkten verwirklichen. Die Backup-Spiegel können jederzeit mit der Produktion synchronisiert sowie atomar und damit (zeit-)konsistent abgetrennt werden. Man erhält so immer ein sofort startbares Image der Gesamtapplikation auf Disk, auf das im Disasterfall zurückgegriffen werden kann. Bei der Verwendung von Datenbanken (z.B. Oracle) wird zudem der Backup-Modus aktiviert, so dass ein Online-Backup verfügbar ist. In Verbindung mit den permanenten Spiegeln (Redologs) hat man die Möglichkeit, das Backup (auch automatisiert) auf jeden gewünschten Stand vorzufahren, ohne dass ein Tape involviert ist. Kurz gesagt: Instant Recovery.

Das Backup-Konzept kann zudem mit einer Tape-Anschlusslösung (z.B. Networker) erweitert werden. Das Backup wird dann zunächst auf Disk erstellt, das dann vom zentralen Backup-Server auf Tape geschrieben wird. Dieses Vorgehen zeichnet sich durch folgende Vorteile aus:

  • Das Tape-Backup belastet die Produktion überhaupt nicht, da lediglich die Backup-Applikation auf Band geschrieben wird.
  • Es wird nur ein Backup-Server pro Cluster verwendet und somit die Lizenzen für die Backup-Clients eingespart.
  • Der Stream auf Band läuft über dedizierte SAN-Verbindungen mit deutlich gesteigerter Performance.

Wenn nun also das Produktiv-RZ ausfällt, kann mit Hilfe der Spiegel-Applikationen die Produktion im Notfall-RZ wieder aufgenommen werden.