Oracle-NMDA Backups in großen NetWorker Umgebungen

Die Konfiguration einer NetWorker Oracle-Backup Umgebung hat sich durch die Einführung des NetWorker Moduls für Database Applications (NMDA) und dem zugehörigen NMC-Wizzard, auf den ersten Blick stark vereinfacht. Betrachtet man die Konfiguration aber in Umgebungen mit einer hohen zweistelligen, oder gar dreistelligen Zahl von Datenbanken, so macht sowohl die Migration bestehender Konfigurationen, als auch die Pflege der Oracle-RMAN-Skripte mit dieser Art der Datenbanksicherung-Konfiguration wenig Spass. Der Pflegeaufwand und der potentielle Wildwuchs der verwendeten RMAN-Skripte und NetWorker Konfigurationen wuchert doch sehr schnell aus.

Genau vor diesem Problem Stand ein Kunde bei der anstehenden Umstellung der Oracle-Datenbanksicherungen vom ehemaligen NMO Modul auf das aktuelle NMDA Modul. Die Anzahl der zu sichernden Datenbanken lag im dreistelligen Bereich. Es sollte also eine Möglichkeit gefunden werden,

• die Umstellung des Datenbankmoduls möglichst einfach zu gestalten.
• sowohl den Update-Vorgang des  NetWorker-Clients als auch des Datenbankmoduls zu automatisieren.
• die NetWorker Ressourcen automatisch vom alten Modul auf das neue Modul anzupassen.
• den anschließenden Pflegeaufwand der Datenbanksicherungskonfigurationen und der RMAN-Skripte zu minimieren.

Klingt auf den ersten Blick ziemlich unmöglich. Doch mit der richtigen Systemumgebung und einigen geschickten Randbedingungen war eine Idee ziemlich schnell gefunden und die Implementierung der Lösung war dann sogar relativ einfach.

Hier eine kurze Beschreibung der Randbedingungen und der implementierten Lösung:

Systemumgebung:

1. Alle Datenbanken befinden sich auf LINUX/UNIX Systemen
2. Die zu installierenden Software-Pakete befinden sich auf einem für alle Maschinen zugänglichen NFS-Share.
3. Es existiert eine sichere (gespiegelte) NFS-Umgebung auf der ein Share angelegt wird, der auf allen Datenbankmaschinen gemountet werden kann.

Randbedingungen:

1. Die Oracle RMAN-Skripte lassen sich durch die Verwendung einiger Oracle-Parameter für alle Datenbanken einer Oracle-Version verwenden.
2. Die NetWorker Ressource-Namen der Gruppen-, Schedule und sonstigen Ressourcen müssen standardisiert sein.
3. Der Save-Set des Clients definiert die Sicherungs-Parameter (Oracle-SID, RMAN-Sicherungstyp (Archive, Full, Level, ...))

Implementierte Lösung

Shell und Python-Skripte

Die Lösung des Problems bestand neben dem Aufbau einer geschickten Datenablage, in der Implementierung folgender Skripte:

1. Migrationsskript, das auf einer Oracle-DB-Maschine
   
   • die bestehende NetWorker-Umgebung analysiert
   • die "alten" NetWorker Pakete deinstalliert 
   • die "neuen" definierten NetWorker Pakete installiert
   • die alten NetWorker Ressourcen deaktiviert
   • neue NetWorker Ressourcen erzeugt
   • die Oracle-Backup-Library verlinkt
   • das Backup-Command verlinkt
   • den NFS-Mount des NFS-Ablageverzeichnisses in die /etc/fstab integriert
2. NetWorker Backup Command, das
   • anhand des übergebenen SaveSets, das definierte RMAN-Skript mit den benötigten Parametern aufruft.
   • das Rollieren der "alten" Backup-Protokolle durchführt

NFS-Ablage

Die gemeinsam genutzte NFS-Freigabe enthält folgende Datenstruktur:

1. Ein eigenes Verzeichnis für jede Datenbank mit dem Namen der Oracle-SID,  in dem neben einer Konfigurationsdatei  die Protokolle der Sicherungen und Wiederherstellungen abgelegt werden.
2. Ein Binarie-Verzeichnis, in dem die gemeinsam genutzten RMAN-Skripte und das implementierte NetWorker-Backup-Kommando liegen.

Fazit

Welche Vorteile bringt die implementierte Lösung?

• Leichtere Wartung der RMAN-Skripte. Nur noch wenige zentral abgelegte Skripte werden benötigt.
• Leichtere Fehlersuche, da bei Problemen die Protokolle und Konfigurationen von funktionierenden und fehlerhaften Sicherungen auf jeder Maschine direkt verglichen werden können. Ein mühsames Anmelden des NetWorker Administrators auf der jeweiligen Datenbankmaschine ist nicht mehr notwendig.
• Übersichtlichere NetWorker Konfiguration. In der Client-Ressource definiert alleine der SaveSet die Art der Oracle-Sicherung.
• Einfache und fehlerfreie Migration der alten NetWorker-Client Umgebungen in die neue NMDA-Umgebung.

Sollten sie Fragen zu diesem Blog haben oder vor ähnlichen Herausforderungen stehen, so scheuen sie sich bitte nicht sich per E-Mail an info@schaefer-tobies.de zu wenden.

Die ersten beiden Migrationen einer FlexFrame 4 SAP (FF4SAP) Sicherungsumgebung konnten von uns noch vor Weihnachten erfolgreich umgesetzt werden.

Hintergrund:

Kunden, die bisher eine auf Fujitsu-NetWorker und der Fujitsu-eigenen Sicherungslösung NSRORA-NDMP basierte NetApp-Snapshot-Sicherung einsetzen, haben seit der Abkündigung der Fujitsu-NetWorker OEM-Version das Problem, dass der Support für diese elegante und hochperformante Backup-Lösung abläuft, bzw. abgelaufen ist.

Die auf NetApp-Snapshots basierende Sicherungslösung ermöglichte es, Oracle-Datenbanken in wenigen Minuten zu sichern und im allgemeinen auch in wenigen Minuten wiederherzustellen! Wenn benötigt können NDMP basierte Band-Sicherungen dieser Snapshots erstellt werden. Des weiteren sorgte NSRORA-NDMP mit Hilfe des Dämonen AMON für die Überwachung, die Sicherung und das Löschen der archivierten Oracle-Logs. Ein besonderes Highlight von NSRORA-NDMP bestand in der Möglichkeit einer vollautomatisierten Wiederherstellung einer Datenbank.

All diese lieb gewonnen Vorteile werden durch unsere Sicherungslösung SB-INT-O ebenfalls erfüllt. Zusätzlich erhält der Administrator jedoch noch weitere durchaus erwähnenswerte Vorteile. Hier eine stichwortartige Auflistung:

• Integration der NetApp eigenen SnapVault Sicherungstechnik. Hierdurch wird eine weitere Sicherungseinheit ermöglicht, die folgende Vorteile liefert.

  • Backup To Disk To Tape. Nur die seit dem letzten Backup veränderten Blöcke werden vom primären Storage-System auf ein sekundäres (Nearstore) Storage-System kopiert. Erst dort wird bei Bedarf ein vollständiges (Tape-)Backup durchgeführt. Dies entlastet das primäre System vom NDMP-Backup. 

  • Das SnapVault-Backup kann auf dem sekundären System,  auf preiswerterem Platten, länger für Wiederherstellungszwecke vorgehalten werden. 

  • Auf dem sekundären Storage kann auf Basis der Backup-Snapshots und der NetApp-FlexClone Technik schnell und automatisiert eine Test- oder Recover-Datenbank erstellt werden. 

  • Schnelles Wiederherstellen einer Datenbank auf Basis der SnapVault Snapshots. Auch die auf dem sekundären Storage vorliegenden Snapshots werden von dem vollautomatisierten Datenbank-Recover für Wiederherstellungen berücksichtigt. Hierdurch wird ein Recover der nicht mehr auf die Snapshots des primären Storage-Systems zurückgreifen kann wesentlich beschleunigt. Denn statt die ganze Datenbank von Band wieder einspielen zu müssen, genügt es die seit dem gewünschten Zeitpunkt veränderten Blöcke vom sekundären auf den primären Storage zu übertragen. Auch diese Art der Wiederherstellung wird natürlich vollautomatisiert von SB-Int-O durchgeführt.

• Schnelleres Recover der archivierten Oracle-Logs.
  Das Backup der archivierten Logs wird über einen sekundären Speicherbereich organisiert. Auf diesem, im Normalfall auf günstigeren Nearstore-Platten basiertem Storage, können die Logs länger für Recovery-Zwecke vorgehalten werden. Sie stehen somit sofort für die Wiederherstellung der Datenbank zur Verfügung. Der voll-automatisierte Wiederherstellungsvorgang von SB-INT-O mountet diesen Bereich wenn nötig in den Archivelog-Bereich der Datenbank. Man benötigt somit in den meisten Fällen weder ein NetWorker-Recover noch einen Kopiervorgang für die Bereitstellung der notwendigen Logs.

• Erhöhte Sicherheitsunterstützung!
  Musste für NSRORA-NDMP jede Datenbankmaschine ssh-Rechte als Benutzer "root" erhalten, genügt es für SB-Int-O definierte NetApp-Benutzer einzurichten, die lediglich die benötigten Kommandos mittels NetApp-API verwenden können. Diese Art der Komunikation ist somit wesentlich sicherer und zudem weniger fehleranfällig.

• Unterstützung von DMZ und V-Filer Umgebungen.
  In einer auf V-Filern basierten DMZ-Umgebung wird keine NDMP-Sicherung unterstützt. SB-Int-O ermöglicht es auch in dieser Umgebung über den Einsatz von SnapVault und einen Nearstore-Filer eine Bandsicherung zu erstellen.

• WWW basiertes zusätzliches Überwachungs- und Konfigurations-Interface.
  Für viele Kunden von SB-Int das Highlight der Lösung! Ermöglicht es doch

  • den Datenbank-Administratoren:

    • jederzeit einen schnellen Blick auf alle zur Verfügung stehenden Sicherungsstände

    • die Möglichkeit, schnell mal eine Snapshot-Sicherung ihrer Datenbank zu starten

    • zu kontrollieren, welche archivierten Logs der jeweiligen Datenbank noch zur Verfügung stehen.

    und das alles ohne das diese hierfür NetWorker Rechte benötigen.

  • den NetWorker Administratoren:

    • einen schnellen Überblick über den Erfolg oder Misserfolg aller Datenbanksicherungen.

    • den Zugriff auf alle SB-Int Konfigurationen.

    • die Überwachung aller Snapshots auf den primären und sekundären Storage-Systemen.

    • den leichten Zugriff auf alle Sicherungsprotokolle.

  Das WWW-GUI besitzt eine eigene Benutzer Verwaltung, in der jedem Benutzer eigene Rechte bis hinunter zur Datebank-Ebene zugewiesen werden können.

  Wie Sie lesen konnten gibt es für die "alte" Sicherungslösung NSRORA-NDMP nicht nur einen adäquaten Ersatz, sondern Sie erhalten mit unserer Backup-Lösung SB-Int-O eine im allgemeinen nochmals schnellere Recover-Lösung, sowie weitere vielfältige Möglichkeiten.

  Für Fragen oder einen persönlichen Vorführungstermin wenden Sie sich bitte an

  Uwe W. Schäfer

Bei einem unserer Kunden war der Wartungsvertrag für die NetApp VTL abgelaufen. Eine Verlängerung wäre unverhältnismäßig teuer gewesen. Außerdem war die Kapazität des Systems auch schon an seine Grenzen gestoßen. Da der Großteil der Daten des Kunden auf NetApp Primary Systemen lag oder darauf umgezogen werden sollte, viel die Entscheidung für eine Ablösung auf eine Kombination von 2 NetApp Nearstore Systemen und Advanced File Devices mit einer Bandsicherung für Langzeitsicherungen.

Auf die beiden Nearstore Systeme, die sich an 2 unterschiedlichen Standorten befinden, werden die Sicherungen der Oracle und VMware ESX Backups, sowie die auf den NetApp befindlichen Nutzerdaten mittels des NetApp Produktes SnapVault auf die erste NetApp gesichert. Diese Backup Volumes werden zyklisch mit dem Produkt SnapMirror auf die 2'te Nearstore in einen entfernten Standort gespiegelt. Da der Kunde schon seit einiger Zeit unsere Backup-Lösungen SBint-O und SBint-VM einsetzt, konnte die Sicherung der Oracle Datenbanken und der VMware-ESX-Datastores weiterhin mit NetWorker gestartet und überwacht werden. Die anfallenden Oracle-Archivelog Dateien werden mit SBint-O vom Primary Storage auf die erste Nearstore verdrängt. Jetzt fehlte nur noch eine entsprechende Integration der auf NetApp gehosteten Benutzerdaten. Hierfür gab es jedoch auch bereits eine Lösung unserer SBint-Backup-Tools. Denn auch hierfür kann man mit Hilfe eines NetWorker-Clients und einer zugehörigen NetWorker-Gruppe die Sicherung eines NetApp Volumes von einem Storage-System zum zweiten starten und überwachen. Selbstverständlich werden auch diese Sicherungen in unserer SBint-WWW-Oberfläche visualisiert (siehe auch hier).

Was jetzt noch fehlte, waren eine integrierte Sicherungslösung ganzer virtueller Filer-Umgebungen, sowie eine einfache Möglichkeit die benötigten Volumes und SnapVault- bzw. SnapMirror-Beziehungen automatisiert anzulegen. Jeder virtuelle Filer besitzt mehrere NetApp-Volumes. Diese sollten auf den sekundären Systemen alle die gleiche Aufbewahrungsfristen erhalten. Hierfür wurde unsere SBint-Backup-Lösung kurzerhand um eine entsprechende Funktion erweitert. Ein neuer Parameter in der Konfigurationsdatei definiert welche primären NetApp-Volumes auf einem gemeinsamen sekundären Ziel-Volume gesichert werden sollen. Das Sicherungskommando startet entsprechend bei einer durch NetWorker getriggerten Sicherung den SnapVault-Abgleich aller definierten Volumes auf ein gemeinsames Ziel-Volume. Nach der erfolgreichen Übertragung aller Volumes wird auf dem Nearstore-Volume ein gemeinsamer Snapshot erzeugt, der von unserer Backup-Integration nach der definierten Retentionzeit auch wieder entfernt wird. Jetzt fehlte nur noch ein komfortables Tool, dass die auf den Nearstores benötigten Volumes automatisiert anlegt und die für die Sicherung benötigten Snapshot-Beziehungen konfiguriert. Entstanden ist ein kleines Programm, dass im nächsten Blog beschrieben wird.

Viel zu lange her, dass ich hier etwas veröffentlicht habe.
Das hat aber nichts damit zu tun, dass es nichts zu berichten gäbe, sondern dass es einfach zu viel zu tun gibt und ich daher keine Zeit gefunden habe, dies hier zu berichten. Nun sitze ich am Flughafen und warte auf den wegen Nebel verschobenen Flug zur NetApp Insight und habe endlich mal Zeit und Luft diese Zeilen zu schreiben ;-)

Wo fangen wir an?
Unser Snapshot-Backup Entwicklung für Oracle und VMware ist an vielen Ecken vorangetrieben worden.

Folgende Erweiterungen wurden für die Oracle-Sicherung auf NetApp implementiert und sind bereits beim Kunden im Einsatz:

• vollautomatische Recover Funktionalität
  • Recover Until Time
  • Vollständiges Recover (Crash Recover)

Durch diese Erweiterung können NSR-ORA-NDMP Kunden auf unser Produkt wechseln ohne Funktionalität zu verlieren. Im Gegenteil: Sie erhalten zusätzliche Funktionalität (SnapVault Support).

Folgende Erweiterungen wurden für die VMware-Sicherungen auf NetApp implemetiert:

• Parallelisierung einiger Funktionen: Dadurch wurde die Sicherungsdauer zum Teil auf ein Viertel der Zeit reduziert!
• Unterstützung von orignären NetApp Snapshots für das Recovery von Einzeldateien. Hierdurch können mehrere Sicherungsstände pro Tag durch den normale NetApp Snapshot Scheduler generiert werden. Diese Snapshot Sicherungen sind zwar nur Crash-Consistent, können aber für das Recovery einzelner Dateien verwendet werden.

Migrationsunterstützung :

Unterstützung von mehreren gleichzeitigen SnapVault Beziehungen.
Sowohl die Oracle-  als auch die VMware- Lösung erkennen und "updaten" jetzt auch mehrere gleichzeitige SnapVault Beziehungen. Hierdurch kann z.B. der secondary Storage auf einem neuen System angelegt werden und sobald beide Nearstore Systeme den gleichen Snapshot-Stand haben (beide haben Snapshots über "n" Wochen), kann die "alte" Nearstore Verbindung aufgelöst werden.

Volume Backup:

Unterstützung von Volume Sicherungen über unsere Snapshot Integration.
Dieses Feature unsere Snapshot-Backup Integration ermöglicht z.B. die Sicherung eines Multistore-Filers (VFiler) auf eine gemeinsames Nearstore Volume zu sichern und dieses für Langzeitsicherungen anschließend auf Band-Medien zu sichern.