Manchmal steckt der Teufel wirklich im Detail Δфلה – Sonderzeichen sind unterschätzte Fehlerquellen bei Migrationen

Ein scheinbar banales Problem bei Migrationen unterschiedlicher Netzwerkprotokolle mit unter Umständen großen Folgen: Sonderzeichen.

Anbieter zum Thema

PoINT Software & Systems GmbH

DataCore Software GmbH

Fujitsu Technology Solutions GmbH

Datenmigrationen sind in vielen Unternehmen eine unterschätzte Pflichtaufgabe. Geschäftsführungen sehen hier im besten Falle ein handwerkliches Problem und den großen Zeitbedarf und erkennen kaum, welche Erfahrung, Fachwissen und spezielle Lösungen dafür nötig sind. Dabei steigt gerade mit der Komplexität der Systeme die Notwendigkeit, jeden einzelnen Schritt genau zu planen und seine Folgen für die Integrität von Daten und den Ablauf von Prozessen durchzudenken. Denn kleine Dinge haben große Wirkung: Auch heute können Migrationen schon an banalen Sonderzeichen im Dateinamen scheitern. Denn vom Mainframe bis hin zur heutigen Generation moderner Rechner haben sich Zeichensätze weiterentwickelt, so dass jedes Legacy-Sonderzeichen neu zu übersetzen ist.

Auf der Zeitleiste der Zeichensätze

Mainframe kannte über ASCII gerade einmal 127 Zeichen. Selbst die Umlaute einiger auf dem römischen Alphabet aufbauenden europäischen Sprachen hielten hier erst mit ANSI/437 (DOS/alte Unix-Systeme) Einzug. ISO8859-X (Windows 3.1 – Windows 98/Windows NT 3.5) umfasste fünfzehn verschiedene Zeichensätze, bei denen die herkömmlichen Buchstaben und Zahlen in allen Varianten identisch waren. Die zweite Hälfte lieferte jedoch jeweils Sonderzeichen aus verschiedenen Sprachkreisen – etwa für Griechisch, Thai oder Japanisch. Ohne Umwege aus dem Vollen schöpfen können die Rechner erst mit UTF-8/Unicode (Windows NT 4.0 und höher/Unix/NAS), das Zeichen mit ein bis vier Bytes darstellt. Seitdem stehen über eine Million Zeichen bereit.

Viele Daten wurden zu Beginn der Vernetzung erzeugt und mit der Zeit auf neue Generationen von File-Servern migriert. Auf dem Weg bis zum heutigen UTF-8 hat sich daher einiges getan, was nun zu Problemen bei weiteren Migrationen führen kann. Alte DOS- oder Windows-Versionen verwenden ANSI oder ISO8859-X. Dies stellt in der Regel kein Problem dar, da die Umlauteinstellung bei der Netzwerkverbindung ausgehandelt wird. Diese Versionen finden sich zudem vor allem auf Steuerrechnern für Produktionsroboter, die das Umlautproblem ohnehin kaum kennen. Auch bei modernen Windows-Versionen gibt es seltener Probleme, weil diese für jede Applikation durchgehend Unicode verwenden.

Die sich wandelnde Darstellung von Dateinamen kann für Probleme sorgen

Dateinamen mit Umlaut sorgen aber mit dem Lauf der Zeit für Probleme. Ein hexadezimaler Wert kann beispielsweise auf Rechnern mit verschiedenen Zeichensätzen unterschiedliche Buchstaben darstellen. Ein Rechner, der als ISO 8859-1, also für westlich lateinische Schriftzeichen, konfiguriert war, schrieb auf dem Fileserver ein „ä“ (hex E4). Wurde diese Datei später von einem Rechner unter ISO 8859-7, also mit griechischen Schriftzeichen, gelesen, wurde der gleiche Hex-Wert E4 als „δ“ interpretiert und dargestellt. Wird diese Datei aber dann beispielsweise von einem Rechner mit ISO 8859-7 mit Konversion unter UTF-8 auf ein neues Ziel geschrieben, verschwindet das ursprüngliche „ä“ vollkommen, weil E4 in Unicode keinen gültigen Buchstaben repräsentiert. So können verschiedene Zeichensätze gegebene Dateinamen falsch wiedergeben. Im schlimmsten Fall sind diese Dateinamen dann für andere Rechner sogar unlesbar. Das Problem hat größere Ausmaße, als man denkt, und betrifft rund 400 Sonderzeichen aus unterschiedlichen Sprachkreisen.

Bei der Migration führt kein Weg daran vorbei, diese unerwünschte „Übersetzungstätigkeit“ zu berücksichtigen. Automatisch von NFSv3 auf NFSv4, das immer in UTF8 arbeitet, zu konvertieren, ist kaum möglich. In jedem Fall stehen die Migrationsexperten vor der Aufgabe, gegebene Datenbestände genau zu analysieren. Außerdem sehen sie sich gezwungen, die Dateien hostbasiert, also jede Datei für sich, zu kopieren. Das ist nicht nur aufwändig, sondern verlängert die Offlinezeit im Rahmen der Migration deutlich.

Unix-Clients können verschiedene Protokolle nutzen

Darüber hinaus gibt es ein weiteres Problem, das mit den verschiedenen Protokollen auf Unix-Clients zusammenhängt. Windows arbeitet schon seit mehr als zehn Jahren nur noch mit Unicode und stellt den zu übertragenden Dateinamen im SMB-Protokoll über Unicode dar. Vorhandene Dateinamen lassen sich daher nicht übertragen und müssen schon vorher in Unicode konvertiert worden sein. Unter NFSv4 spielt nun der Client keine Rolle mehr: NFSv4 zwingt den Client, den Dateinamen in UTF8 zu übertragen. So verstehen sich Client und File-Server, und es kann nicht mehr viel schiefgehen.

Unter NFSv3 herrschen dagegen noch völlig ungeordnete Verhältnisse. Nutzer können hier bei einem Unix-Client je nach Terminal verschiedene Codepages nutzen. Damit schreiben sie unter Umständen Dateinamen unterschiedlicher Codierungen auf ein und denselben Fileserver. So können im Directory zwei unterschiedliche Dateien mit scheinbar identischen Dateinamen vorkommen: beide vom gleichen Client geschrieben, jedoch aus unterschiedlichen Terminals und mit verschiedenen Codepages.

Storage für große Datenmengen

Eine Herausforderung für Speichersysteme: Big Data

Protokollarische Differenzen unter NFSv3

Beim Nutzen eines File-Servers, der Multiprotokoll anbietet, können außerdem invalide UTF-8-Sequenzen entstehen. Ein Beispiel: Ein Unix-Client mit NFSv3 ist mit UTF-8 konfiguriert. Der Dateiname „Report_März.txt“ wird beim Schreiben auf ein NAS, welches eine Codierung in ISO-8859-1 erwartet, beim Konvertieren in UTF-8 jedoch falsch interpretiert. Jeder andere Unix-Client mit NFSv3 würde zwar trotz dieser Fehlkonfiguration auch „Report_März.txt“ lesen. Ein mit NFSv4 konfigurierter Client sieht liest jedoch „Report_März.txt“. Die Datei ist dann zwar nicht korrupt und kann weiterhin gelesen werden. Aber nach einer Migration auf den neuen Server wird die Datei „Report_März“ kaum noch über die Suchfunktion eines Windows-Rechners gefunden, weil sie unter diesem korrekten Dateinamen nicht mehr existiert.

Der Versuch, solche Dateinamen zu reparieren, wächst sich schnell zu einem wenig erfreulichen Ratespiel aus, da man natürlich nicht mehr nachvollziehen kann, wann und warum der Dateiname beim Konvertieren falsch interpretiert wurde. Im Rahmen einer Migration lassen sich Dateien zumindest gewissen Unternehmensbereichen und den dort verwendeten Protokollen zuordnen. Für deutsche Standorte kann man in der Regel davon ausgehen, dass der ISO 8859-1-Zeichenssatz verwendet wurde. Auch kann man prüfen, ob auf dem Fileserver die Konvertierung eingeschaltet war. So kann man zumindest das Verhalten nachvollziehen und nach entsprechende Fehlkonfigurationen suchen.

Berücksichtigt man die Einstellungen am Fileserver beim Planen einer Migration und damit potenzielle Fehler beim Konvertieren von Dateinamen, dann lassen sich diese über einen Algorithmus zur Verifikation aufdecken. Die als fehleranfällig identifizierten Dateinamen sind anschließend jedoch manuell auf der Quelle umzubenennen. Prinzipiell sollten die Verantwortlichen bei einer Migration im Vorfeld erkannte Umlautproblematiken bereits quellseitig bereinigen. Dies ermöglicht anschließend eine saubere Migration ohne Fehler in den Logfiles.

Fazit

Die Migration unstrukturierter Daten ist an sich eine komplexe Aufgabe mit vielen Fallstricken, die professionelle Analyse, Planung und Umsetzung erfordert. Datenbestände auf einem NAS sind meist historisch gewachsen und wurden mit unterschiedlichen Protokollen geschrieben oder konvertiert. Sonderzeichen, wie die im deutschen Sprachraum üblichen Umlaute, bereiten hier oft Probleme. Ohne das Wissen und die Erfahrung, wo welche Fehler auftreten können, kommen viele IT-Teams schnell an ihre Grenzen. Wer umfangreiche Migrationsprojekte plant, sollte sich im Vorfeld von Daten- und Migrationsexperten beraten lassen. Diese Spezialisten bauen auf ihre jahrzehntelange Expertise und können Schwierigkeiten schon vor der eigentlichen Migration erkennen.

*Der Autor: Ralf Draeger, Mitgründer und Technischer Leiter bei dynamigs.net.

Aktuelles eBook

Storage-Management

Teil 1: Immer den Überblick behalten

Ab einer gewissen Größe ist für Unternehmen das Storage-Management unerlässlich. Es optimiert durch geeignete Strategien und technische sowie organisatorische Maßnahmen die Effizienz und Leistungsfähigkeit der heterogenen Speicherlandschaft.

Dieses eBook behandelt unter anderem die folgenden Themen:

• Was ist Storage-Management?
• Nahe Verwandte des Speichermanagements
• Der Status quo der Storage-Systeme

eBook „Storage-Management“ kostenlos downloaden

(ID:48034495)