Erste erfolgreiche Migration eines Windows basierten NetWorker-Servers auf ein Linux System mit Hilfe der in NetWorker V19.9 neu eingeführten Migrations-Kommandos.

Durch das verstärkte Auftreten von Male-Ware Angriffen wird der Wunsch und auch der Druck immer größer, bestehende Windows-NetWorker-Server auf ein Linux-System zu migrieren.

Wer schon einmal einen verschlüsselten NetWorker-Server wieder ans rennen bringen musste (so wie ich für einen unserer Kunden ;-/) weiß, es ist keine gute Idee ein Backup System auf dem OS laufen zu haben, das am allermeisten unter den Verschlüsselungs-Angriffen zu leiden hat. Wenn man dann noch berücksichtigt, dass die Datensicherung eines der ersten Angriffsziele der Erpresser ist, (wenn der angegriffene seine Daten nicht wiederherstellen kann, ist er natürlich eher bereit das Erpressergeld zu zahlen), sollte jedem klar sein, dass auch die Plattform der Backup-Software so sicher wie möglich sein muss. Und da ist man mit einem Linux-System wesentlich sicherer unterwegs! Mir ist zumindest bisher kein durch einen Verschlüsselungstrojaner verschlüsseltes Linux-System bekannt geworden!

Bis zur NetWorker-Version 19.9 war die Migration von Windows zu Linux für einen NetWorker-Server ein Albtraum. Aber mit den neu eingeführten Kommandos nsrimportmmdb und nsrimportclient, sowie einer DataDomain als Backup-Storage lässt sich eine NetWorker-Server Migration ohne Einschränkungen durchführen. Klar, es sind einige Vor- und Nach-bereitungen nötig, aber mit einer guten Planung kann die Downtime des NetWorker-Servers während der eigentlichen Migration auf wenige Stunden begrenzt werden.

Die Vorbereitungen umfassen hierbei folgende Arbeiten:

• die Anpassung der Client „servers“ Dateien
• den Aufbau des neuen Linux-NetWorker-Servers
• die Übernahme der benötigten NetWorker-Ressourcen (natürlich Script gesteuert)
• das Erstellen einer schreibbaren Kopie des Sicherungs-Mtrees auf der DataDomain (hierfür wird kein zusätzlicher Platz auf dem Storage-System benötigt!)
• eine erfolgreiche Test-Migration (inclusive Test-Wiederherstellungen am neuen Server)
• Migration der NetWorker Lizenz auf das neue System

Die eigentliche Übernahme besteht dann nur noch aus:

• dem still legen des Windows-NetWorker-Servers
• der erneuten Kopie des DataDomain Mtrees
• der Migration existierender vProxy Systeme
• der Migration evtl. vorhandener StorageNodes und deren Laufwerke
• Aktivieren des neuen Servers

Die Nachbearbeitungen sind:

• Übernahme der letzten Indices
• Anpassung der Notifications
• Löschen des „alten“ Windows Mtrees auf der DataDomain
• ...

Wichtig zu erwähnen ist, dass die Migration immer auf einem doppeltem Boden aufgesetzt ist. Zu jeder Zeit kann diese unterbrochen werden, wenn eine bisher ungeahnte Problematik auftritt oder zum Beispiel ein Passwort für die Wiederherstellung der Lockbox nicht zu bekommen ist. Wichtig ist daher genügend Zeit für Recover und evtl. auch Backup-Tests vor der eigentlichen Migration einzuplanen.

Sollten auch Sie Ihren NetWorker-Server noch auf einem Windows-System betreiben und möchten diesen auf ein Linux-System migrieren lassen, dann melden Sie sich doch unverbindlich beim Autor dieses Blogs.

Der Storage-Markt ist in Bewegung. Neben den etablierten Platzhirschen wie EMC, IBM, Hitachi und NetApp gibt es einige neue Markteilnehmer, die versuchen mit neuen Ideen und Produkten im Markt Fuß zu fassen.

Einer dieser neuen Wilden ist Tintri. Tintri hat sein Storage Produkt als VAS "Virtual Aware Storage" implementiert. Soll heißen: Das Storage-System kennt den Virtualisierungs-Service und alle virtuellen Maschinen auf dem Storage und ermöglicht es so, die Storage-Performance und die Latency leicht pro virtueller Maschine zu überwachen und einzustellen.

Tintri bietet 2 Storage Varianten an: Hybrid-Flash und All-Flash. Auf beiden Varianten werden die Daten dedupliziert und komprimiert und dennoch ist das Storage-System im Vergleich zum Mitbewerb um ein mehrfaches schneller.

Genug der Vorrede kommen wir zum Thema: selbstverständlich bietet das Storage-System auch lokale Snapshots. Diese können entweder Crash- oder VM-Konsistent erstellt werden. Das Erzeugen der Snapshots kann entweder per Tintri eigenem Scheduler, per Hand oder über ein API erfolgen. Die Herausforderung bestand nun darin einen Storage-Snapshot eines LINUX-System per Kommando an eben diesem LINUX-System, als eigene(s) Filesystem(e) sichtbar zu machen. Entstanden ist ein "kleines" Python-Skript, dass genau diese Aufgabe erfüllt. Genauerer Informationen und das Tool selbst können sie über GitHub unter folgendem Link herunterladen.

GitHub: Tintri_LINUX_FLR

Sollten sie weitere Informationen zu unserem kleinen Helferlein wünschen, selbst einmal ein Automatisierungstool benötigen, oder Interesse am Tintri Storage bekommen haben, so melden sie sich doch einfach beim Autor per Email, oder rufen sie uns unter der folgenden Telefonnummer an:

Telefon: +49 8250 92903

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.