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.

NetWorker 8.x in einer DMZ-Umgebung.

Erster Update-eines FSC/FTS OEM-NetWorker FWX-Tunnels auf die neue NetWorker 8.0 Funktionalität.

Nachdem ich die erste Migration eines NetWorker FWX-Tunnels bei einem unserer Kunden durchführen konnte, will ich das sehr erfolgreiche Ergebnis an dieser Stelle weitergeben.

Zunächst aber eine kleine Einführung für alle die NetWorker Kunden, die das NSR-FWX Modul noch nicht kennen.

Eine NetWorker-Umgebung benötigt zur Kommunikation zwischen dem NetWorker-Server und seinen Clients standardmäßig eine größere Anzahl von TCP/IP-Ports.

Der Grund für dieses, von Firewall Administratoren nur schwer akzeptierbare Verhalten liegt in der Basis der NetWorker-Kommunikationstechnik. NetWorker verwendet für alle Verbindungen zwischen seinen Client-Programmen und den Server-Programmen das Remote-Procedure-Call(RPC)-Verfahren. Dieses definiert zwar eine eindeutige RPC-Nummer für jeden Dienst, ein TCP-Port hierzu wird aber erst zur Laufzeit allokiert. Der Vorteil des Verfahrens liegt in seiner hohen Flexibilität, denn der Weg und auch das Ziel der Datensicherung wird erst beim tatsächlichen Start des Backups ermittelt. Fällt ein Laufwerk oder gar eine StorageNode für das Backup aus, so wird die Sicherung dynamisch auf ein anderes Laufwerk umgeleitet. Durch eine einmal definierte Konfiguration ist sichergestellt, dass das Backup auch in einem Fehlerfall durchgeführt werden kann.
Diese Eigenschaft ist für den normalen Betrieb also sehr vorteilhaft. In einer Rechnerlandschaft aber, in der eine durch Firewall getrennte Datenzone gesichert werden soll, ist das Verhalten eher kontraproduktiv, weil nicht nur viele TCP-Ports benötigt werden, sondern auch noch Ports in beiden Richtungen geöffnet werden müssen. Beim Start der Sicherung kontaktiert der NetWorker-Server den zu sichernden Client, der im Anschluß daran für jeden Sicherungsjob gleich 5 Verbindungen zu den diversen NetWorker-Diensten am NetWorker-Server benötigt.

Die Fujitsu-Siemens OEM-NetWorker Version hatte für dieses Problem schon seit einigen Jahren eine Tunnel-Lösung erhalten. Die Lösung basiert auf dem freien "vtun" Daemonen und implemetiert einen Filter- und einen Proxy-Server. Nach der erfolgreichen Konfiguration beider Dienste wird dann in der Firewall lediglich noch ein TCP-Port benötigt und dieser kann gerichtet in lediglich einer Richtung definiert werden.

Die beschriebene Implementation hat sich in der NetWorker OEM-Version, vor allem bei Banken und Behörden, über Jahre bewährt, ist bei vielen Kunden im Einsatz und kann auch innerhalb einer NetWorker-Datazone mehrmals Verwendung finden. Zum Beispiel ist mir ein Kunde bekannt der mit einem NetWorker-Server mehr als 10 DMZ-Umgebungen mit einem NetWorker-Server sichert.
Mit der NetWorker Version 8.0 hat EMC die Funktionalität des Tunnel-Konzepts in seine NetWorker-Version integriert. Hierzu müssen jedoch die bestehenden Konfigurationen von Hand migriert werden.

Folgende wesentliche Änderungen lassen sich bei der EMC-Integration festhalten:

1. Die ursprüngliche Implementation benötigte für die Funktionalität zusätzliche Installations-Pakete. Die EMC-Implementation hat die Tunnel-Funktionalität im NetWorker Client Paket integriert.
2. Bei der ursprünglichen Version mussten auf dem FWX-Filter und dem FWX-Proxy für jeden Tunnel mehrere Konfigurationsdateien angelegt werden. Der Name dieser Dateien war Teil der Funktionalität und der Sicherheitsüberprüfung. Die EMC-Implementation hat für diesen Zweck im NetWorker-Client Daemon (nsrexecd) einen neuen Ressource-Typ (nsr tunnel) intergriert. Hierdurch wird die Konfiguration transparenter, leichter implementierbar und auch weniger fehleranfällig.
3. Bei der FSC/FTS Version musste der Start der Tunnel Dämonen vor dem Start der NetWorker Dienste erfolgen. Es war folglich nicht möglich Änderungen oder gar einen Neustart des Tunnels durchzuführen, ohne den NetWorker-Client oder gar den NetWorker-Server neu zu starten. Diese unschöne Abhängigkeit ist durch die Integration des Tunnels in den NetWorker-Client entfallen. Jetzt wird sowohl der Proxy als auch der FWX-Filter direkt vom NetWorker-Client Daemon gestartet. Hierduch ist das Ändern und der Neustart eines Tunnels auch während laufender NetWorker-Sicherungen möglich.
4. Für die ursprüngliche Tunnel-Lösung wurde von FSC/FTS für jeden laufenden Tunnel eine Lizenz verlangt. Diese Lizenz entfällt bei EMC!

Gleich geblieben ist jedoch die Einschränkung der Betriebssytem-Plattformen auf der die Tunnel-Dienste laufen können. Dies sind LINUX und Solaris. D.h.: Der NetWorker-Server und der NetWorker-Firewall-Proxy in der DMZ müssen auf LINUX und/oder Solaris laufen. Die in der DMZ zu sichernden Clients können jedoch jedes beliebige von NetWorker unterstützte Betriebssystem verwenden. Diese Clients erkennen gar nicht, dass ihr NetWorker-Server über eine Firewall-Konfiguration gesichert wird. Für die erfolgreiche Sicherung dieser Clients über den FWX-Tunnel wird lediglich das setzen des Client-Attributes "server network interface" benötigt.

Wichtiger Hinweis.
Vor einer Sicherung von Massendaten durch eine Firwall möchte ich an dieser Stelle aber unbedingt abraten. Sollen größere Datenmengen aus einer DMZ gesichert werden, so benötigt man in der DMZ eine eigene StorageNode. Hierdurch kann man die Sicherung der Massendaten innerhalb des DMZ-Netzes belassen und den Firewall-Tunnel benötigt man nur noch für die NetWorker-Metadaten (Index-, Medien-, Job-DB).

Weitere Informationen über das NetWorker-Firewall-Tunnel-Modul können Sie entweder im Workshop NetWorker Admin-3, oder direkt vom Author dieses Blocks erhalten.

NetWorker besitzt seit der Version 7.3 einen eigenen Client-Update Mechanismus. Nun ist seit dieser Version doch schon einige Zeit vergangen und es scheint nicht verwunderlich, dass Maschinen die vielleicht in dieser Version inventarisiert wurden, mittlerweile nicht mehr existieren. Doch wie bekommt man diese "alten" Clients jetzt auch aus der NetWorker-Versions-Datenbank (Push-DB) entfernt?

Man kann natürlich erstmal fragen, warum sollte man die denn entfernen wollen? Dazu kurz folgende Zusatzinformation:

Mit Hilfe des nsrpush Kommandos kann man leicht alle NetWorker Clients eines NetWorker Servers auf eine neue Version updaten. Hierzu dient die nsrpush Option 'all'.
Hat man aber seit dem letzten Inventory einen oder mehrere NetWorker-Clients gelöscht, so erhält man vom nsrpush die nette Meldung:
"Skipping client 'old_client' because it is no longer configured with this server"

Wie bekommt man aber jetzt diesen gelöschten Client aus der Push-DB?
Der nsrpush selbst bietet einem hierzu leider keine Option.
Wenn man aber weiß, dass die Push-DB eine NetWorker-RAP Database ist, läßt sich das relativ leicht mit dem 'nsradmin' Kommando bewerkstelligen.
Man benötigt folglich "nur" noch den Ressource-Namen und ein eindeutiges Attribut zum Löschen der zugehörigen Ressource.
Hier der passende Kommando Aufruf:

echo ". type: NSR installed Software; name:  old_client
           delete " | nsradmin -i - -d /nsr/res/cpdb

Wie schon lange von Fujitsu und EMC versprochen hat der neue NetWorker Version 8.0 so ziemlich alle Fujitsu NetWorker Erweiterungen erhalten. Ja - auch das Firewall Modul ist jetzt im NetWorker 8 vorhanden - auch wenn dieses nicht explizit von EMC erwähnt wird.

Damit hat der EMC NetWorker 8 alle nötigen Funktionen, so dass einer Migration der NetWorker Version von FTS zu EMC nichts mehr im Wege stehen sollte.

Hier noch einmal eine Auflistung der wichtigsten nun integrierten FTS Features:

• Firewall Modul
• scm_filter
• "server network interface" Attribute für Devices und Jukeboxen
• compression directive (gzip, bzip2)
• automatisches Rollover der daemon.raw
• Beruhigen eines NetWorker Servers:
  • "accept new session" Attribute

Diese Liste erhebt natürlich keinen Anspruch auf Vollständigkeit, sollte aber die wichtigsten Punkte enthalten.

Sollten SIe Fragen zur Migration von NetWorker-FTS zu NetWorker 8 von EMC haben, so scheuen Sie sich nicht uns per E-Mail zu kontaktieren. Nähere Informationen zur Umstellung, inklusive Aufzeigen eines Migrationsweges, erhalten sie auch in unserem NetWorker 8.0 Update Workshop