6 versteckte Engpässe bei der Migration von Cloud-Daten

Seth Noble ist Gründer und Präsident von Data Expedition.

Das Verschieben von Terabyte oder sogar Petabyte an Daten in die Cloud ist eine entmutigende Aufgabe. Es ist jedoch wichtig, über die Anzahl der Bytes hinauszuschauen. Sie wissen wahrscheinlich, dass sich Ihre Anwendungen beim Zugriff in der Cloud anders verhalten, dass die Kostenstrukturen unterschiedlich sind (hoffentlich besser) und dass das Verschieben all dieser Daten einige Zeit in Anspruch nimmt.

Da mein Unternehmen, Data Expedition, im Bereich der Hochleistungsdatenübertragung tätig ist, kommen Kunden zu uns, wenn sie erwarten, dass die Netzwerkgeschwindigkeit ein Problem darstellt. Bei der Unterstützung von Unternehmen bei der Überwindung dieses Problems haben wir jedoch viele andere Faktoren gesehen, die Cloud-Migrationen zu entgleisen drohen, wenn sie übersehen werden.

Das Sammeln, Organisieren, Formatieren und Validieren Ihrer Daten kann viel größere Herausforderungen darstellen als das Verschieben. In der Planungsphase einer Cloud-Migration sind einige wichtige Faktoren zu berücksichtigen, damit Sie später zeitaufwändige und teure Probleme vermeiden können.

Cloud-Migrationsengpass Nr. 1: Datenspeicherung

Der häufigste Fehler bei Cloud-Migrationen besteht darin, Daten in den Cloud-Speicher zu verschieben, ohne zu berücksichtigen, wie diese Daten verwendet werden. Der typische Denkprozess lautet: „Ich möchte meine Dokumente und Datenbanken in der Cloud ablegen, und die Objektspeicherung ist billig, daher werde ich meine Dokument- und Datenbankdateien dort ablegen.“ Dateien, Objekte und Datenbanken verhalten sich jedoch sehr unterschiedlich. Wenn Sie Ihre Bytes in die falsche Position bringen, können Ihre Cloud-Pläne lahmgelegt werden.

Dateien werden durch eine Hierarchie von Pfaden, einen Verzeichnisbaum, organisiert. Auf jede Datei kann schnell zugegriffen werden, mit minimaler Latenz (Zeit bis zum ersten Byte) und hoher Geschwindigkeit (Bits pro Sekunde, sobald die Daten fließen). Einzelne Dateien können einfach verschoben, umbenannt und auf Byte-Ebene geändert werden. Sie können viele kleine Dateien, eine kleine Anzahl großer Dateien oder eine beliebige Mischung aus Größen und Datentypen haben. Herkömmliche Anwendungen können wie in der Cloud auf Dateien in der Cloud zugreifen, ohne dass eine besondere Cloud-Kenntnis erforderlich ist.

All diese Vorteile machen dateibasierten Speicher zur teuersten Option, aber das Speichern von Dateien in der Cloud hat einige andere Nachteile. Um eine hohe Leistung zu erzielen, kann auf die meisten Cloud-basierten Dateisysteme (wie Amazon EBS) jeweils nur eine Cloud-basierte virtuelle Maschine zugreifen. Dies bedeutet, dass alle Anwendungen, die diese Daten benötigen, auf einer einzelnen Cloud-VM ausgeführt werden müssen. Um mehrere VMs (wie Azure-Dateien) bedienen zu können, muss der Speicher mit einem NAS-Protokoll (Network Attached Storage) wie SMB ausgestattet werden, was die Leistung erheblich beeinträchtigen kann. Dateisysteme sind schnell, flexibel und Legacy-kompatibel, aber sie sind teuer, nur für Anwendungen nützlich, die in der Cloud ausgeführt werden, und lassen sich nicht gut skalieren.

Objekte sind keine Dateien. Denken Sie daran, denn es ist leicht zu vergessen. Objekte leben in einem flachen Namespace wie einem riesigen Verzeichnis. Die Latenz ist hoch, manchmal Hunderte oder Tausende von Millisekunden, und der Durchsatz ist gering. Oft werden etwa 150 Megabit pro Sekunde erreicht, sofern keine cleveren Tricks angewendet werden. Viel über den Zugriff auf Objekte hängt von cleveren Tricks wie dem Hochladen mehrerer Teile, dem Zugriff auf den Bytebereich und der Optimierung von Schlüsselnamen ab. Objekte können von vielen Cloud-nativen und webbasierten Anwendungen gleichzeitig sowohl innerhalb als auch außerhalb der Cloud gelesen werden. Herkömmliche Anwendungen erfordern jedoch leistungsbeeinträchtigende Problemumgehungen. Bei den meisten Schnittstellen für den Zugriff auf den Objektspeicher sehen Objekte wie Dateien aus: Schlüsselnamen werden nach Präfix gefiltert, um wie Ordner auszusehen. Benutzerdefinierte Metadaten werden an Objekte angehängt, die wie Dateimetadaten aussehen.und einige Systeme wie FUSE-Cache-Objekte in einem VM-Dateisystem, um den Zugriff durch herkömmliche Anwendungen zu ermöglichen. Solche Problemumgehungen sind jedoch spröde und saftig. Cloud-Speicher ist billig, skalierbar und Cloud-nativ, aber auch langsam und schwer zugänglich.

Datenbanken haben ihre eigene komplexe Struktur und werden von Abfragesprachen wie SQL aufgerufen. Herkömmliche Datenbanken können durch Dateispeicherung gesichert werden, erfordern jedoch einen Live-Datenbankprozess, um Abfragen zu bearbeiten. Dies kann in die Cloud übertragen werden, indem die Datenbankdateien und -anwendungen auf eine VM kopiert oder die Daten in einen in der Cloud gehosteten Datenbankdienst migriert werden. Das Kopieren einer Datenbankdatei in den Objektspeicher ist jedoch nur als Offline-Sicherung nützlich. Datenbanken lassen sich gut als Teil eines in der Cloud gehosteten Dienstes skalieren. Es ist jedoch wichtig sicherzustellen, dass die von der Datenbank abhängigen Anwendungen und Prozesse vollständig kompatibel und Cloud-nativ sind. Der Datenbankspeicher ist hochspezialisiert und anwendungsspezifisch.

Um die offensichtlichen Kosteneinsparungen bei der Objektspeicherung gegen die Funktionalität von Dateien und Datenbanken abzuwägen, muss sorgfältig überlegt werden, welche Funktionalität genau erforderlich ist. Wenn Sie beispielsweise viele tausend kleine Dateien speichern und verteilen möchten, archivieren Sie sie in einer ZIP-Datei und speichern Sie diese als einzelnes Objekt, anstatt zu versuchen, jede einzelne Datei als separates Objekt zu speichern. Eine falsche Speicherauswahl kann zu komplexen Abhängigkeiten führen, deren spätere Änderung schwierig und teuer ist.

Cloud-Migrationsengpass Nr. 2: Datenvorbereitung

Das Verschieben von Daten in die Cloud ist nicht so einfach wie das Kopieren von Bytes in den angegebenen Speichertyp. Bevor etwas kopiert wird, müssen viele Vorbereitungen getroffen werden, und diese Zeit erfordert eine sorgfältige Budgetierung. Proof-of-Concept-Projekte ignorieren diesen Schritt häufig, was später zu kostspieligen Überschreitungen führen kann.

Das Herausfiltern unnötiger Daten kann viel Zeit und Speicherkosten sparen. Ein Datensatz kann beispielsweise Sicherungen, frühere Versionen oder Arbeitsdateien enthalten, die nicht Teil des Cloud-Workflows sein müssen. Der vielleicht wichtigste Teil der Filterung besteht darin, zu priorisieren, welche Daten zuerst verschoben werden müssen. Daten, die aktiv verwendet werden, tolerieren nicht, dass sie in den Wochen, Monaten oder Jahren, die für den Abschluss des gesamten Migrationsprozesses erforderlich sind, nicht synchron sind. Der Schlüssel hier ist, ein automatisiertes Mittel zu finden, um auszuwählen, welche Daten wann gesendet werden sollen, und dann sorgfältige Aufzeichnungen über alles zu führen, was getan wird und was nicht.

Unterschiedliche Cloud-Workflows erfordern möglicherweise, dass die Daten in einem anderen Format oder einer anderen Organisation vorliegen als lokale Anwendungen. Für einen legalen Workflow müssen beispielsweise möglicherweise Tausende kleiner Word- oder PDF-Dokumente übersetzt und in ZIP-Dateien gepackt werden. In einem Medienworkflow werden möglicherweise Transcodierungen und Metadaten gepackt, und für einen Bioinformatik-Workflow müssen möglicherweise Terabyte Genomdaten ausgewählt und bereitgestellt werden. Eine solche Neuformatierung kann ein sehr manueller und zeitaufwändiger Prozess sein. Es kann viel Experimentieren, viel temporären Speicher und viel Ausnahmebehandlung erfordern. Manchmal ist es verlockend, eine Neuformatierung in die Cloud-Umgebung zu verschieben. Denken Sie jedoch daran, dass dies das Problem nicht löst, sondern nur in eine Umgebung verschiebt, in der jede von Ihnen verwendete Ressource einen Preis hat.

Ein Teil der Speicher- und Formatierungsfragen kann Entscheidungen über Komprimierung und Archivierung beinhalten. Zum Beispiel ist es sinnvoll, Millionen kleiner Textdateien vor dem Senden an die Cloud zu komprimieren, aber nicht eine Handvoll Mediendateien mit mehreren Gigabyte. Das Archivieren und Komprimieren von Daten erleichtert das Übertragen und Speichern der Daten. Berücksichtigen Sie jedoch die Zeit und den Speicherplatz, die zum Packen und Entpacken dieser Archive an beiden Enden erforderlich sind.

Engpass bei der Cloud-Migration Nr. 3: Validierung von Informationen

Die Integritätsprüfung ist der wichtigste Schritt und auch der am einfachsten zu verwechselnde. Oft wird davon ausgegangen, dass während des Datentransports eine Beschädigung auftritt, sei es durch physische Medien oder durch Netzwerkübertragung, und dass vorher und nachher Prüfsummen durchgeführt werden können. Prüfsummen sind ein wesentlicher Bestandteil des Prozesses, aber es ist tatsächlich die Vorbereitung und der Import der Daten, bei denen Sie am wahrscheinlichsten Verluste oder Korruption erleiden.

Wenn Daten Formate und Anwendungen verschieben, können Bedeutung und Funktionalität verloren gehen, selbst wenn die Bytes gleich sind. Eine einfache Inkompatibilität zwischen Softwareversionen kann Petabytes „korrekter“ Daten unbrauchbar machen. Es kann eine entmutigende Aufgabe sein, einen skalierbaren Prozess zu entwickeln, um zu überprüfen, ob Ihre Daten korrekt und verwendbar sind. Im schlimmsten Fall kann es zu einem arbeitsintensiven und ungenauen manuellen Prozess kommen: „Für mich sieht es in Ordnung aus.“ Aber auch das ist besser als gar keine Validierung. Das Wichtigste ist, dass Sie Probleme erkennen können, bevor die Legacy-Systeme außer Betrieb genommen werden!

Cloud-Migrationsengpass Nr. 4: Transfer-Marshalling

Wenn Sie ein einzelnes System in die Cloud heben, ist es relativ einfach, die vorbereiteten Daten einfach auf physische Medien zu kopieren oder über das Internet zu übertragen. Dieser Prozess kann jedoch schwierig zu skalieren sein, insbesondere für physische Medien. Was in einem Proof-of-Concept „einfach“ erscheint, kann zu einem „Albtraum“ werden, wenn viele und unterschiedliche Systeme ins Spiel kommen.

An jedes Gerät muss ein Mediengerät wie ein AWS-Schneeball angeschlossen sein. Dies kann bedeuten, dass Sie das Gerät physisch durch ein oder mehrere Rechenzentren führen, Konnektoren jonglieren, Treiber aktualisieren und Software installieren. Das Herstellen einer Verbindung über das lokale Netzwerk erspart die physische Bewegung, aber das Software-Setup kann immer noch schwierig sein und die Kopiergeschwindigkeit kann weit unter das fallen, was mit einem direkten Internet-Upload erreicht werden könnte. Das direkte Übertragen der Daten von jedem Computer über das Internet spart viele Schritte, insbesondere wenn die Daten Cloud-fähig sind.

Wenn die Datenvorbereitung das Kopieren, Exportieren, Neuformatieren oder Archivieren umfasst, kann die lokale Speicherung zu einem Engpass werden. Möglicherweise muss ein dedizierter Speicher eingerichtet werden, um die vorbereiteten Daten bereitzustellen. Dies hat den Vorteil, dass viele Systeme die Vorbereitung parallel durchführen können, und reduziert die Kontaktpunkte für versendbare Medien und Datenübertragungssoftware auf nur ein System.

Cloud-Migrationsengpass Nr. 5: Datenübertragung

Wenn Sie die Netzwerkübertragung mit der Mediensendung vergleichen, können Sie sich ganz einfach auf die Versandzeit konzentrieren. Beispielsweise kann ein 80-Terabyte-AWS-Schneeballgerät per Kurierdienst am nächsten Tag gesendet werden, wodurch eine scheinbare Datenrate von mehr als acht Gigabit pro Sekunde erreicht wird. Dies ignoriert jedoch die Zeit, die erforderlich ist, um das Gerät zu erwerben, zu konfigurieren und zu laden, es für die Rückgabe vorzubereiten und dem Cloud-Anbieter zu ermöglichen, die Daten im Back-End zu kopieren. Kunden von uns, die dies regelmäßig tun, berichten, dass vierwöchige Durchlaufzeiten (von der Gerätebestellung bis zu in der Cloud verfügbaren Daten) häufig sind. Dadurch wird die tatsächliche Datenübertragungsrate beim Versand des Geräts auf nur 300 Megabit pro Sekunde gesenkt, viel weniger, wenn das Gerät nicht vollständig gefüllt ist.

Die Netzwerkübertragungsgeschwindigkeiten hängen ebenfalls von einer Reihe von Faktoren ab, vor allem von der lokalen Aufwärtsverbindung. Sie können Daten nicht schneller als die physische Bitrate senden, obwohl eine sorgfältige Datenvorbereitung die zu sendende Datenmenge reduzieren kann. Ältere Protokolle, einschließlich solcher, die Cloud-Anbieter standardmäßig für die Objektspeicherung verwenden, haben Schwierigkeiten mit der Geschwindigkeit und Zuverlässigkeit über Internet-Fernpfade, was das Erreichen dieser Bitrate erschweren kann. Ich könnte viele Artikel über die Herausforderungen schreiben, die hier auftreten, aber diesen müssen Sie nicht selbst lösen. Data Expedition ist eines der wenigen Unternehmen, das sich darauf spezialisiert hat, sicherzustellen, dass der Pfad vollständig genutzt wird, unabhängig davon, wie weit Ihre Daten vom Cloud-Ziel entfernt sind. Beispielsweise liefert eine Gigabit-Internetverbindung mit Beschleunigungssoftware wie CloudDat 900 Megabit pro Sekunde.dreimal so hoch wie der Nettodurchsatz eines AWS-Schneeballs.

Der größte Unterschied zwischen physischem Versand und Netzwerkübertragung ist auch einer der am häufigsten beim Proof-of-Concept übersehenen. Beim physischen Versand muss das erste Byte, das Sie auf das Gerät laden, warten, bis das letzte Byte geladen ist, bevor Sie versenden können. Wenn das Laden des Geräts Wochen dauert, sind einige Ihrer Daten zum Zeitpunkt des Eintreffens in die Cloud Wochen veraltet. Selbst wenn Datensätze das Petabyte-Niveau erreichen, bei dem der physische Versand insgesamt schneller sein kann, kann die Möglichkeit, Prioritätsdaten während des Migrationsprozesses auf dem neuesten Stand zu halten, die Netzwerkübertragung für wichtige Assets begünstigen. Eine sorgfältige Planung während der Filter- und Priorisierungsphase der Datenaufbereitung ist unerlässlich und kann einen hybriden Ansatz ermöglichen.

Das Abrufen der Daten in einen Cloud-Anbieter ist möglicherweise nicht das Ende des Datenübertragungsschritts. Wenn es auf mehrere Regionen oder Anbieter repliziert werden muss, planen Sie sorgfältig, wie es dort ankommt. Das Hochladen über das Internet ist kostenlos, während AWS beispielsweise bis zu zwei Cent pro Gigabyte für die interregionale Datenübertragung und neun Cent pro Gigabyte für die Übertragung an andere Cloud-Anbieter berechnet. Beide Methoden sind mit Bandbreitenbeschränkungen konfrontiert, die von einer Transportbeschleunigung wie CloudDat profitieren könnten.

Engpass bei der Cloud-Migration Nr. 6: Cloud-Skalierung

Sobald die Daten an ihrem Ziel in der Cloud ankommen, ist der Migrationsprozess nur zur Hälfte abgeschlossen. Prüfsummen stehen an erster Stelle: Stellen Sie sicher, dass die eingehenden Bytes mit den gesendeten übereinstimmen. Dies kann schwieriger sein, als Sie vielleicht denken. Der Dateispeicher verwendet Schichten von Caches, die die Beschädigung von Daten, die gerade hochgeladen wurden, verbergen können. Eine solche Beschädigung ist selten, aber bis Sie alle Caches geleert und die Dateien erneut gelesen haben, können Sie sich keiner Prüfsummen sicher sein. Durch einen Neustart der Instanz oder das Aufheben der Bereitstellung des Speichers werden Caches toleriert.

Um die Prüfsummen für die Objektspeicherung zu überprüfen, muss jedes Objekt zur Berechnung in eine Instanz eingelesen werden. Entgegen der landläufigen Meinung sind Objekt-E-Tags als Prüfsummen nicht nützlich. Insbesondere Objekte, die mit mehrteiligen Techniken hochgeladen wurden, können nur durch erneutes Auslesen validiert werden.