Die Corona Zeit hat uns weiterhin alle im Griff, so gab es für mich seit März keine Workshops im Hause qSkills (lediglich 3 virtuelle NetWorker Workshops fanden statt) und auch die vor Ort Einsätze bei Kunden beschränkten sich auf genau 2 HealthChecks.

Aber einige Dinge lassen sich auch in diesen Zeiten nicht bremsen, so zum Beispiel das Datenwachstum in den Unternehmen. Daher stand bei einem unserer Kunden ein Austausch der beiden DataDomain Systeme gegen neuere, größere Modelle an. Um genau zu sein, sollten zwei DD6400-er Modelle mit 4-TB Platten-Shelfs gegen zwei DD9800-er Modelle mit 8 TB Platten ersetzt werden.

Im Normalfall kann man bei einem Upgrade der DataDomain-Systeme einfach einen Head-Swap (Austausch der Betriebssystem-Einheit) durchführen, wodurch keine Datenmigration nötig wird und alle angeschlossenen Backup Systeme nach dem Tausch der Einheit weiter arbeiten können wie zuvor. In dem hier beschriebenen Fall, konnte dieses Verfahren aber leider nicht durchgeführt werden, weil die „alten“ Platten-Shelfs nicht an den neuen Kopf angeschlossen werden konnten. Wären auf den DataDomain-Systemen ausschließlich NetWorker Server im Einsatz gewesen, so hätte eine Lösung in einer schleichenden Übernahme der Daten mittels Cloned-Control-Replication (CCR) und einer NetWorker basierten Migration der Langzeitsicherungen bestehen können. Aber der Kunde ist Dienstleister und hat außer 3 NetWorker Servern, 3 weitere Backup-Applikationen (VEEAM, DD-Boost for EAPP und VRanger) auf Basis von DD-Boost mit Mtree-Replikationen im Einsatz. Zudem gibt es auch noch reine CIFS-Shares mit Mtree-Replikationen. Ziel des Systemaustausches war es aber dennoch: Alle Backup-Systeme sollten nach der Migration ohne Datenverlust und OHNE Konfigurationsänderungen wieder an den Start gehen können.

Es war folglich eine Migration der Daten mit einer Übernahme der Konfigurationen von den Alt-Systemen zu den Neu-Systemen nötig. Die Herausforderung bestand folglich darin:

• alle auf den beiden „alten“ DataDomain befindlichen Daten auf die beiden „neuen“ Systeme zu kopieren

• die Namen der „Alt-Systeme“ auf die „Neu-Systeme“ zu übernehmen

• die bestehenden Replikations-Beziehungen zwischen den DataDomain Systemen zu erhalten und auf die neuen Systeme zu übernehmen

• die Migration so zu gestalten, dass nach der erfolgreichen Migration alle Backup-Applikationen nahtlos mit den neuen Systemen weiter arbeiten können.

Wie geht man in einem solchen Falle vor?

Das DataDomain-Betriebssystem kennt neben den oben bereits erwähnten Replikationsarten, Mtree-Replikation und CCR die „altertümliche“ Art der Collection-Replikation. Diese Replikationsart kopiert auf Block-Ebene alle Daten einer DataDomain auf eine zweite DataDomain. Hierbei werden alle Mtrees, deren Snapshots und auch die lokalen Benutzer und sonstigen Konfigurationen mit kopiert. Auf den neuen Systemen sollten folglich nach der erfolgreichen Kopieraktion alle Daten und Konfigurationen der „alten“ Systeme zur Verfügung stehen. Der einzige größere Punkt wäre demnach die Übernahme der Netzwerk-Konfiguration und die Umbenennung der Systeme. So weit die graue Theorie, doch wie so oft liegt die Tücke im Detail. Doch dazu später mehr!

Meine erste Idee für eine erfolgreiche Umsetzung der obigen Aufgabe war natürlich ein Test der Migration mit virtuellen DataDomain-Systemen. ABER nachdem ich eine passende Test-Umgebung aufgebaut hatte, gab mir das virtuelle DataDomain-Betriebssystem zu verstehen, dass eine Collection-Replikation mit virtuellen Systemen nicht unterstützt wird.

Also war mal wieder eine Operation am offenen Herzen nötig. Frei nach dem Motto „No Risk No Fun“, setzte ich folglich die Collection-Replikation zwischen den Source-DataDomain- und den Destination-DataDomain-Systemen auf. Hierfür ist zwar eine DownTime aller beteiligten Backup-Systeme von Nöten (das Filesystem der DataDomain muss vor dem Aufsetzen der Collection-Replikation disabled werden), aber diese hält sich zeitlich in Grenzen und war auch nur ein kleines organisatorisches Problem.

Nach dem Aufsetzen der Replikation bestand die Aufgabe zunächst nur darin, zu beobachten, mit welcher Geschwindigkeit die Daten kopiert werden und ob evtl. die Datenrate eingeschränkt werden sollte, um die Netzwerke nicht zu überfordern. Doch dank 10-GB Ethernet gab es keine Last-Probleme und die 4 Systeme waren nach einigen Tagen synchron.

Der Tag des CutOver (Übernahme der kompletten Funktionalität auf das jeweils neue System) war schließlich da. Die Downtime für alle Backup-Syteme war vorsichtshalber für einen ganzen Arbeitstag eingeplant. Jetzt wurde es spannend. Wichtig für eine erfolgreiche Übernahme der Mtree-Replikationen ist es, vor der Unterbrechung der Collection-Replikation auf allen Mtrees einen Snapshot zu generieren. Auf diesem Snapshot kann die jeweilige Mtree-Replikation nach dem CutOver wieder aufgesetzt werden. Eine Beschreibung zu diesem Verfahren findet man hier (Data Domain: MTREE resync after Collection replication cutover). Folglich legten wir für jeden Mtree (16 an der Zahl) ein Snapshot an und kontrollierten das diese auch auf den Ziel-Systemen vorhanden waren. Nach der erfolgreichen Kontrolle wurde der BREAK der Collection-Replikation durchgeführt. Auch hierfür muss zunächst das Filesystem disabled werden. Nachdem die Filesysteme auf den neuen DataDomain-Systemen wieder aktiviert (enabled) wurden, hat man auf diesen Systemen ein voll funktionsfähiges Filesystem mit allen Mtrees und Benutzern der Alt-Systeme.

Also ran an die Umbenennung der Alt-Systeme in vorher vorbereitete Backup-Namen und Adressen. Anschließend konnten die Neu-Systeme die Namen und Adressen der altem Systeme bekommen. Diese Arbeiten müssen natürlich über die Management-Interfaces der DataDomain Systeme durchgeführt werden, da man sich ja sonst den Boden unter den Füßen wegzieht. Der erste Schreck war jedoch, dass man nach dem Umbenennen der Neu-Systeme diese nicht erreichen konnte. Eine kurzes Innehalten und reflektieren des Themas ergab dann schnell, das dieses Problem im ARP-Cache der Ethernet-Switches zu finden war. Diese Komponenten hatten natürlich noch die alten MAC-Adressen zu den alten IP-Adressen gespeichert und ließen die Kommunikation erst mal nicht zu. Nachdem dieses Thema erledigt war, konnte man sich an die Wiederherstellung der Replikationen begeben.

Wenn das oben erwähnte Dokument dieses Vorgehen auch etwas kurz ab handelt, war dieser Punkt eher eine Fleiß-Aufgabe. Auf den neuen Systemen ist nämlich zunächst nichts von den ‚alten‘ Mtree-Replikationsbeziehungen zu sehen. Diese müssen folglich zunächst auf beiden Systemen bekannt gemacht werden. Hiernach kann man durch die bestehenden Snapshots und die Funktion Resync die vorherige Beziehung wieder aktivieren.

Diese Schritte mussten für jede Mtree-Replikationsbeziehung separat durchgeführt werden. Wie gesagt, Fleißarbeit und volle Konzentration waren hier gefragt.

Aber dann der Schock, wo waren die für die DD-Boost Kommunikation benötigten Storage-Units?

Die Mtrees auf denen die StorageUnits zum Beispiel für den NetWorker-Backups basieren, waren da, aber die logische DD-Boost-Einheit „StorageUnit“ war von der Collection-Replikation nicht übertragen worden. Zumindest war von diesen nichts zu sehen! Ein Anlegen dieser StorageUnits auf den bereits bestehenden Mtrees verweigert das DataDomain-OS sowohl aus dem GUI als auch auf der CLI Ebene. Eine Recherche auf den Dell/EMC Support-Seiten konnte leider auch nicht weiter helfen. Ein Hilferuf in die EMC-Community ergab zunächst die Idee, den bestehenden Mtree mittels Fastcopy in eine neue StorageUnit zu kopieren, hierbei könnte man die alte zunächst umbenennen und die Kopie auf dem original Namen wieder aufsetzen. Dieses Verfahren funktioniert auch für die NetWorker-StorageUnits, ABER für die StorageUnits die mittels Mtree-Replikation ihre Daten auf das Destination-System kopieren ist es leider unbrauchbar, weil man hierdurch die zugehörige Replikationsbeziehung verliert. Gott sei Dank kam kurz vor der nötigen Entscheidung, entweder noch mal zurück auf die alten Systeme zu schwenken oder alle Mtree-Replikationen neu aufzusetzen, eine weitere Information aus der EMC-Community. Offensichtlich werden alle Informationen der StorageUnit bei der Collection-Replikation übertragen, lediglich der letzte Schritt das Sichtbar machen dieses logischen Elements scheint zu fehlen. Führt man demzufolge eine Veränderung an einer „verborgenen“ StorageUnit durch, dann wird diese plötzlich sichtbar und im Anschluss auch verwendbar.

Nachdem auch diese Hürde genommen war, konnten die Backup-Applikationen wieder starten, dachte man. Aber aus unerfindlichen Gründen gab es auf der Destination-DataDomain dann doch noch ein Problem mit den StorageUnits. Das betraf zwar nur die NetWorker Server, aber diese konnten auf die Destination nicht Clonen. Die Ursache dieses Problems lag darin, dass der NetWorker-Boost Benutzer auf dem neuen DataDomain System eine andere User-ID hatte als auf dem dem Ursprungssystem. Also Mounten der StorageUnit am NetWorker-Server, die Rechte umbiegen und auch dieses Problem war gelöst.

Am nächsten Tag gab es dann Gott sei Dank keine bösen Überraschungen! Alle Backups waren gelaufen, lediglich einige Überwachungsskripte, die per SSH Kommunikation (authorized keys) Daten direkt aus der DataDomain auslesen, konnten keine Daten liefern. Das Problem hier, die Home-Verzeichnisse der DataDomain-Benutzer werden bei der Collection-Replikation nicht mit kopiert. Der Benutzer selbst war aber da (s.o.), man konnte aber leider auch keine neuen SSH-Keys einrichten. Denn das zugehörige Kommando lieferte nur dubiose Fehlermeldungen (can not mkdir …). Auch hier Bestand die Lösung in einem Mount, in dem Falle des DataDomain-Konfigurations-Verzeichnisses (ddvar) und einem händischen Anlegen der zugehörigen Verzeichnisse und Dateien.

Bleibt noch zu erwähnen, dass das gesamte Projekt mittels Fern-Verbindung durchgeführt wurde.

FAZIT:

Die Migration „alter“ DataDomain Systeme auf „neue“ größere und schnellere Systeme konnte wie geplant mit einer überschaubaren Down-Time der Backup-Systeme ohne Datenverluste durchgeführt werden. Leider lässt sich dieses Verfahren nicht mit virtuellen Systemen testen und es gibt wie so oft kleine Stolpersteine auf dem Weg zum Erfolg. Aber für Umgebungen mit DD-Boost Konfigurationen mit zugehörigen Mtree-Replikationen erscheint es weiterhin die einzig praktikable Vorgehensweise zu sein.

Sollten Sie Fragen zum beschriebenen Projekt haben, oder Unterstützung bei einer ähnlichen Herausforderung haben, so scheuen Sie sich bitte nicht den Autor zu kontaktieren, wir finden bestimmt auch eine Lösung für Ihr Problem!