Problemfall Datenmigration

Eine Datenmigration ist mehr als ein Kopieren von A nach B, vor allem mit steigendem Datenvolumen. Doc Storage erklärt, worauf es zu achten gilt, damit der Datenumzug auf ein neues Speichersystem reibungslos funktioniert.

Leserfrage: Daten von einem älteren Disk-Array auf ein neues Storage-System zu überspielen ist keine triviale Angelegenheit. Zumal das Datenvolumen selbst in KMUs viele 100 TByte und mehr beträgt. Eine einfach Kopieraktion führt oft genug zu Fehlermeldungen und zum Abbruch der Aktion. Wie lässt sich dies Vermeiden und lässt sich eine Datenmigration überhaupt automatisieren?

Antwort Doc Storage:

Datenmigration ist einfach der Prozess des Verschiebens von Daten von einem Ort zum anderen (ach was). Nicht nur als Folge des Wachstums eines Unternehmens sind Datenmigrationen unvermeidlich. Eventuell wird ein größeres Speichersystem benötigt, oder Datenformate ändern sich aufgrund veränderter Anforderungen oder Anwendungen. Auch wenn Hersteller entsprechender Software es uns immer wieder glauben, machen wollen, Migration von Daten ist niemals eine leichte Aufgabe, und vor allem keine kurzfristige. Für eine (bestenfalls) reibungsarme Migration ohne Ausfallzeiten oder Verfügbarkeitslücken ist eine Vielzahl von Dingen zu beachten. Hier also einige Praktiken, die unabhängig von der Systemarchitektur zu befolgen sind, um in möglichst wenige Probleme zu geraten.

Es gibt zwei hauptsächliche Punkte, die zu berücksichtigen sind, bevor mit einer Migration in einem laufenden System begonnen werden sollte. Erstens – wie wird sichergestellt, dass die Daten im Ziel aktuell bleiben, also alle Änderungen an den bereits kopierten Daten auch auf den neuen Speicher übertragen werden? Während der Migration schreiben die meisten Anwendungen immer noch in den bisherigen Speicher. Somit gehen – ohne zusätzliche Maßnahmen – alle Aktualisierungen an bereits migrierten Daten im neuen Speicher verloren. Zweitens, wie lassen sich Anwendungen reibungslos »schwenken«, um den neuen Speicher zu verwenden? Es muss zu jedem Zeitpunkt möglich sein, eine oder alle Anwendung(en) auf den alten Speicher zurückzusetzen. Ein jederzeit reibungsloser Übergang zwischen altem und neuem Speicher ist der Schlüssel zu einer Migration ohne größere Ausfallzeiten.

Dateimigration: Schreib-Lese-Flag nutzen

Um diese Anforderungen zu erfüllen, sollte vom Schreib-Lese-Flag Gebrauch gemacht werden. Dies ist ein Schalter im Dateisystem, der bestimmte Eigenschaften von Dateien während der Laufzeit ein- oder ausschalten kann. Für eine Migration sollte ein solcher Flag vier Werte haben können, die jeweils festlegen, wie Anwendungen mit den gespeicherten Daten umgehen. Vor Beginn der Migration arbeiten die Anwendungen nur mit dem alten Speichersystem – dies ist das Standardverhalten und soll hier »A« heißen. Wird das Flag auf »B« gesetzt, lesen die Anwendungen aus dem alten Speicher, schreiben allerdings bereits in beide. Diese Nutzung des neuen Speichers sollte bereits beginnen, bevor die eigentliche Migration startet. Dies stellt sicher, dass der neue Speicher aktualisiert bleibt, während der der alte Speicher weiterhin wie gewohnt funktioniert.

Nach Abschluss der Migration können die Anwendungen Daten aus dem neuen Speicher lesen, schreiben aber immer noch in beide – das Flag kann also auf »C« gesetzt werden. Sollten wider Erwarten Fehler auftreten, kann das Flag sofort wieder zurück auf »B« gesetzt werden. Dank des fortgesetzten Schreibens in beide Speicher sind beide noch voll nutzbar. Nach einer bestimmten Zeit, in der sich das neue System als stabil und fehlerfrei erwiesen hat, kann das letzte Flag »D« gesetzt werden. Nun schreibt der Rechner nur noch auf das neue System, und liest auch nur noch aus diesem. Hiermit ist dann die Migration beendet. Der große Vorteil dieses Vorgehens ist, dass für den gesamten Prozess keine Code-Änderung oder zusätzliche Bereitstellungen erforderlich sind. Und, die gesamte aktive Logik kann bereits vor Beginn der Migration vorbereitet und getestet werden.

Migration: Zusätzliche Ressourcen-Auslastung einplanen

Das Hauptproblem beim »doppelten Schreiben« besteht allerdings darin, dass es den sonst üblichen Schreibverkehr auf die Speichersysteme mehr oder weniger verdoppelt. Hier gilt es zu beachten, dass von Netzwerk- und Komponentenseite die entsprechenden Bandbreiten und I/O-Leistungen zur Verfügung stehen. Des Weiteren kann das doppelte Schreiben auch längere Antwortzeiten für die Produktivsysteme mit sich bringen – im schlimmsten Fall führt dies zum Stillstand. Deshalb muss bereits in der Planungsphase vor der Migration sichergestellt werden, bis zu welchen Antwortzeiten welche Anwendungen noch »zu gebrauchen« sind. Hier kommt man also um die guten alten Belastungstests nicht herum, um den maximalen Datenverkehr festzustellen, den das Gesamtsystem unterstützen kann. Das Verständnis der Auswirkungen einer Migration auf die Systeme ist wichtig, um sich auf das Unerwartete vorzubereiten.

Datenmigration: Probleme einkalkulieren

Auch mit dem oben beschriebenen Schreib-Lese-Flag und genauester Ressourcen-Planung können immer noch Fehler passieren. Die kleinsten Netzwerkprobleme können zu einer Zeitüberschreitung beim Einfügen von Daten führen. Und – »alles, was schief gehen kann, wird schief gehen«. Das wissen wir alle, davor muss man nicht mehr warnen. Bevor beispielsweise das Read-Write-Flag »C« (nur noch aus dem neuen System lesen) gesetzt wird, empfiehlt sich dringend eine Konsistenzprüfung aller Inhalte, sowohl mit Hilfe des Dateisystems als auch der schreibenden Anwendungen. Bei Inkonsistenzen können die Daten immer noch aus dem Altsystem überführt werden, da unter »C« immer noch auch dorthin geschrieben wird. Ab einer bestimmten Datenmenge sollten IT-Manager diese Prüfung mit einem automatisierten Skript durchführen. Abhängig von der Fehlertoleranz lassen sich entweder vollständige oder Stichprobenkonsistenzprüfungen durchführen.

Das Prüfskript sollte nach Möglichkeit auch den Prozentsatz der gefundenen Inkonsistenzen melden. Liegt dieser Wert über einem tolerierten Maximum, sollten die Ursache gefunden werden, bevor die Anwendungen auf »D« umschalten. In der Zwischenzeit kann die Lösung von Konsistenzproblemen synchron oder asynchron erfolgen. Im synchronen Modus wendet das Prüfskript Korrekturen sofort nach dem Auffinden von Inkonsistenzen an. Im asynchronen Modus verschiebt das Skript die Markierung eines Fehlers in eine Warteschlange, um ihn dann zu einem bestimmten späteren Zeitpunkt mit anderen gebündelt anzuwenden.

Migration: synchron oder asynchron?

Welche Auswirkungen haben die synchronen und asynchronen Methoden auf die Anwendungen? Angenommen, die Anwendungen schreiben Daten synchron in beide Speicher. Für die Konsistenzprüfung ist allerdings »asynchron« eingestellt. Durch eine Warteschlange kann es hier zu kurzzeitigen Verzögerungen kommen. Bis alle Korrekturen dann asynchron ausgeführt werden, könnten die Speicher bereits neuere Versionen von Anwendungen enthalten. Das asynchrone Skript überschreibt dann die aktuelleren Daten mit bereits veralteten. In den meisten Fällen sollte man sich also, vor allem in Systemen mit hohen Schreib-, also Veränderungsraten, für eine synchrone Korrektur entscheiden, da sie unkompliziert und fehlerunanfälliger ist. Migrationen werden immer umso komplexer, je mehr Daten aus unterschiedlichen Quellen zu fließen. Der DV-Manager sollte dieses Verhalten sehr genau kennen und verstehen, ansonsten könnte dies unangenehme Konsequenzen haben.

Konsistenzprüfung und Fehlerprotokolle

Sollte man schon länger dabei sein, wird man wissen, dass Systemprotokolle die besten Freunde aller DVler sind. Bei der Migration sind zwei Arten von Protokollen hervorzuheben, die das Leben zigmal einfacher machen. Es ist zu bedenken, dass Fehler jederzeit passieren können (und werden!) und man darauf vorbereitet sein muss. Sollte ein Fehler auftreten, sollte das Skript ihn zu Debugging-Zwecken melden. Anstatt sich nur auf die Konsistenzprüfung zur Fehlerbehebung zu verlassen, ist es dringend angeraten, diese sofort zu beheben, falls sie auftreten.

Dauert die Migration zwei Wochen, nimmt eine vollständige Datenprüfung dieselbe Zeit in Anspruch. Dies ist meist überhaupt nicht machbar, es sei denn, man hat das einzige Projekt der Welt erwischt, das keinen Zeitdruck hat. Mithilfe von Fehlerprotokollen kann deren Behebung manuell durchgeführt werden. Hat man genügend Zeit, lässt sich ein weiteres Skript entwerfen, um die Protokolle durchzusehen und die Probleme automatisch zu beheben. Sollte man so vorgehen, ist die Konsistenzprüfung nur eine Rückversicherung. Eine stichprobenartige Prüfung am Ende ist schneller und dann mehr als ausreichend.

Migration ausführlich vorbereiten & Checkliste nicht vergessen

Man muss es niemandem sagen, der das schon einmal machen musste – die Migration großer Datenmengen ist ein qualvoller Vorgang. Man sollte aber immer genau wissen, welcher Unterprozess gerade läuft und vor allem, welcher wann beendet ist. Wenn man den Fortschritt der Migration kennt, weiß man beispielsweise, wie viel zusätzlichen Schreibverkehr dem System aufgelastet wurde. Außerdem ist es immer gut, auf Nachfrage »von oben« schnell und genau Auskunft über den Fortschritt geben zu können. So kann man beispielsweise jede Minute die Datenmenge protokollieren, die bisher migriert wurde. Da man ja die Gesamtdatenmenge kennt, lässt sich abschätzen (nicht voraussagen!), wie viel Zeit der gesamte Prozess benötigen wird.

Eine Migration ist immer sorgfältig vorzubereiten. Je mehr Arbeit man in die Vorbereitung steckt, je größer die Kenntnis der Systeme und ihrer Leistungsfähigkeit ist, desto weniger Nachtschichten hat man während der Migration vor sich. Ich weiß, ich weiß, alles alte Kamellen, kenn ich, weiß ich, war ich schon, hab das T-Shirt. Aber eben, weil wir alle meinen, schon einmal alles über Migrationen gewusst zu haben, sollte man immer so an eine neue herangehen, als ob es das erste Mal ist. Nie vergessen – es fallen nur deshalb so wenige Flugzeuge vom Himmel, weil selbst die Piloten mit den meisten Flugstunden immer und immer und immer wieder die Checkliste durchgehen.

Gruß
Doc Storage

Weiterführende Links

• Doc Storage: Energieverbrauch in mittleren Rechenzentren reduzieren
• Doc Storage: Rechenzentren: Energie- und Stromhunger vs. Nachhaltigkeit
• Doc Storage: Wann benötigen Unternehmen einen Chief Digital Officer?
• Doc Storage: Wird NVMe-over-TCP das FC-SAN ablösen?
• Doc Storage: Storage: Edge-Computing gehört die Zukunft
• Doc Storage: Ist die Cloud die Zukunft? Ja, aber…