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.

Im letzten Herbst habe ich bereits eine Lösung für das Problem, "werden alle NetApp Volumes auch vom NetWorker gesichert" vorgestellt. Die Überwachung der gesicherten NetApp Volumes wurde anhand von einem Python Script mit unserer eignenen NetApp API durchgeführt und läuft seit dem sehr erfolgreich bei unseren Kunden. Jetzt kam eine neue Herausforderung hinzu!

Ein weiterer Kunde sichert die NetApp Volumes nicht als komplette Volumes, sondern unterteilt diese in mehrere Sicherungen, von NetApp-Qtrees bzw zum Teil auch in Sicherungen von Unterverzeichnissen mehrere Stufen unterhalb des Volume Namens. Natürlich sollte sicher gestellt sein, dass alle Unterverzeichnisse eines Volumes gesichert werden. Es kommt aber leider immer mal wieder vor, dass andere Abteilungen, neue parallele Verzeichnisse zu den bestehenden aufbauen ohne an die Datensicherung zu denken. Dies passiert zum einen, weil mehrere Abteilungen über verschieden Standorte verteilt an der Administration des Storage beteilgt sind. So kann zum Beispiel die Windows-Abteilung in Ihrem Volume selbstverständlich neue Freigaben generieren und hierfür auch neue Verzeichnisse anlegen.

Hier ein kleines Beispiel um das Thema etwas griffiger zu gestalten:

Das Volume /vol/sv_filer3_bauplaene enthält zurzeit 5 TB zu sichernde Daten. Diese Daten verteilen sich in folgende Verzeichisse:
        /vol/sv_filer3_bauplaene/MUC
        /vol/sv_filer3_bauplaene/FRA
        /vol/sv_filer3_bauplaene/HAM
        /vol/sv_filer3_bauplaene/KOB
        /vol/sv_filer3_bauplaene/DUS
        /vol/sv_filer3_bauplaene/KOL
        /vol/sv_filer3_bauplaene/BRE
        /vol/sv_filer3_bauplaene/PDB
        /vol/sv_filer3_bauplaene/KA

Alle Verzeichnisse sind in 3 NetWorker Client Ressourcen eingetragen. Der Vorteil hierbei liegt auf der Hand: Die Vollsicherung des Volumes kann an 3 unterschiedlichen Tagen stattfinden und bei auftretenden Problemen kann gezielt ein SaveSet der Sicherung nachgefahren werden.
       
Die Windows Abteilung generiert das neue Verzeichis "/vol/sv_filer3_bauplaene/STG" vergisst aber leider dies den NetWorker Administratoren mitzuteilen. Nach "n" Wochen möchte ein Entwickler einen 3 Wochen alten Plan aus der Unterverzeichnis "STG" wiederhergestellt haben. Dumm gelaufen.

Um genau dieses Problem nicht entstehen zu lassen, haben wir unser kleines Überwachungstool so erweitert, dass jetzt auch beliebig tiefe Unterverzeichnisstrukturen analysiert werden. Im obigen Fall würde nach dem Generieren des Verzeichnisses am folgenden Morgen eine Mail an den Backup-Administrator gesendet, in der er mitgeteilt bekommt, dass das Verzeichnis "STG" nicht in der Sicherung enthalten ist.

Das Tool ermittelt zunächst für den angegebenen Filer alle im NetWorker enthaltenen SaveSets und generiert daraus eine Liste der Verzeichisse und Volumes, die untersucht werden müssen. Hierauf wird am Filer eine Auflistung der Verzeichnisse und Volumes angefordert. Die gesammelten Daten werden im Anschluß gegen die bereits bekannte "Whitelist" verglichen und alle nicht bekannten Volumes und "parallel Verzeichnisse" werden den NetWorker Administratoren gemailt.

Hier ein Beispiel für den Aufruf eines Überwachungslaufs:

================================================================================
        not saved Volumes und Subdirectorys for NetApp Filer: nafiler3
        check WIKI entry: http://ciwi/s_t_wiki/index.php5/Check_Volume_Backup
================================================================================

db_oaiacc
db_oaidev

/vol/sv_filer3_bauplaene/STG

Die beiden Volumes "db_oaiacc" und "db_oaidev" gehören in die WhiteListe der SaveSets. "/vol/sv_filer3_bauplaene/STG" sollte in die NetWorker Konfiguration aufgenommen werden.

Bei der Auseinandersetzung mit dem Thema, Windows-Systeme mittels Networker-NMM - also der konsequent auf VSS-Snapshots basierenden Sicherung via Networker - zu sichern, bin ich auf die Aussage gestoßen, dass die in den Windows-Servern implementierte VSS-Unterstützung stets zuerst eventuell vorhandene VSS-Hardware-Provider zu nutzen versucht und bei Notwendigkeit anschließend den Microsoft Software Shadow Copy Provider mit der Erstellung des Snapshots beauftragt. Nun gut, eine Regelung muss es ja geben. Sinnvoll ist sie außerdem: erst mal versuchen, zu delegieren, dann doch selber machen ...

Auf die Konsequenzen aus diesem Verhalten wurde ich kürzlich aufmerksam: Ein Zwei-Node MSCS-Activ-Activ-Cluster (Windows 2003) nutzt per SnapDrive den Storage einer NetApp. Für die in den virtuellen Servern installierte (und nicht weit verbreitete) Applikation gibt es keinen SnapManager, der beim Backup Unterstützung liefert. Die Betreiber des Clusters waren beunruhigt über Fehlermeldungen des Servers, die auf massive Probleme des Volume Shadow Copy Service (VSS) hinwiesen. Außerdem würden in unregelmäßigen Abständen Laufwerke an den Clusternodes angezeigt, deren Herkunft sich niemand erklären konnte. Wichtig war der Hinweis, dass beide Phänomene im zeitlichen Zusammenhang mit der nächtlich ausgeführten Networker-Sicherung zu stehen scheinen.

Apropos NetWorker Sicherung, wie würde ich vorgehen?
Nun, ich würde in diesem Fall die auf shared LUNs abgelegten Daten aus dem letzten (oder einem anderen) Snapshots des Volumes, in dem die LUN liegt, per SnapDrive zugänglich machen, die NetWorker-Sicherung ausführen und anschließend den Clone der LUN wieder entfernen. Also die Networker-Sicherung mit vor- und nachgeschalteten Befehlen "abrunden".

Aber das Vorhandensein eines NetWorker-Savesets "ALL" ist wohl zu verlockend: es kümmert sich um alles und wird es schon richten. Das dies spätestens beim Einsatz des vom Konzept her genialen NMM überhaupt nicht mehr funktioniert, habe ich in einem früheren Beitrag bereits dargelegt. Die Nodes des MSCS waren beide für die Sicherung per Saveset ALL eingerichtet, wobei die durch die virtuellen Server genutzen Laufwerke sowie die Quorum-Disk aus der Sicherung ausgeschlossen wurden oder ausgeschlossen werden sollten.

Gesichert werden sollte also nicht ALL, sondern der "Systemstate" und die Dateien des Betriebssytemlaufwerkes (C:\). Eine in diesem Umfang testhalber ausgeführte Sicherung war die erste auf diesen Systemen überhaupt, die völlig ohne Warnungen oder gar Fehler ausgeführt werden konnte.

Was war also passiert: Der Networker beauftragt seinen Client, doch erst mal das System klar zu machen dafür, "ALL"es zu sichern, denn später kann er ja immer noch darauf verzichten, auch alle Daten "abzuholen".

Da standardmäßig der für Datenkonsistenz  sorgende Weg über VSS-Backups gegangen wird, geht der Auftrag an alle VSS-Writer raus, die VSS-Sicherung "auf breiter Front" (Saveset ALL !) vorzubereiten, was von diesen auch problemlos quittiert werden kann. Nun sind die VSS-Provider an der Reihe, die Snapshots zu erstellen: der in SnapDrive implementierte NetApp-VSS-Hardwareprovider zuerst, dann der Microsoft-Software-Provider.

Und SnapDrive reagiert so, wie es von SnapDrive erwartet wird: von allen angeschlossenen LUNs wird ein Snapshot erstellt. Stimmt natürlich nicht: das Snapshot wird jeweils von dem Volume erstellt, in dem sich die LUN befindet. Und um sicherzugehen, dass das auch funktioniert hat, prüft SnapDrive den Zugiff auf die LUN im gerade erstellten Snapshot und greift kurzzeitig auf eine *.rws - LUN zu. Diese Snapshots werden aber gar nicht benötigt, da die LUN-Inhalte ja extra "excluded" wurden. Jetzt haben wir ein Snapshot, dass keiner haben wollte und niemend braucht - und fast zeitgleich legt der Software-Provider los, und will nun seinerseits von "ALL"em Datenbestand eine Schattenkopie anlegen; mitunter wohl auch von der zwecks Test nur kurzzeitig gemounteten LUN im Snapshot (die im nächsten Moment aber schon wieder "weg" sein kann, wenn dann die Daten abgeholt werden könnten). Fallen diese Zugriffe zeitlich "unglücklich" zusammen, dann sorgt der Zugriff auf die temporäre LUN dafür, dass SnapDrive diese nicht wieder entfernen kann. Damit sind sowohl die sporadisch "aus dem Nichts" auftauchenden Disks als auch die massiven Probleme im VSS-Bereich erklärt.

Die von mir oben beschriebene Methode für das Networker-Backup aus dem letzten Snapshot heraus werde ich die nächsten Tage einrichten und damit für ein System sorgen, in dessen Ereignisanzeige weder gelbe noch rote Hinweise auftauchen.

Nach und nach gibt es immer mehr Situationen, in denen Networker-Saveset ALL nicht eingesetzt werden kann: bereiten wir uns auf den Abschied vom Networker Saveset ALL vor !