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.

Aufbau eines standortübergreifenden NetWorker Servers

Der Kunde benötigte aus Revisionsgründen eine Datensicherungskonfiguration die den Ausfall einzelner NetWorker Komponenten (Band-Library, StorageNode, NetWorker-Server, SAN/LAN Switche) aber auch den Ausfall eines ganzen Standorts abfängt. Es bestand eine NetWorker Konfiguration ohne Standortkonzept auf Basis eines Windows-NetWorker Servers Version 7.3. Der gesicherte Datenbestand dieses NetWorker Servers sollte in die neue Umgebung übernommen werden. Folgende Arbeitsschritte wurden für den Aufbau der neuen Umgebung durchgeführt.

• Migration der NetWorker V7.3 Umgebung von Windows 2003 auf eine RedHat Linux NetWorker 7.5.2.
• Aufbau zweier NetWorker StorageNodes (in zwei getrennten Standorten)
• Aufbau eines Standby-NetWorker-Servers im entfernten Standort.
• Generierung von Cloning Skripten zum zeitnahen Clonen der nächtlichen Sicherungen.

Beschreibung der neuen Umgebung und deren Vorteile:

• Ausfallsichere Konzeption aller Komponenten durch folgende Vorkehrungen:
  • Generierung von persistenten Geräteknoten für Bandlaufwerke und die Roboter-Steuerung.
  • Sicherung der Daten in den jeweils anderen Standort.
  • Zeitnahes Clonen der Daten auf Bänder im Herkunfsstandort der Daten.
  • Ablage der NetWorker eigenen Datenbereiche (Mediendatenbank, Ressourcen, Index-Datenbanken) auf einem synchron gespiegelten Daten-Volume. Die Plattform hierfür bildet ein NetApp MetroCluster. Der Datenbereich wird mit einer 10GBit LAN Verbindung per NFS am NetWorker Server und dessen Standby Partners verbunden. Hierdurch wird eine Verlustfreie Übernahme der Server Funktionalität am anderen Standort ermöglicht.
  • Kein Start-Stop Betrieb der neuen LTO4 Technik durch den Einsatz von Advanced File Type Devices (AFT-Devices).
    • Die Daten der AFT-Devices werden zeitnah auf den anderen Standort dupliziert und nach „n“ Tagen von den Platten auf lokale BandMedien verdrängt (Staging).
  • schnelles Recover da 95 % aller Recover-Anforderungen von Advanced File Devices erfolgen.
• Einfaches Handling, die Intelligenz der Lösung liegt im Aufbau der ganzen Umgebung und den angefertigten Skripten.
  • Die Definition des Sicherungsstandorts erfolgt bei der Sicherung über das Attribut StorageNodes bei den Clients und beim Cloning / Staging über die Definition geeigneter Pools.
  • Ein Recover kann wie gewohnt durchgeführt werden. Das Operating muss nicht wissen wo die Daten gesichert wurden. NetWorker holt sich die Daten immer vom erreichbaren Medium.

Wenn Sie nähere Informationen über dieses Projekt wünschen, wenden Sie sich bitte an Herrn Schäfer.