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.

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.

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.