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.

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.