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

EMC hat diese Woche die neueste NetWorker Version mit einem großen Internet-Event vorgestellt. Im "EMC Community Network" kann man sich das zugehörige Video anschauen. Hier der zugehörige Link zum Video.

Aber Achtung: Das sind ca 45 Minuten und davon sind doch einige Minuten reines Marketing. Es gibt mittlerweile jedoch auch Ausschnitte aus dem Event mit den wirklich interessanten Sequenzen in YouTube.

Hierin werden allerdings längst nicht alle neuen Features und Verbesserungen des NetWorker 8.0 vorgestellt. Eine komplette Liste und tiefer gehende Informationen erhalten sie natürlich wie immer in unseren Workshops NetWorker Update 8.0 und NetWorker NMM.

Hier eine Liste der interessanten Videos:

Ausschnitte aus dem Launch:

EMC NetWorker 8.0 Overview

EMC NetWorker 8.0 Client Direct Demo

EMC NetWorker 8.0 Enhanced Microsoft Application Support

Weitere Videos zum Thema NetWorker Server 8.0:

EMC NetWorker 8.0 Multi Tenancy

EMC NetWorker Multi-Tenancy Facility Configuration

Videos zum NetWorker Modul NMM 2.4

EMC NetWorker Module for Microsoft Application 2.4 Installation and Config Checker

EMC NetWorker Client Configuration Wizard for Exchange

EMC NetWorker Module for Microsoft Applications - Exchange RDB

EMC NetWorker SQL Configuration Wizard with Data Domain

EMC NetWorker Module for Microsoft Applications 2.4 SharePoint GLR

EMC NetWorker Module for Microsoft Applications Hyper-V Overview and GLR

EMC NetWorker Module for Microsoft Applications Hyper-V CSV

EMC NetWorker Module for Microsoft Application 2.4 Kroll OnTrack GLR

Animierte Videos zur Vergangenheit und Gegenwart von NetWorker

EMC NetWorker 8.0 animation

EMC NetWorker 8.0 Retrospective