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.

Nach langer Zeit mal wieder ein Blog zu einem Projekt. Diesmal möchte ich aber nicht die Lösung eines Sicherungsproblems ansprechen, sondern das Thema heißt korrekte Lizenzierung.

EMC bietet seit einiger Zeit an, seine NetWorker Lizenzen nach einer sogenannten Volumen-Lizenz berechnen zu lassen. Das heißt EMC berechnet einmal im Jahr die gesicherte "Frontend-Capacity" und daraus ergibt sich der Preis für den jährlichen Support.

Diese Lizenzierung hat einige Vorteile. Sollte eine neue Datenbank oder ein sonstiges Modul zu sichern sein, muss sich der Administrator keine Gedanken machen, ob noch eine entsprechende Lizenz vorhanden ist. Die Sicherung kann sofort eingerichtet und aktiviert werden. Mit der Volumen Lizenz sind alle NetWorker-Module abgedeckt.

Doch nun zum schwierigen Punkt der Angelegenheit, wie berechnet sich denn eigentlich die "Frontend-Capacity"?

• Das Handbuch sagt folgendes (NetWorker Licensing Guide; Chapter 3; Task 2)

Estimate the backup environment's capacity

You can use scripts, NMC reports, or the EMC AMP appliance to estimate the capacity of
the backup environment. Capacity is defined as the total aggregate amount of data for
which the NetWorker software is used to provide data protection.
For most sources, the capacity is measured as the largest aggregate of full backups or
synthetic full backups that are performed for all protected data by the NetWorker software
over the last 60 days. A synthetic full backup is the combination of all full backups and
incremental backups.
NetWorker save set names are used for file system backups and to identify which backups
are from the same source. However, databases and applications often have their save set
names defined outside of the NetWorker software. This makes it difficult to accurately
distinguish between the same and different sources. For this reason, the capacity of
databases and applications are estimated by the largest amount of data backed up in a
24-hour (noon to noon) period.

• Was heißt das nun für Ihre Kapazitätsberechnung?
• Warum gibt EMC hier unterschiedliche Möglichkeiten für die Berechnung an?

Hier die Antwort:

• EMC hat kein Verfahren, das diese Größe eindeutig ermitteln kann!

EMC zählt einfach nur die Level-Full und Level-'manual' Backups für eindeutige SaveSet Namen.

• Sollten sie nur Filesystem, NDMP und NMM Backups in ihrer Datensicherung haben, ist das so weit kein Problem. In dem Falle dürfte die Auswertung ihrer Kapazität passen.
• Haben Sie aber einige Oracle oder SAP-Datenbanken, so sieht das ganze schon anders aus. Hier verzählt sich EMC bei der Berechnung der Log- und DB-Backups bei NMDA und NMSAP Sicherungen. Das kann dann für eine einzelne Datenbankmaschine schon mal das 10-fache mehr an  Frontend-Capacity ergeben. Da die Berechnung aber nur für den gesamten Server durchgeführt wird, erkennt man dieses Problem nicht sofort. Also bleibt nur mit eigenen Skripten das Sicherungsvolumen zu überprüfen bzw. zu berechnen.

Diese Aufgabe hatte ich von einem Kunden erhalten. Das Ganze stellte sich allerdings als wesentlich schwieriger heraus, als zuerst angenommen. Denn Die Oracle-Module generieren, wie ja schon oben gesagt, für jede Sicherung andere Namen. Man braucht also eine Menge an Zusatzinformationen wie Gruppennamen, Pools usw., die herangezogen werden können, um die Zuordnung der Sicherungen  zu einer definierten Datenbank zu ermöglichen. Aber auch das funktioniert nur dann, wenn auch die RMAN Skripte die SaveSet-Namen mit der Oracle-SID versehen.

Bei meinem Kunden hat sich der Aufwand auf alle Fälle gelohnt!

Die Frontend-Capacity Betrug nach meinen Berechnungen 20 - 25 % weniger als die von EMC gemessene Größe.

Die Berechnung der Frontend-Capacity wird beim Kunden nun jeweils am 1'ten eines Monats per Cron erzeugt. Das Ergebnis ist ein PDF, dass das Gesamt-Volumen eines NetWorker-Servers und die Größe für jede einzelne Maschine enthält.

EMC hat dieses Skript inzwischen als offizielles Berechnungsverfahren akzeptiert und erhält für die Berechnung der Lizenzen die so erzeugten PDFs.

Fazit:

Die Volume Lizenz ist für einige Umgebungen mit Sicherheit die richtige Wahl der Lizenzierung, aber die Berechnungsmethode von EMC hat leider ihre Tücken.

Sollten Sie einen hohen Anteil an Oracle-Datenbanksicherungen in Ihrem Backup-Volumen haben, so lohnt es sich sehr wahrscheinlich eine eigene Berechnung des gesicherten Volumens zu Erstellen.

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

Nach langer Zeit mal wieder ein Block zu einer Scripting-Lösung, die bisher weder mit einer NetWorker-internen noch mit einer mir bekannten Third-Party Lösung erledigt werden kann.

Ein schon häufiger in Kursen gefragtes Thema war ein Modul zur Berechnung von Sicherungsmengen für eine bestimmte Auswahl von Sicherungen, z.B. die Datenmenge aller Sicherungen der Gruppe Oracle und deren zugehörigen LogSicherungen oder aller Sicherungen der Abteilung XY.

Kurz und gut es ging um eine NetWorker Backup Statistik Erstellung für definierbare Einheiten.

Beispiel:

Entstanden ist eine Scriptlösung, die SaveSets auf Basis einer Python Definition nach den unten folgenden Kriterien gruppieren und aufsummieren kann und als Ausgabe eine CSV Datei erstellt. Die Auswahl des Statistikzeitraums ist ebenfalls frei wählbar. Es stehen hierbei Zeiträume der Art 'n' Tage, Wochen oder Monate vor dem Startzeitpunkt oder die Definition eines genauen Zeitraums von "Datum Uhrzeit" bis "Datum Uhrzeit" zur Verfügung. P { margin-bottom: 0.21cm; } Die Optionen 'Tag', 'Woche' und 'Monat' sind für zyklische Abfragen zum Beispiel mit Hilfe eines crontab Eintrags gedacht. Die Optionen 'Start-' und 'Endzeit' bieten die Möglichkeit von Hand eine Statistik für einen bestimmten Zeitraum zu Erzeugen.

Die möglichen Kriterien für die Auswahl der zu zählenden Sicherungen einer Rubrik sind:

• Der NetWorker Gruppen-Name
• Der Client-Name
• Der SaveSet Name
• Der Level der Sicherung
• Die SaveSet Flags (z.B. Auswahl von NDMP Sicherungen)

Die obigen Kriterien können bei der Zusammenstellung einer Berechnungsgruppe beliebig kombiniert werden.

Ist dieses Tool auch für Sie von Interesse?