Wann merkt man, dass ein Datenbereich nicht gesichert wird?
Natürlich erst dann, wenn man Daten aus dem betreffenden Bereich wiederherstellen möchte!

Genau dieses war mal wieder beim Kunden vorgekommen und damit dieses nicht noch mal passiert, sollte eine Lösung entwickelt werden, die einmal täglich überprüft, ob alle zurzeit existierenden Volumes gesichert werden.

Die Umgebung:

Der Kunde sichert mehrere NetApp Filer mit dem Backup Produkte NetWorker und dem NDMP Protokoll auf externe Bandmedien.

Auf den Filern werden sowohl Oracle-Datenbanken, MS-Exchange-Daten, VMware-Datastores als auch Benutzer-Daten gespeichert. Die Oracle-, Exchange,- wie auch die VMware-Daten werden über eigene Module gesichert; so kann folglich nicht einfach der NetWorker-SaveSet "All" verwendt werden, um alle NetApp-Volumes zu sichern.

Die Lösung:

Mit unserer eigenen NetApp-ZAPI-Python-Schnittstelle werden zunächst vom jeweiligen Filer alle Volumes ermittelt.

Dann werden über unsere Python-NetWorker-nsradmin-Schnittstelle alle "Save Sets" für den betreffenden Filer ausgelesen.

Volumes, die nicht im NetWorker definiert sind, werden anschließend noch gegen eine definierbare White-Liste verglichen. Die Oracle- und VMware-Volumes will man ja nicht jeden Morgen vor Augen haben,
da man sonst ja wieder nicht sieht, ob ein neues Volume hinzugekommen ist.

Über die Volumes, die weder in der Sicherung noch in der White-Liste enthalten sind, werden die Administratoren mittels E-Mail informiert.

Durch unsere bestehenden NetApp und NetWorker Frameworks konnte somit eine einfache und praktikable Lösung in kurzer Zeit entwickelt werden, die dem Kunden eine Menge Ärger und Erklärungsnöte ersparen kann.

Leider ist die NetApp VTL ja schon Geschichte :-(, aber dennoch durfte ich eine der wohl letzten ausgelieferten Geräte in die beim Kunden bestehende NetWorker Kunden Umgebung integrieren.

Da es keine Workshops zur NetApp VTL bei unserem Partner qSkills mehr geben wird, hatte der Kunde eine In-House-Schulung zum Thema gebucht.

Aus dieser Not wurde eine Tugend! Der Workshop konnte direkt in der aktiven Umgebung stattfinden und somit konnten die Auswirkungen der verschiedenen Szenarien (Cache Betrieb mit Direct Tape Creation, oder reine "Backup-To-Tape" Lösung) direkt sichtbar gemacht werden. Am Ende des 3 tägigen Workshops erhielt der Kunde somit eine fertige Lösung.

Implementiert wurde die Cache Version. Hiefür wurde im NetWorker ein Python-Script in die NetWorker Notification-Ressource integriert, das bei Bedarf Bänder automatisch aus der angeschlossenen Tape-Library importiert. Ein Cron-Job sorgt für die Auslagerung voller Bänder. Diese Auslagerung findet täglich statt und verdrängt dabei die Bänder aus der NetWorker Jukebox in den Shadow Bereich der VTL. Wird ein virtuelles Band für die Wiederherstellung benötigt, so generiert NetWorker automatisch eine Notification mit der Anforderung des benötigten Bandes. Das oben erwähnte Skript bringt das benötigte Medium dann umgehend zurück in die NetWorker Jukebox. Dabei ist es egal, ob das virtuelle Band noch in dem Shadow-Pool vorhanden ist, oder dieses aus der physiklaischen Jukebox eingelagert werden muss.

Die Lösung läuft rund und performant, Schade das es wohl keine weitere Implementation in der Art geben wird ;-(

Diese Woche war schwitzen angesagt (nicht nur der Temperaturen wegen ;-)), sondern auch das Projekt hatte es mal wieder in sich.

Es sollte ein NetWorker Active-Active Cluster bestehend aus einer NetWorker Storage-Node und einem NetWorker Server aufgebaut werden. Die Basis bilden:

• zwei Solaris-10 Maschinen, auf denen ein Veritas-Cluster zum Einsatz kommt
• ein über NFS angebundener Storage auf einem NetApp Metro-Cluster
• die Networker Version 7.5 von Fujitsu
• SAN Laufwerke aus einem ACSLS Roboter
• die SAN Laufwerkssharing Lösung SRS zum Verwalten der Laufwerksvergabe
• eine VTL-700 für die Sicherung der langsamen und asynchronen Daten

Die Lösung erlaubt eine automatische (von der Cluster-Software überwachte) Übernahme der NetWorker-Server Funktionalität an den StorageNode mit Übernahme aller Laufwerke und umgekehrt. Dies bedingt natürlich gleiche Laufwerksbezeichnungen aller verwendeten Laufwerke auf den beiden Cluster-Maschinen und ein durchdachtes Design des Storage und der Laufwerksaufteilung.

Das Schwitzen hat sich aber gelohnt ;-) das Cluster ist fertig und alle Kundenanforderungen konnten erfüllt werden.

Es gibt sie immer noch - die NetWorker Server mit der Version 7.2.

Eines dieser Arbeitstiere (die noch bestehenden V7.2 Server sind meist in größeren Umgebungen zu finden) durfte ich vor 2 Wochen auf eine neue Umgebung hieven. Hierbei wurde aber nicht nur die NetWorker Version auf den neuesten Stand gebracht, sondern auch die Hardware des NetWorker Servers und dessen StorageNode ausgetauscht. Des Weiteren wurde eine NetApp VTL-700 als Cache und als Datengrab in die bestehende Umgebung integriert.

Die Herausforderung bei der Umstellung war aber nicht das NetWorker Update, sondern die Integration der neuen 72 virtuellen Laufwerke in die Umgebung mit NetWorker-Server, dessen örtlich getrennter StorageNode und 8 NetApp Filern. Hier war im Vorfeld eine gute Planung und Abstimmung notwendig. Schließlich soll ja nicht jede Maschine alle 72 Laufwerke sehen können.
Auf der anderen Seite soll die StorageNode aber auch als Quasi-Cluster fungieren und die Laufwerke des Servers sehr wohl sehen. Hierfür ist eine eindeutige Namensgebung der Laufwerke (persistent device names) an Server und StorageNode Voraussetzung. Erreicht wurde dieses durch den Einsatz des LINUX udev Drivers und einer geschickten Namensgebung.

Nach einigen kleineren und größeren Problemen (es wurde unter anderem ein HotFix von Fujitsu benötigt), läuft die Konfiguration nun wieder reibungslos.