Egal wie stabil und ausfallsicher ein Disk-Array mit SATA- oder SAS-Laufwerken seinen Dienst verrichtet, irgendwann nagt der Zahn der Zeit an ihm. Nach einer Laufzeit von drei bis fünf Jahren sind RAIDs in der Regel intern abgeschrieben und bieten nicht mehr genügend Kapazität oder Leistung. Dann droht das Schreckgespenst der Migration.

Das Szenario ist ebenso bekannt wie gefürchtet: Vor drei, vier Jahren wurde ein damals schon preiswertes Disk-Array mit beispielsweise 16 SATA-Laufwerken (mit je 250 GByte) angeschafft und über zwei 2-Gbit/s-Schnittstellen ans SAN angeschlossen. Von den vier TByte Gesamtkapazität blieben nach Abzug der RAID-5-Parität in vier Gruppen zu 3+1 Laufwerken noch drei TByte nutzbarer Speicher übrig. Von den drei logischen Laufwerken zu jeweils einem TByte wurde eines einem Linux-Server und zwei für Windows-Systeme bereitgestellt. Das damalige Ziel war, dass der Speicherplatz auch bei einem übertrieben geschätzten Datenzuwachs für die nächsten fünf Jahre ausreicht.

Oftmals trügt die Einschätzung des künftigen Datenwachstums, daher ist es nicht verwunderlich, dass bereits nach wesentlich kürzerer Zeit zahlreiche Probleme auftauchen. In unserem Beispiel überschreitet der Füllgrad aller LUNs bereits wesentlich schneller als erwartet die 90-Prozent-Marke. Die Schnittstellen mit zwei Gbit/s sind nicht mehr Stand der Technik und die angegrauten Festplatten beginnen mehr und mehr ihre Dienste zu verweigern. Hinzu kommt, dass der RAID-5-Schutz nicht mehr den heutigen Möglichkeiten entspricht.

Die fehlenden Kapazitäten ließen sich leicht auf das Achtfache aufrüsten, wenn denn das alte Array 2-TByte-Platten unterstützen würde. Für diese Umrüstung müssten allerdings zuerst alle Daten auf Band evakuiert und dann auf die neuen Laufwerke zurückgespielt werden. Dies bringt auf jeden Fall eine längere Auszeit mit sich. Zudem unterstützt das alte Betriebssystem keinen RAID-6-Schutz, was bei Platten dieser Größe ein empfindliches Risiko bedeutet. Darüber hinaus will man sich alle Vorteile eines neuen 8-Gbit/s-SANs zunutze machen und diese Option steht im aktuellen System ebenfalls nicht mehr zur Verfügung. Letztlich bleibt dem IT-Administrator nur der Entschluss, ein komplett neues Disk-Subsystem anzuschaffen und im gleichen Zuge neue Konzepte für Backup, Archiv und ein Self-Service-Helpdesk einzuführen.

Speichermigration: viele Ansätze, ein Ziel

Datenmigration ist nicht ohne Grund einer der unbeliebtesten Begriffe in der EDV. Firmen geraten schnell in eine Zwickmühle, wenn sie sich nicht für ein und dieselbe Marke entscheiden und/oder die Hersteller kein entsprechendes Werkzeug zur Übertragung der Daten anbieten. Die produktive Arbeit darf nicht oder nur sehr kurz unterbrochen werden. Alle Daten sollen während der Migration möglichst im Zugriff bleiben und vielleicht sogar veränderbar sein. Die Leistung des Gesamtsystems soll nicht oder nur unmerklich beeinflusst werden. Weitere wichtige Anforderungen der IT-Abteilung an den Migrationsprozess sind ein gutes Preis-Leistungsverhältnis, geringer Personaleinsatz sowie eine zügige und zuverlässige Umsetzung.

Vor der Migration auf das neue System gilt es mehrere Fragen zu klären:

• Wie lange soll das Subsystem im Einsatz sein – drei, vier oder fünf Jahre?
• Wie ist die zu erwartende Gesamtbelegung – einschließlich Sicherheitspuffer – bis zum Laufzeitende des Systems?
• Wie viele Anwender und welche Anwendungen mit welcher Netzwerkanbindung nutzen den Speicher?
• Sollte das erste Backup und eine Archivfunktion ebenfalls implementiert sein?

Hieraus ergeben sich alle Parameter, nach denen das neue Gerät angeschafft werden kann.

Geht man davon aus, dass der Hersteller des neuen Disksystems nicht derselbe wie der des alten Gerätes ist, also keine internen Werkzeuge zur Migration bereitstehen, bieten sich drei Möglichkeiten. In unseren Betrachtungen gehen wir davon aus, dass die kleineren 1-TByte-Laufwerke »einfach« eine Verlagerung auf größere LUNs erfahren. Vielleicht kommen bei Anschaffung eines neuen Speichers mit der achtfachen Kapazität auch neue logische Laufwerke hinzu, meist wird der zusätzliche Platz jedoch für erweiterten logischen Schutz (RAID 6), Snapshots oder First-Level-Sicherungen genutzt. Die gleiche Laufwerksanzahl von 16 kann der Zuständige dann sinnvoll in zwei RAID-6-Gruppen mit jeweils 5+2 Laufwerken einteilen. Die restlichen beiden Platten dienen als Hotspare, springen also im Fehlerfall für ein defektes Laufwerk ein. Bei dieser Einteilung ergeben sich zehn TByte nutzbarer Speicher, also nicht die erwartete achtfache Kapazität. Richtet der EDV-Mann drei LUNs zu jeweils zwei TByte ein, bleiben noch vier TByte für Snapshot-Safeareas, Backups und neue logische Laufwerke. Diese vier TByte könnten auch als stille Reserve dienen, da doch immer mehr Daten anfallen als der Administrator in seinen schlimmsten Albträumen befürchtet. Das nächste Problem ist die unterbrechungsfreie und konsistente Übermittlung der Bestandsdaten auf das neue System.

Migration: Kopieren mit Betriebssystem

Die einfachste Methode zur Migration ist immer noch die Nutzung von im Betriebssystem vorhandenen Mitteln. Hierbei wird das neue Ziellaufwerk zusätzlich an den Server angeschlossen und alle dort vorhandenen Daten ohne Modifikation kopiert. Der große Vorteil ist, dass diese Migration von Personal ohne besondere Schulung und ohne weitere Hilfsmittel durchgeführt werden kann. Allerdings muss während des Kopiervorgangs jeglicher Zugriff auf die Daten unterbleiben, um Inkonsistenzen durch Änderungen während der Datenübertragung zu vermeiden. Die Betriebsunterbrechung beträgt somit in unserem Beispiel mindestens 30 Stunden, wenn man von einer durchschnittlichen Kopierrate von 25 MByte/s und einer Datenmenge von 2,7 TByte ausgeht. Nicht eingerechnet sind die Anbindung des Ziellaufwerks und die abschließenden Arbeiten, also das Abhängen der alten LUN, die Umbenennung des neuen Produktivlaufwerks und die entsprechenden Anpassungen im SAN. Hier können schnell 36 und mehr Stunden zusammenkommen, selbst wenn erfahrene Mitarbeiter jeden Handgriff sicher durchführen.

Migration via Dateisystem-Manager

Mit Hilfe von Dateisystem-Managern, wie beispielsweise dem Symantec »Veritas Volume Manager«, lassen sich Abbilder von Produktionslaufwerken auf anderer Hardware anlegen. Diese Abbilder werden transparent zur Produktion mit den entsprechenden Daten gefüllt; für deren Kopie ist keine Betriebsunterbrechung notwendig. Sind alle Daten übertragen, ändert der Dateisystem-Manager die Adressierung des neuen Laufwerks, so dass dieses gegenüber dem Betriebssystem so aussieht wie die LUN aus dem Altsystem. Alle Zugriffe gehen nun nur noch auf das neue Array, das alte kann abgeschaltet werden.

Diese Methode ist zwar elegant, jedoch ist es in den meisten Fällen sehr schwierig, einmal unter der Kontrolle eines Dateisystem-Managers befindliche Daten wieder in ein »normales« Laufwerk zu konvertieren. Hier hilft meist nur ein weiterer Kopiervorgang und dieser kostet dann wieder eine Auszeit, wodurch nichts gewonnen ist. Die alte Weisheit »einmal Volume-Manager, immer Volume-Manager« sollte bei aller Begeisterung über diese Methode nicht vergessen werden. Ebenso muss das Unternehmen natürlich die damit verbundenen Lizenz- und Wartungskosten einkalkulieren. Dazu gehört auch die Schulung des Personals, da diese Software nicht unkompliziert ist.

Virtualisierung aus dem Array

Hersteller wie zum Beispiel Hitachi Data Systems bieten die Option an, mit ihren Systemen selbst logische Laufwerke aus dem SAN anzubinden und so ohne Zwischenschalten eines Rechners Daten migrieren zu können. Dies ist die sauberste Methode, kommunizieren doch beide Speichersysteme direkt und ohne Vermittler miteinander. Alle Hersteller solcher Systeme haben für die Migration auch an eine transparente Änderung der Adressierung über das SAN, also der WWNs, gedacht. Sobald alle Daten migriert wurden, werden die weltweiten Nummern des oder der Ports und andere relevante Bezeichner des Altgeräts gegen die des neuen Subsystems getauscht, und ohne dass ein Rechner etwas bemerkt, findet die Produktion vom neuen Array aus statt.

Firmen müssen neben den offensichtlichen Vorteilen natürlich auch auf die Preise und vor allem den nicht unerheblichen Schulungsaufwand für das Personal achten. Die Methode der Virtualisierung aus dem Array bringt einen weiteren, nicht unerheblichen Vorteil mit sich: Durch den direkten Anschluss des Altsystems muss dieses nicht sofort entsorgt, sondern kann für andere Aufgaben wie eine VTL oder Testumgebungen genutzt werden.

Migration per Virtualisierung im SAN

Die neben dem Einsatz von Dateisystem-Managern ebenfalls neutrale Methode der Migration ist diejenige über SAN-Virtualisierungswerkzeuge. Hierbei übernimmt eine logische Schicht im Speichernetz, meist in einer Appliance, die Aufgabe, LUNs gegenüber den Rechnern zu abstrahieren. Hierbei ist es gleichgültig, welche Speichersysteme die Laufwerke bereit stellen, da deren Adressierung und damit der eigentliche Weg der Daten von der Appliance festgelegt werden. Diese verfügen auch über die Möglichkeit, Daten transparent zur Produktion auf neue Laufwerke zu kopieren und nach Erfolg die Adressierung der alten auf die neuen LUNs zu übertragen. Hierbei kann der Betrieb ohne Unterbrechung laufen.

Allerdings wandern in vielen Fällen die physikalischen Inhaltstabellen der Laufwerke, die Tracktabellen, aus den Speichersystemen in die Virtualisierungsschicht (In-Band-Virtualisierungen). Diese ist dann zum weiteren Betrieb der migrierten Laufwerke unbedingt notwendig und lässt sich nicht nach dem Datentransfer einfach wieder abschalten. Daneben existieren auch Lösungen, bei denen die Virtualisierungsschicht nur die Einstellungen des Speichernetzes, also die Verbindungen von Laufwerken zu Rechnern und deren Portadressierung beeinflussen und nicht direkt im Datenpfad sitzen (Out-of-Band). Diese lassen sich vor der Migration ein- und danach wieder ausschalten, ohne Einfluss auf die späteren Produktionslaufwerke zu nehmen. Diese sind daher für unser Szenario zu bevorzugen.

Die Einrichtung und Nutzung von SAN-Virtualisierung als Migrationswerkzeug ist nicht trivial. Daher ist hier der Aufwand zur Erlangung der notwendigen Routine nicht zu unterschätzen. Die SAN-Virtualisierung ist allerdings nicht preiswert und ihre Dauernutzung macht in kleineren und mittleren Umgebungen technisch wenig Sinn. Daher sollte sie erst als Migrationsmittel in Erwägung gezogen werden, wenn die drei anderen beschriebenen Möglichkeiten aus guten Gründen ausscheiden.

Migration: Ausfallzeit zugunsten der Sicherheit in Kauf nehmen

Die einfachste und preiswerteste Methode der Datenmigration ist und bleibt die Kopie mit Mitteln des Betriebssystems. Allerdings entsteht dabei leicht ein Ausfall von mehreren Tagen, da mit parallel stattfindender Produktion keine Konsistenz der Daten auf dem Ziellaufwerk sichergestellt werden kann. Hier müsste man also auf ein günstig gelegenes Weihnachtsfest oder andere Betriebspausen hoffen.

Alle anderen Wege, also Volumemanager oder irgendeine Art von Virtualisierung, erkaufen sich ihre Transparenz durch Komplexität und Preis. Wer das Geld für Produkte, Installation und Personalschulung in die Hand nehmen möchte, der bekommt die Möglichkeit, immer und vor allem ohne Einfluß auf die Produktion migrieren zu können. Je nach Wichtigkeit der EDV im eigenen Hause also vielleicht eine gute Investition.

Kommentare:

Kommentar schreiben