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?

Eine der Stärken der NetWorker Backup Lösung besteht schon immer darin, dass der NetWorker-Server sich schnell und einfach auf einem anderen Rechner starten läßt. Diese Eigenschaft ermöglicht es auch den NetWorker-Server von einer Platform auf eine andere zu transferieren. Doch das ist ein anderes Thema. Eine weitere Einsatzmöglichkeit dieser Eigenschaft besteht darin, einen NetWorker-Server über 2 Standorte oder Brandabschnitte als Quasi-Cluster einzurichten. Ein Quasi-Cluster schaltet nicht automatisch. Der Start des NetWorker-Servers muss von einem Administrator auf der vorbereiteten Maschine von Hand gestartet werden.

Die Vorteile des Quasi-Cluster:

• es wird keine NetWorker Power-Edition Lizenz benötigt.
• es wird keine pflegeaufwendige Cluster Konfiguration benötigt.
• der NetWorker-Server ist in einem Ausfallszenario in einer übeschaubaren Zeit wieder aktiv.

Nachteile des Quasi-Cluster:

• der NetWorker-Server wird nicht automatisch im anderen Rechenzentrum gestartet.
• die NetWorker Lizenzen sind für den Quais-Cluster Partner nicht lizenziert und somit nur wenige Tage gültig.

Die beschriebenen Umgebungen laufen bei unseren Kunden noch in der NetWorker Version 7.x. So langsam steht jedoch der Update auf die NetWorker Version 8 bevor (der Support für NetWorker 7.5 und 7.6 läuft schließlich Ende des Jahres aus). Also habe ich mich mal näher mit diesem Thema befasst. Zunächst stellte sich das Thema etwas schwieriger dar als gedacht. Es stellte sich nämlich heraus, dass die neuen Features (z.B. der neue StorageNode Daemon, nsrsnmd) den Start des Servers auf einem anderen Rechner erschweren. Nach einigem Untersuchungen konnte ich die Probleme jedoch analysieren und dem Aufbau eine NetWorker Quasi-Clusters mit NetWorker 8 steht nun nichts mehr im Wege. Hier eine kurze Beschreibung der Randbedingungen und Voraussetzungen:

Voraussetzungen / Zusammenfassung der nötigen Umgebung:

1. NetWorker Server und der Quasi-Cluster-Partner Rechner müssen beide auf einem LINUX/UNIX System installiert sein, auf beiden Maschine sollte möglichst der gleiche OS und NetWorker Stand installiert sein.
2. Auf beiden Maschinen muss der NetWorker-Server installiert sein. Auf dem Partner Rechner darf der automatische Start des NetWorker-Servers aber nicht über den Unix-Start-Mechanismus erfolgen. Es darf zwar ein NetWorker-Client gestartet werden, und es darf auch eine StorageNode auf diesem Rechner laufen.
3. Die NetWorker Datenbanken und Ressourcen sollten auf einem über beide Rechenzentren geclusterten Storage-System gehostet werden. Der Storage sollte am einfachsten mit Hilfe des NFS-Protokolls an beiden Quasi-Cluster-Maschinen gemountet werden.
4. Die Datensicherungen sollten auf den 2'ten Standort dupliziert (gecloned oder z.B. durch eine VTL gespiegelt ) werden.
5. Die Datensicherungsziele (Advanced File Devices, Data-Domain Boost Devices und wenn verwendet auch Bandgeräte) müssen an beiden Standorten erreichbar und mount fähig sein (zumindest das jeweilige Duplikat). 
6. Die NetWorker-Client Konfigurationen sollten in der Servers-Datei beide Maschinen-Namen enthalten.

Notwendige Anpassungen vor dem Start:

Die folgenden Aussagen gehen davon aus, dass der Name der NetWorker-Server-Maschine nicht auf die neue Maschine übernommen werden kann. Sollte dies möglich sein, so hat man nicht weiteres zu tun, als die NetWorker-Datenbasen unter /nsr zu mounten und den NetWorker-Server zu starten! Ist dies aber nicht möglich oder nicht gewollt, so müssen beim Start des NetWorker-Servers im entfernten Rechenzentrum, folgende Besonderheiten der NetWorker Version 8.0 berücksichtigt werden.

1. Die NetWorker-Client-Datenbasis darf nicht übernommen werden. Das Problem besteht darin, dass in der NSRLA Ressource des Servers, sowie des Clients, der Name der Maschine im Client-Zertifikat enthalten ist. Befindet sich in dieser Ressource der Name des original NetWorker-Servers, so läßt sich der StorageNode-Management-Daemon (nsrsnmd) nicht mehr starten. Man muss folglich vor dem Start des Servers oder besser bereits beim Aufbau der Server-Umgebung darauf achten, dass die Client-Ressource-DB (nsrladb) pro Maschine separat gehalten wird.
2. In der NetWorker-Server-Ressource (nsrdb) existiert für den original Rechnernamen eine StorageNode-Ressource. Diese kann nach dem Start des Servers auf dem Quasi-Cluster nicht gestartet werden und sollte dementsprechend vor dem Start deaktiviert (disabled) werden.

Fazit:

Auch mit der NetWorker Version 8 kann man einen NetWorker-Quasi-Cluster vorbereiten. Das Starten des NetWorker-Servers in dem 2'ten Standort bedarf zwar jetzt einiger Vorbereitungen, aber diese lassen sich durch eine geschickte Installation und durch ein angepasstes Start-Script auch automatiseren.

Wenn Sie mehr über einen NetWorker-Quasi-Cluster erfahren möchten, so besuchen Sie doch unseren NetWorker Admin III Workshop, oder Fragen Sie uns direkt.