ADMIN

2022

02

2022-01-30T12:00:00

Cloudmanagement

SCHWERPUNKT

070

Datenmigration

Cloud

Datenmigration in die Cloud

Umziehen für Profis

von Norbert Deuschle

Veröffentlicht in Ausgabe 02/2022 - SCHWERPUNKT

Viele Unternehmen betreiben kritische Anwendungen in gewachsenen IT-Infrastrukturen noch selbst – aus Gründen der Compliance, Sicherheit oder anderer Vorgaben. Allerdings fällt eine durchgehende Digitalisierung mit nicht cloudbasierten Applikationsumgebungen schwer. Diese Anwendungen in die Cloud umzuziehen, kann hier für Vereinheitlichung sorgen. Wir beleuchten, auf welche Punkte IT-Verantwortliche bei Migrationsprojekten in die Cloud primär achten sollten.

Cloudmigration impliziert die Verlagerung von Daten, Workloads oder kompletten Anwendungen in eine öffentliche oder private Cloud. Dazu gehören Entscheidungen darüber, wie die Cloud nach Abschluss der Migration gewartet, optimiert, betrieben und verwaltet werden soll. Aufgrund der Umstellung von einem CAPEX- auf ein OPEX-Modell öffnen sich mehr Budget-Spielräume für geschäftskritische Initiativen und Innovationen, die sonst für den Betrieb einer aufwendigen, kaum skalierbaren Legacy-IT-Infrastruktur aufzubringen wären. Die Cloud kann die IT-Abteilung zudem von operativen Aufgaben entlasten.
Wahl des Betriebsmodells
Generell gilt: Nicht jedes Workload-Profil passt zu jeder Cloudplattform. Deshalb ist die Kenntnis über zu migrierende Daten – Stichwort Klassifikation – und eine fundierte Bewertung der in Frage kommenden Anwendungen sowie Arbeitslasten die zentrale Voraussetzung für den späteren Erfolg.
In einer privaten Cloud ist die IT-Infrastruktur durch die Unternehmensvorgabe bestimmt, Speicher-, Compute- und Netzwerkressourcen lassen sich individuell gestalten. Dies erlaubt das jeweils notwendige Maß an Kontrolle und Sicherheit, angepasst an eigene Applikations- und Compliance-Anforderungen. Abhängig von den eingesetzten Workloads kann eine private Cloud zudem größere Kosteneinsparungen liefern als eine reine Public-Cloud-Nutzung.
Cloudmigration impliziert die Verlagerung von Daten, Workloads oder kompletten Anwendungen in eine öffentliche oder private Cloud. Dazu gehören Entscheidungen darüber, wie die Cloud nach Abschluss der Migration gewartet, optimiert, betrieben und verwaltet werden soll. Aufgrund der Umstellung von einem CAPEX- auf ein OPEX-Modell öffnen sich mehr Budget-Spielräume für geschäftskritische Initiativen und Innovationen, die sonst für den Betrieb einer aufwendigen, kaum skalierbaren Legacy-IT-Infrastruktur aufzubringen wären. Die Cloud kann die IT-Abteilung zudem von operativen Aufgaben entlasten.
Wahl des Betriebsmodells
Generell gilt: Nicht jedes Workload-Profil passt zu jeder Cloudplattform. Deshalb ist die Kenntnis über zu migrierende Daten – Stichwort Klassifikation – und eine fundierte Bewertung der in Frage kommenden Anwendungen sowie Arbeitslasten die zentrale Voraussetzung für den späteren Erfolg.
In einer privaten Cloud ist die IT-Infrastruktur durch die Unternehmensvorgabe bestimmt, Speicher-, Compute- und Netzwerkressourcen lassen sich individuell gestalten. Dies erlaubt das jeweils notwendige Maß an Kontrolle und Sicherheit, angepasst an eigene Applikations- und Compliance-Anforderungen. Abhängig von den eingesetzten Workloads kann eine private Cloud zudem größere Kosteneinsparungen liefern als eine reine Public-Cloud-Nutzung.
In einer öffentlichen Cloud wird die Infrastruktur von vielen Unternehmen gemeinsam genutzt und von einem Anbieter bereitgestellt. Da die Ressourcen ganz nach Bedarf und "pay-as-you-use" nach oben oder unten skalierbar sind, lassen sich Lastspitzen bei schwierig zu planenden Workloads abfedern und die Kosten sind aufgrund des nutzungsabhängigen Charakters fast immer transparent. Mit Angeboten wie AWS Outposts lässt sich eine Hyperscale-Cloud sogar innerhalb des lokalen Rechenzentrums auf Basis eigener Hardware betreiben, ebenso wie eine private VMware-Cloud unter AWS.
Ein weiteres Modell stellt die Hybrid Cloud dar, die sowohl öffentliche als auch private Cloudumgebungen miteinander verbindet. Sie kombiniert die Kontrollmöglichkeiten einer individuell angepassten Private Cloud für geschäftskritische Ressourcen mit sensiblen Daten und die Agilität sowie Kosteneffizienz von Public Clouds für weniger kritische Anwendungen sowie Daten.
Multi-Cloud-Architekturen schließlich fassen mehrere Clouds zusammen. Ein On-Premises-Rechenzentrum und private Cloudimplementierungen lassen sich mit Hyperscale-Angeboten wie AWS, Microsoft Azure oder Google Cloud Platform kombinieren. Dazu können SaaS-Applikationen wie Backup-as-a-Service oder auch Co-Location-Angebote innerhalb einer Multicloud betrieben werden. Die laufenden Kosten aufgrund der Nutzung von unterschiedlichen Schnittstellen und Technologien sowie vertragsrechtliche Implikationen fallen hier meist höher aus; auch sind Multiclouds je nach Umfang komplexer zu betreiben als hybride Cloudumgebungen.
Kriterien für eine Migrationsstrategie
Vor der Migration von Daten und Anwendungen sollte es gängige Praxis sein, mit einer Bewertung des Ist-Zustands für die sogenannte "Cloud-Readiness" zu beginnen. Dabei gilt es, im Rahmen der zu migrierenden Umgebung die geschäftlichen Anforderungen und Schwerpunkte zu untersuchen. Die Prüfung schließt Daten, sicherheitstechnische und rechtliche Implikationen, die bereits vorhandene lokale und Cloudinfrastruktur, Anwendungen und deren Abhängigkeiten ein. Diese Analyse von unternehmenskritischen Abläufen und vorhandenen beziehungsweise noch notwendigen Ressourcen bildet die Grundlage der Strategie für die Cloudmigration.
Der erste Schritt bei einer Migration ist die Auswahl von Workloads. IT-Verantwortliche bestimmen an dieser Stelle, was überhaupt migriert werden soll, also welche Anwendungen, Prozesse und Infrastrukturen. Dies ist besonders für Analyse- und Big-Data-Workloads von Bedeutung, um performanceseitige Belange wie Speicher-I/O- und Netzwerklatenz sowie das Datenvolumen möglichst korrekt abzubilden. Bei einem sehr umfangreichen Projekt können die Zeit und der Faktor Mensch kritische Faktoren sein. Deshalb ist es üblich, mit einer überschaubaren Anzahl an Arbeitslasten zu beginnen und erst später zu komplexeren Workloads überzugehen.
Anwendungsprofile sind hilfreich, um detailliertere Informationen über Workloads zu bekommen. Um diese für eine Cloudmigration zu bewerten und zu priorisieren, empfehlen sich mehrere Schritte. An erster Stelle steht der Check einer bestehenden Umgebung in Bezug auf Rechenbedarf, Antwortzeiten und andere für den Geschäftsbetrieb wichtige Leistungswerte. Auf diese Weise lassen sich praxisbezogene Parameter definieren und KPIs für die neue Plattform entwickeln.
Das Monitoring von Arbeitslasten zu virtuellen Serverkonfigurationen, der Speicherauslastung, von Daten- und Anwendungsabhängigkeiten sowie spezifischer Benutzeranforderungen sind weitere Schritte. Sie definieren die Anforderungen für die Auswahl der richtigen Cloudplattform zur Unterstützung der jeweiligen Umgebung.
Auf dieser Grundlage lassen sich dann die relevanten Arbeitslasten in der Reihenfolge der Migrationskomplexität priorisieren – also welche Workloads sind leicht migrierbar, ohne dass Re-Factoring oder Re-Plattform (siehe Kasten "Migrationsstrategien") als weitere Aktionen für die Migration nötig werden.
Migrationsstrategien
- Replatforming: Die zugrundeliegende Architektur zwischen Cloud und On-Premises bleibt unverändert, Systeme wie Datenbanken oder Betriebssysteme ändern sich aber. Bei dieser Strategie sind meist nur wenige Änderungen erforderlich, um messbare Vorteile zu erzielen, da die vorhandenen Anwendungen lediglich eine Optimierung erfahren.- Refactoring: Bei diesem Prozess werden Anwendungen in die Clouinfrastruktur verschoben und gleichzeitig neu strukturiert, um sie besser an die Cloudumgebung anzupassen. Dieser Ansatz ist zeit- und ressourcenintensiv, kann jedoch die höchsten Ersparnisse erzielen, sobald die modifizierten Workloads in der Cloud laufen.- Refactoring plus Neuentwicklung: Hybride Migrationsstrategien haben zum Ziel, bestimmte Teile von Anwendungen in die Cloud zu migrieren, während andere Bereiche davon in der bestehenden Umgebung verbleiben. So lässt sich etwa eine monolithische Anwendung weiterhin intern hosten, während die Datenbank in die Cloud umzieht, wo sie mit NoSQL-Optionen als Funktionserweiterung eine höhere Performance erreicht oder weitere Vorteile cloudbasierter KI-Analysetools nutzen kann. Mit dieser Methode lassen sich monolithische Anwendungen über die Zeit je nach Anforderung sukzessive erweitern, modernisieren und in die Cloud verlagern.- Rehosting: Diese Strategie ist beliebt, um Anwendungen zu migrieren, da sie relativ einfach und schnell umzusetzen ist – auch als "Lift-and-Shift" bezeichnet. Sie ist für breit angelegte Legacy-Migrationsszenarien geeignet, bei denen es gilt, die Geschäftsziele schnell zu erreichen. Dieser Ansatz erfordert die wenigsten Änderungen an Arbeitslasten und Prozessen. Ein Rehosting lässt sich mit den von den Cloudanbietern zur Verfügung gestellten Tools automatisieren, schränkt jedoch die Möglichkeiten von cloudnativen Deployments ein.- Replacement: Legacy-Komponenten werden komplett durch eine cloudbasierte Architektur ersetzt. Dies beschleunigt den Weg in die Cloud, erfordert aber die genaue Analyse, welche Daten von einem System zum anderen umziehen sollen und welche nicht. Der Ansatz impliziert zudem ein höheres Risiko, falls unerwartete Probleme auftreten..
Daten- und Anwendungsanalyse
Die Entscheidung, welche Daten und Applikationen in die Cloud wandern sollen, fällt schwer, wenn keine aktuellen, realistischen Werte zu Last- und Zugriffsprofilen, Kapazitäten, Sicherheitsanforderungen et cetera dokumentiert sind. Der Prozess der Migration beginnt deshalb wie bereits erwähnt mit einer Bestandsaufnahme und Bewertung aller Daten im Betrieb, wobei die IT-Entscheider diejenigen Ressourcen ermitteln und priorisieren sollten, die am vorteilhaftesten zu migrieren sind. Dabei sind neben den Leistungs- und Sicherheitsanforderungen auch ihre Interoperabilität mit lokalen Systemen oder bereits bestehenden cloudbasierten Anwendungen zu berücksichtigen.
Auf immer mehr Daten wird immer weniger zugegriffen. Es ist in diesem Zusammenhang sinnvoll, die Konsolidierung von Flash, hochkapazitativen Festplatten und Bändern zu einer mehrstufigen, einheitlich zu verwaltenden Architektur unter Einbeziehung von Cloudspeichern in Betracht zu ziehen. Im Zusammenhang mit systemnahen Archiven wird dieser Ansatz oft unterschätzt. Ein Beispiel: Office-Anwendungen erzeugen die Masse aller Geschäftsdaten und diese Daten altern schnell, was zu immer mehr Online-Speicherkapazitäten bei nur geringer Zugriffshäufigkeit führt. Eine Speicherung dieser kalten Daten in der Public Cloud ist sinnvoll, um zusammen mit HDDs und Flash eine kostenoptimierte, mehrstufige und hybride Speicherverwaltungslösung aufzubauen. Die Cloud findet dann als weitere, nahtlos integrierte Speicher- und Datenverwaltungsebene Verwendung.
Weiterhin ist zu beachten, dass Langzeitdaten inzwischen häufig als Quelle für Analysen oder sogar als primärer kostengünstiger Speicher für selten abgerufene Daten fungieren. Für jedes Unternehmen summieren sich diese Speicherkosten über den gesamten Lebenszyklus bei den Cloud-Storage-Anbietern. Die Kosten können innerhalb kürzester Zeit steigen, indem sich die abzurufende Datenmenge auch nur um wenige Prozente verändert. Cloudanbieter erheben zusätzliche Gebühren, um Daten aus dem Langzeitarchiv abzurufen. Es ist deshalb hilfreich, wenn eine intelligente Datenverwaltungs-strategie die möglichst automatisierte Klassifizierung relevanter Daten vor der Migration in die Cloud berücksichtigt. Dieser vor der Migration stattfindende Prozess bietet die Möglichkeit, sich detaillierter mit relevanten Unternehmensdaten zu beschäftigen und diese zunächst zu bereinigen. Dabei werden nicht nur nicht benötigte Daten gelöscht, sondern der dazu erforderliche Speicherplatz und damit verbundene Kosten gesenkt.
Nicht zuletzt ist daran zu denken, alle Anforderungen an die Produktionshardware zu definieren. In diesem Stadium soll eine genauere Vorstellung davon existieren, welcher Technologien es in der Produktionsumgebung jeweils bedarf. Wichtige Parameter können die Datenmenge und die Schnittstellen-Durchsatzleistung sein, sodass sich die entsprechenden Komponenten sowie Storage- und RAID-Konfigurationen, Betriebssysteme et cetera festlegen lassen.
Cloudspeicher und weitere cloudbasierte Dienste sind in den Bereitstellungsmodellen Storage-as-a-Service, Platform-as-a-Service und Infrastructure-as-a-Service zu haben.
Zugriffskontrolle neu auflegen
Definierte Benutzerrollen und organisatorische Verantwortlichkeiten im Rahmen eines Change-Management-Frameworks sind geeignete Verfahren, um menschliche Fehler zu vermeiden, die oft für Sicherheitsprobleme mit verantwortlich sind. Unternehmen sollten Ressourcen und Daten nicht mehr Mitarbeitern zugänglich machen als unbedingt nötig. Die Migration in die Cloud kann hier eine Gelegenheit darstellen, die Kontrollen bezüglich des Datenzugriffs zu optimieren. Auch die Implementierung von Verschlüsselung bei der Übertragung von Daten und "at-rest" innerhalb der Cloudumgebung sollte möglichst einfach zu implementieren und automatisiert wartbar sein, ohne die Performance negativ zu beeinflussen.
Je nachdem, wo und wie viele Daten gespeichert sind, treten spezifische Speicher-anforderungen auf. Bei umfangreichen Legacy-Tape-Archivsystemen finden sich mit herstellerspezifischer oder selbstentwickelter Media-Library-Software gerne komplexe proprietäre Metadatensysteme, die eigene Tools zum Zugriff und zur Migration erforderlich machen. Es ist auch an dieser Stelle sinnvoll, die Sicherheitsanforderungen zu berücksichtigen und festzulegen, wer an diesem Punkt welchen Zugriff auf welche Daten benötigt.
Datensicherung und Hochverfügbarkeit
Snapshots und Backups müssen auch in der Cloud geplant und je nach SLA-Anforderung regelmäßig erneuert werden. Dabei können die mit der Speicherung verbundenen Kosten ansteigen und sollten deshalb einer kontinuierlichen Überwachung unterliegen. Ein zentraler Punkt betrifft die Wiederherstellung von kritischen Anwendungsdaten. Wer Anwendungen aus der Public Cloud nutzt, darf einen Faktor nicht übersehen: die Sicherung der Daten, die in der Cloud liegen. Denn dafür ist der Nutzer von Software-as-a-Service-Angeboten zuständig und nicht der Cloudprovider. SaaS-Backupwerkzeuge sind somit bei der Nutzung von Diensten wie Microsoft 365 unverzichtbar.
IT-Verantwortliche sollten sich beim Thema Backup & Recovery auch die Frage stellen, ob sich im Ernstfall nur ganze Datenbestände oder auch wichtige Teile davon wiederherstellen lassen. Der Provider sollte granulare Recovery-Prozesse unterstützen, damit beispielsweise eine virtuelle Maschine oder einzelne Dateien einer virtuellen Applikation granular zurückgeholt werden können. Oft kommen für das Backup unterschiedliche Anwendungen auf verschiedenen Plattformen zum Einsatz. Doch darüber hinaus ist es nötig, dass herstellerübergreifende beziehungsweise unabhängige Disaster-Recovery-Mechanismen zur Verfügung stehen, um kritische Daten auch Ende-zu-Ende schützen zu können.
Die Auswirkungen eines Systemausfalls sind im Vorfeld in jedem Falle konkret abzuwägen – auch als Grundlage einer realistischen Disaster-Recovery-Planung. Ausfallsicherheit lässt sich bei modernen Cloudplattformen anstelle von separaten Disaster-Recovery-Standorten mittels Hot-Cold-Szenarien oder einer vollständig lastverteilten Redundanz über geografische Regionen hinweg implementieren. Moderne Infrastructure-as-Code-Tools erlauben es, die IT-Infrastruktur in vorgefertigten Konfigurationsdateien so zu definieren, dass sich die jeweilige Umgebung über automatisierte Werkzeuge schnell wiederherstellen lässt.
Kosten realistisch einschätzen
Je nach Art des gewählten Betriebsmodells bietet die Cloud diverse Möglichkeiten zur Kosteneinsparung. Aber wenn die vorhandenen lokalen Ressourcen weiterlaufen, erhöhen sich naturgemäß die Gesamtausgaben. IT-Verantwortliche sollten bei der Gesamtkosten-Betrachtung zudem die Tatsache berücksichtigen, dass viele Cloudprovider Gebühren für den Rücktransfer (Download) der Daten in das eigene Unternehmen in Rechnung stellen. Je nach Betriebsmodell und über den gesamten Lebenszyklus der Daten gerechnet (zehn bis 15 Jahre) sind diese Gebühren kritisch und können – insbesondere wenn die abzurufende Datenmenge hoch ist – die Kosten für den Primärspeicher übertreffen.
Nicht alle Public-Cloud-Anbieter arbeiten mit leicht einsehbaren Gebühren für Datenabrufe oder API-Anfragen, die parallel zur Datennutzung steigen. Der Großteil aller Daten sollte nach Möglichkeit deshalb dorthin umziehen, wo die Speicherkosten niedrig und die Transparenz sowie die Kontrolle gleichzeitig hoch sind, also zu spezialisierten Cloud-Storage-Anbietern mit Kompatibilität auf Bit-Ebene und Hochgeschwindigkeitsanbindung.
Die Verlagerung von Ressourcen in die Cloud kann dann eine kostensparende Maßnahme darstellen, wenn Firmen veraltete Daten oder unnötige Duplikate vorher löschen und klar ist, welche Informationen jetzt wie auch in Zukunft zugriffs- und kostenoptimal Verwendung finden. Entscheidungen nur auf Basis des reinen Service-Preises sind meist nicht zielführend. Grundsätzlich gilt es, bei der Providerwahl anzumerken, dass die technischen Anforderungen mit den geschäftlichen Erfordernissen und der Kostenseite abzuwägen sind und Kompromisse nötig sein können.
Unterbrechungen vermeiden
Die Punkte Ausfallsicherheit und Datensicherung samt Wiederherstellung sollten wie bereits erwähnt immer im Mittelpunkt des gesamten Prozesses stehen. Legacy-Elemente, die nicht vollständig in die Cloud umziehen können, lassen sich über hybride Umgebungen einbinden. Das zentrale System bleibt dann bestehen und wird über Speicher- und Rechenleistung aus der Cloud ergänzt. Bei einer hybriden Cloudstrategie kann es sinnvoll sein, On-Premises-Daten in der Cloud zu replizieren, um die Wiederherstellung sicher zu gewährleisten.
Nicht zuletzt ist es ratsam, die Migration mit Daten aus der Produktionsumgebung – etwa über einen Mirror – großzügig zu testen und nicht nur mit einer Stichprobe. Denn wenn Testdaten nicht repräsentativ sind, ist die Wahrscheinlichkeit groß, bei den Live-Daten Bedingungen vorzufinden, die zur Laufzeit einen Fehler bei der Migration verursachen. Auch mit sorgfältiger Planung können jedoch beim Umzug in die Cloud Datenverluste oder Leistungseinbußen bis hin zu Produktionsausfällen auftreten. Nach Möglichkeit sollte die Migration deshalb in den ruhigeren Phasen eines Geschäfts erfolgen und sind Benutzer in Bezug auf die Zeitfenster mit einzubinden.
Für den Fall des Fehlschlagens einer Migration sollten sich IT-Entscheider frühzeitig überlegen, ob ein Rollback möglich ist und ob es dafür providerseitige Unterstützung gibt. Die Rückabwicklung einer gescheiterten Migration ist nicht nur komplex, sondern erfordert auch organisationsübergreifende Unterstützungsmaßnahmen, die vor der Durchführung zu planen sind. Wurde die Cloudumgebung dann erfolgreich in Betrieb genommen, ist diese kontinuierlich zu optimieren, zu automatisieren und zu testen. Dies gilt besonders für die Bereiche Backup und Restore sowie Disaster Recovery. Protokolle zu SLAs und Migrationsvalidierung sind schlussendlich über einen unabhängigen Prozess zu dokumentieren, um sicherzustellen, dass der Migrationsprozess alle notwendigen Daten in ausreichender Qualität geliefert hat.
Fazit
Moderne cloudnative Technologien ermöglichen es, skalierbare Anwendungen in dynamischen Umgebungen wie öffentlichen, privaten oder hybriden Clouds zu erstellen und auszuführen. Container, Servicenetze, Mikroservices, Infrastructure-as-a-Code sowie deklarative APIs veranschaulichen diese Entwicklung. Gut durchdachte Pläne für eine robuste und sichere Migration in die Cloud sind aus Anwendungs- und Datenverwaltungssicht deshalb ein unverzichtbarer Bestandteil jeder Unternehmens- und IT-Strategie.
(ln)