Migration von Workloads in die Cloud
Vom RZ in die Wolke
Cloud-Computing gehört heute zum IT-Alltag, fast so selbstverständlich wie der Umgang mit Windows-Programmen. IT-Services lassen sich damit auf völlig neue Weise virtuell bereitstellen. Um eine Cloud nutzen zu können und über diese Geschäftsanwendungen einzusetzen, bedarf es jedoch einer vernünftigen Vorbereitung.Workloads, also der Inhalt der originären Server mit den Daten, sind als 1:1-Abbild auf die gewählte Cloud-Infrastruktur zu übertragen. Unternehmen setzen eine eigene Cloud entweder neu auf oder transferieren Teilbereiche ihrer existierenden Infrastruktur an einen neuen Standort oder zu einem Cloud-Anbieter. Wie sich dieser Prozess bei den beiden verschiedenen Ausgangslagen - physisch und virtuell - aufsetzen lässt und welche Anwendungen für die Migration zum Einsatz kommen können, ist Gegenstand der folgenden Diskussion. Cloud-Computing stellt dem Nutzer IT-Ressourcen und Services zur Verfügung, die von der darunter liegenden Infrastruktur losgelöst sind. Diese sind in jedem Moment abrufbar, bedarfsabhängig nutzbar, skalierbar und sollen zudem möglichst leistungsfähig und zuverlässig sein. Bei einer Cloud-Lösung geht es nicht mehr um den eigenen Server oder die Server-Konfiguration vor Ort im Unternehmen oder auch in einem externen Rechenzentrum als Outsourcing-Modell, sondern um eine mit vielen Nutzern geteilte, elastische und vor allem virtuelle Umgebung. Eine Cloud lässt sich über mehrere Standorte und Ländergrenzen aufsetzen. Dazu fungieren gewissermaßen als Basis die Infrastructure-as-a-Service-Anbieter (IaaS) für Server, Storage, Netzwerke und damit verbundene Dienste. Wenn sich ein Unternehmen entschieden hat, welche Anwendungen zukünftig in einer Cloud bereit stehen sollen, müssen die Verantwortlichen festlegen, wie diese zu migrieren sind. Fakt ist, dass die Anwendungen und Daten zunächst auf den Server des Cloud-Anbieters gelangen müssen. Um den Schritt in eine Cloud in der Praxis zu realisieren, muss der RZ-Betreiber daher größere Datenmengen in einem sicheren Prozess und für Nutzer möglichst ausfallfrei von einem Standort zum neuen Cloud-Standort transferieren. Gilt es dabei zudem, neue Dienste und Funktionen aufzubauen, werden die Datensätze auch direkt in der Cloud generiert. Doch wie verhält es sich, wenn er seine aktuelle Infrastruktur (physisch oder virtuell) in die Cloud auslagern will? Entscheidet er sich für einen Umzug, kommt er meist nicht um eine Datenübertragung von größeren Datenmengen herum. Dann sind die Cloud-Anbieter gefragt, die ihre Ressourcen meist über das Internet bereitstellen, schnell zugängliche und erprobte Softwarelösungen für einen reibungslosen Datentransfer anzubieten. Der RZ-Betreiber kann bei der Migration auf verschiedene Tools zurückgreifen, die abhängig von der verwendeten Infrastruktur unterschiedliche Vorgehensweisen erfordern. Abhängig von den gegebenen Voraussetzungen muss er sich für den passenden Migrationsweg entscheiden: Physical-to-Virtual (P2V) oder Virtual-to-Virtual (V2V), der auch bei einer Migration von Workloads in Hybrid-Cloud-Modelle eine Rolle spielt. Letztere sind als Kombination aus Public und Private Cloud bereits über Virtualisierung aufgebaut. Bei der Variante P2V geht die physische Basis in eine virtuelle Umgebung über. Dabei entsteht ein Abbild des physischen Servers, ohne dass dieser dabei selbst ausgeschaltet werden muss. Für diesen Prozess ist eine virtuelle Festplatte in Form einer Datei auf einem beliebigen Datenträger erforderlich, die entweder direkt in die virtuelle Umgebung oder auf einen Zwischenspeicher übergeht. Von physischer in eine virtuelle Umgebung Der Austausch der Treiber ist bei der Konvertierung der entscheidende Punkt, da das Betriebssystem nun nicht mehr direkt mit der Hardware kommuniziert, sondern zunächst mit dem Hypervisor, der für den Zugriff auf die tatsächliche Hardware verantwortlich ist. Der Hypervisor ist eine Schicht, die funktional die Verteilung der Daten von der physischen Hardware an die virtuellen Server übernimmt. Für die Erstellung der virtuellen Kopie gibt es mehrere Tools, beispielsweise Platespin-Migrate oder den VMware Converter. Soll eine Migration mit der Übertragung der Daten von einem laufenden System erfolgen, installiert der Administrator meist einen Agenten für den Zeitraum des Prozesses auf dem Quell-Server und entfernt ihn nach erfolgreichem Abschluss wieder. Die Anwendungen laufen wie zuvor weiter. Im Rahmen der virtuellen Infrastruktur muss ein Management-Server, wie beispielsweise ein Vcenter von VMware, das Zielsystem bereitstellen. Alternativ zum Internet kann eine bestimmte Netzwerkverbindung oder ein physischer Datenträger zum Einsatz kommen, um den Übergang von Daten auf die virtuellen Server umzusetzen. Dieser Migrations- und Transferprozess lässt sich bei einer größeren IT-Landschaft sukzessive realisieren, also Server für Server. Der Vorgang läuft solange, bis die gesamte physische Umgebung identisch und nutzungsbereit in der virtuellen Umgebung vorliegt. Migrations-Tools wie Platespin Migrate können auch die Änderungen, die auf dem Quell-Server noch während des Migrationsprozesses stattfinden, erkennen und nachträglich mit dem virtuellen Ziel-Server synchronisieren. Dieses optional einzusetzende Instrument stellt sicher, dass der Datenbestand in der Cloud aktuell ist, wenn sich der Migrationsprozess über einen längeren Zeitraum erstreckt. Von virtueller zu virtueller Umgebung Bei der Überführung einer existenten virtualisierten Infrastruktur in eine Cloud Umgebung greifen die gleichen Instrumente für die Migration. Der Quell-Server ist jedoch bereits virtuell. Dies ist der entscheidende Unterschied. Setzt der Betreiber bereits auf eine Virtualisierungslösung und muss diese wechseln, zum Beispiel weil der Cloud-Anbieter sie nicht unterstützt, ist die gleiche Art von Migration möglich. Mit der Entscheidung, von einem laufenden System zu migrieren, muss das System eigene Hardwareressourcen für diesen aufwändigen technischen Vorgang nutzen, bei dem die Festplattengeschwindigkeit temporär heruntergesetzt sein kann. Die CPU- und Netzwerkleistung sind unter gewissen Umständen beeinträchtigt, also nicht voll für den normalen Arbeitsbedarf verfügbar. Wenn Cloud-Initiatoren dies ausschließen wollen, sollte zunächst eine Datenspeicherung erfolgen. Mit dem entstandenen Image als Voll-Backup läuft dann die eigentliche Migration ab. Dies gilt gleichermaßen für die Wege P2V und V2V. Unabhängig von der Grundsatzentscheidungen, ob der Workload- und Datentransfer mit dem Zwischenschritt einer Backup-Version der Server erfolgt, muss ein Betreiber den gesamten Migrationsprozess gründlich planen und den Vorgang fachkundig observieren. Für Entscheider, die sich mit der Thematik Cloud neu auseinandersetzen, ist noch ein Hinweis interessant: Festplatten müssen bei einer Datenmigration nicht abgeschaltet werden. Die Migration in die Cloud oder von einer Cloud-Lösung in eine andere kann komprimiert, an einem Stück und ohne Ausfälle im Arbeitsbereich vonstatten gehen. Die Migration in einer hybriden Cloud-Lösung Eine Hybrid Cloud basiert auf mindestens zwei virtuellen Umgebungen. Eine davon ist eine Private Cloud, die das Unternehmen selbst betreibt. Parallel dazu ist eine Public-Cloud-Lösung im Einsatz. Eine Migration innerhalb einer hybriden Umgebung erfolgt schrittweise. Die einzelnen Resultate lassen sich auf ihre volle Funktionsfähigkeit hin testen und dann weitere Daten zwischen dem lokalen und dem neuen Standort fortlaufend migrieren. Die originäre Cloud-Lösung kann entweder bei einem Unternehmen selbst aufgesetzt oder in einem externen Rechenzentrum gehostet sein. Für den Betrieb einer hybriden Cloud gibt es als Partner für das Unternehmen bereits einen oder mehrere Cloud-Anbieter. Mit dieser Voraussetzung ist die eingesetzte Software für den Migrationsprozess wichtig: Zum Beispiel kann ein Produkt von Microsoft im Einsatz sein, und auf der anderen Seite ist es das Pendant von VMware. Es geht bei der hybriden Form also bereits um einen virtuellen Status, der anforderungskonform zu verändern ist. Der Converter greift an dieser Stelle ein, isoliert die Virtualisierungsschicht und implementiert sie wieder an einem anderen Ort. Bei der Migration konvertiert das System zum Beispiel die Festplattendateien von .vhd zu .vmdk oder umgekehrt, um diese mit dem jeweiligen Hypervisor des verwendeten Herstellers kompatibel zu machen. Bei einem großem zu migrierenden Datenvolumen empfiehlt es sich, ein Image oder das erzeugte Backup als Quelle für die Erstellung virtueller Server zu verwenden, weil dadurch die produktive Umgebung ohne Beeinträchtigung weiterarbeiten kann. Der Transfer der Daten an den neuen Standort kann auf konventionellem Weg erfolgen, nämlich durch einen Transport eines physischen Datenträgers, der am Zielstandort angeschlossen wird. Datenänderungen, die während des Transports auf dem Quell-Server entstehen, lassen sich wie bei einer Migration über das Netzwerk nachträglich synchronisieren. Eine solche Lösung kann unter wirtschaftlichen Gesichtspunkten sinnvoll sein, wenn die Kosten für den Bandbreitenbedarf und für den Up- und Download bei der Migration mit großen Datenmengen zu hoch sein würden. Wenn die Daten auf Servern im Ausland liegen, ist die Variante mit einer Kopie auf einem Datenträger aus Sicherheitsgründen eine Option, wenn die Netzverbindung unsicher zu sein scheint. Eine Cloud eignet sich schließlich auch für Backup-Lösungen im Unternehmen. Bei einem Cloud-Anbieter mit Rechenzentrumsflächen kann eine Private Cloud als Backup parallel arbeiten. Backup- und Disaster-Recovery-Funktionen dienen dann der Sicherheit durch gespiegelte Datenwelten. Dazu bieten sich auch zwei unterschiedliche Standorte und von verschiedenen Cloud-Anbietern für einen Kunden betriebene Systeme an. Bei hohem Migrationsvolumen sind RZ-Betreiber auf die Unterstützung des Cloud-Anbieters angewiesen, da die Daten nicht über das Standardnetzwerk laufen, sondern beispielsweise ein alternatives internes Netzwerk des Providers zum Einsatz kommt. Darauf sollten RZ-Betreiber bei der Auswahl ihres Cloud-Partners achten. Auch die externe multiple Netzanbindung ist ein wichtiges Auswahlkriterium, da eine Vielfalt an verfügbaren Carriern und eigene Netzkapazität Private- und Public-Cloud-Lösungen an einem Standort zulässt.
Lesen Sie mehr zum Thema
