On-Premises-Migration und Cloud-Servermigration im Vergleich

Die Migration von einem Server zu einem (virtuellen) Server

Server-zu-Server-Migrationen können physisch zu physisch (P2P) erfolgen, wobei eine herkömmliche nicht virtualisierte oder Bare-Metal-Anwendung auf einen anderen nicht virtualisierten Server verschoben wird. Dafür installiert man die Anwendungen neu auf dem zukünftigen Server.

Spezielle Tools wie PlateSpin und VMware Converter können den Zeitaufwand für die Migrationen reduzieren. Wenn ein Workload lokale Daten benötigt, können diese auf den Zielserver kopiert werden und Administratoren können die migrierte Anwendung so konfigurieren, dass sie alle migrierten Daten wieder findet.

Physisch-virtuelle Migrationen (P2V) erfordern ähnliche Überlegungen. Administratoren können Bare-Metal-Anwendung auf einer VM (virtuellen Maschine) neu installieren und im Voraus bereitstellen. Auch hier können die bereits genannten Migrations-Tools eine schnellere P2V-Migrationen unterstützen.

P2P- und P2V-Migrationen gehen unvermeidlich mit Ausfallzeiten einher, in der Administratoren den Umzug und die Konfiguration der Workloads durchführen; planen Sie also entsprechend.

Ein genauerer Blick auf lokale V2V-Migration

Virtuell-zu-Virtuell-Migrationen (V2V) sind die gängigste Art der Migration, ob On-Premises oder in der Cloud: Hypervisoren wie Hyper-V und vSphere unterstützen problemlos Live-Migrationen. Diese Tools verschieben automatisch eine funktionierende VM von einem Quell- auf einen Zielserver, ohne dass die VM während des Umzugs stillgelegt oder angehalten werden muss. Das Ergebnis sind geringe oder gar keine Ausfallzeiten.

Datenmigrationen, bei denen Administratoren Dateien von einem Server auf einen anderen zu kopieren, können vor oder während der Live-Migration erfolgen. Allerdings erfordert der Umzug großer Datensätze, selbst über ein LAN, einen erheblichen Zeitaufwand, so dass unter Umständen Workloads, die auf diese Daten angewiesen sind, erst danach vollständig laufen.

Eine typische lokale V2V-Migration im Detail

Planung. Seien Sie sich von Anfang an darüber im Klaren, warum Sie von einer virtuellen Ressource auf eine andere wechseln. Ein häufiger taktischer Grund ist, dass ein Serverfehler einer virtuellen Maschine Probleme bereitet. Sie möchten daher die virtuelle Maschine verschieben, um das zugrunde liegende Hardwareproblem beheben zu können.

Oder die Migration hat strategische Gründe und Sie möchten einen in die Jahre gekommenen Server außer Betrieb nehmen, um die VMs auf einen neuen Server zu verschieben. Alternativ kann es auch sein, dass Sie die Leistung verbessern möchten und die VMs verschieben, um Ihre Workloads auf mehrere Zielsysteme zu verteilen.

Vorbereitung. Identifizieren Sie die VMs und Datensätze, die Sie verschieben müssen, und zeichnen Sie die Konfiguration jeder virtuellen Maschine auf. Wählen Sie dann den geeigneten Zielserver für die Migration aus. Es gibt in vielen modernen Virtualisierungsplattformen Tools, die diese Vorbereitungsarbeit rationalisieren und automatisieren. Dennoch ist es sinnvoll, wenn Administratoren begreifen, was im Hintergrund abläuft.

Ausführung. Moderne Werkzeuge machen den eigentlichen Migrationsprozess kurz. Beim Hyper-V-Manager beispielsweise wählen Administratoren einen Quellserver aus und stellen eine Verbindung zu diesem her, wählen die zu verschiebenden VMs aus und verwenden dann den Verschiebungs-Assistenten, um den Prozess zu konfigurieren und den Zielserver auszuwählen. Wenn der Administrator den Assistenten abgeschlossen hat, wird die Migration automatisch ausgeführt.

Obwohl Live-Migrationen nur geringe Ausfallzeiten verursachen, sollten Sie trotzdem solche Migrationen eher in Zeiten mit geringer Auslastung durchführen. Auf diese Weise wirken sich etwaige Probleme auf möglichst wenige Benutzer aus. Wenn Sie die Anwendung aus irgendeinem Grund stilllegen müssen, sollten Sie Ausfallzeiten einplanen.

Testen. Wenn die V2V-Migration abgeschlossen ist, prüfen Sie die Anwendung, um sicherzustellen, dass sie wie erwartet funktioniert. Migrationen von unternehmenskritischen Workloads sollten Wiederherstellungsstrategien umfassen, damit Sie die Migration bei schwerwiegenden Problemen rückgängig machen können.

Wenn Sie den Workload ursprünglich mit einem Überwachungs-Tools beobachtet haben, aktualisieren Sie diese Tools, um nach der Migration weiterhin zuverlässige Daten zu bekommen.

Nachbereitung. Anschließend können Sie den Ausgangsserver je nach Bedarf reparieren, aktualisieren, wiederverwenden oder ausmustern.

Überblick über die Migration vom Server in die Public-Cloud

Viele Organisationen haben mittlerweile neben ihrem Rechenzentrum einzelne Workloads in die Cloud verlagert. Eine Migration von einem lokalen Rechenzentrum in eine Public Cloud folgt dem gleichen grundlegenden Prozess wie eine lokale P2V- oder V2V-Migration, doch es kommen einige zusätzlichen Überlegungen auf Sie zu.

Erstens verschieben Sie wahrscheinlich nicht nur Workloads in die Cloud, sondern auch die von ihnen verwendeten Datenspeicher. Dies geschieht auch bei lokalen Servermigrationen, wenn sich die zugehörigen Daten auf demselben Server wie die Anwendung befinden. Da aber Implementierungen mit geteiltem Speicher die Regel sind, ist das eher selten.

Wenn Sie eine VM in die Cloud verschieben, kann sie immer noch Daten verwenden, die sich auf einem lokalen Server oder Speichersubsystem befinden. Dieser Zugriff ist jedoch unsicher, weil dafür laufend eine optimale Internetverbindung nötig ist. Außerdem fallen beträchtliche Egress-Gebühren an, wenn laufend Daten aus der Cloud zurück in Ihr lokales Rechenzentrum wandern. Die Workload-Performance verbessert sich in der Regel, wenn sich die Daten und die Anwendung am selben Ort befinden.

Zweitens sollten Sie, auch, wenn Sie On-Premises ohne Infrastrukturüberwachungs-System ausgekommen sind, beim Wechsel in die Cloud auf alle Fälle ein solches anschaffen. Sie sind für Sie der einzige Weg, die Ressourcenauslastung, Kosten und Leistung nachzuvollziehen. Dienste wie Amazon CloudWatch oder Azure Monitor sammeln Metriken zur Überwachung der Anwendungsleistung und des Anwendungszustands und erstellen gleichzeitig Berichte über die Nutzung von Cloud-Ressourcen.

Prozess der V2V-Migration in die Cloud

Planung. Cloud-Umgebungen haben eine ganz andere Infrastruktur als lokale Rechenzentren, so dass Cloud-Migrationen nicht kurzfristig und aufgrund akuter Beweggründe durchgeführt werden. Stattdessen sind sie oft Teil einer übergreifenden Unternehmensstrategie und sollen Investitionen in die lokale Infrastruktur und deren Wartung reduzieren.

Die skalierbare, bedarfsorientierte Natur der Cloud ist bei Workloads mit stark schwankendem oder unvorhersehbarem Datenverkehr und Ressourcenbedarf ein weiterer Grund für die Migration. In ähnlicher Weise kann das Kopieren eines Workloads und von Daten in eine Cloud-Region, die weit von Ihrem lokalen Rechenzentrum entfernt ist, den Workload zum Reduzieren von Latenzen näher an seine Benutzer bringen, ohne dass Sie ein dediziertes Rechenzentrum in dieser Region aufbauen müssen.

Vorbereitung. Eine Cloud-Migration erfordert mehr Überlegung und Vorbereitung als nur die Auswahl eines Zielservers. Public Clouds bieten eine große Auswahl an Zielserverinstanztypen, Speicherdiensten, Load Balancern, Skalierungsdiensten und so weiter. Sie müssen erst eine Infrastruktur aus den virtuellen Ressourcen in der Cloud aufbauen, damit der Workload ein tatsächliches Ziel hat.

Im einfachsten Fall müssen Sie dafür lediglich eine Speicher- und Recheninstanz in der Cloud bereitstellen. Um einen Produktions-Workload zu migrieren, sind es jedoch möglicherweise mehrere Rechen- und Speicherinstanzen, Skalierungsdienste, Lastausgleichsdienste, Datenbankdienste und mehr, die Sie konfigurieren müssen. Die Vorbereitung einer komplexen Cloud-Migration kann die Fähigkeiten eines Cloud-Architekten erfordern.

Ausführung. Cloud-Migrationen sind selten ein einstufiger Prozess. Die Daten werden in der Regel erst dann migriert, wenn Sie geeignete Ressourcen oder eine komplette Cloud-Infrastruktur bereitgestellt haben. Die Datensätze können sehr umfangreich sein und leicht bis in den Terabyte- oder sogar Petabyte-Bereich gehen. Sie sind viel zu groß, um sie über eine herkömmliche Internetverbindung zu bewegen. Verwenden Sie stattdessen eine dedizierte Verbindung oder versenden Sie die Daten auf physischen Geräten mit Diensten wie AWS Snowball oder Google Transfer Appliance.

Nachdem die Daten verschoben wurden, müssen sie mit den lokalen Daten synchron gehalten werden, solange der Workload noch On-Premises läuft und sich dadurch Daten ändern. Dienste wie AWS DataSync und Azure File Sync können dabei helfen, große Umzüge zu bewältigen und die Datensynchronisation aufrechtzuerhalten.

Sobald die Daten bereit sind, ist es an der Zeit, den eigentlichen Serverumzug auszuführen und die VMs von On-Premises zu den in der Cloud bereitgestellten Instanzen zu migrieren. Administratoren können problemlos händisch lokale VM-Dateien in Cloud-Recheninstanzen kopieren und sie ausführen, aber dieses Vorgehen ist nur in seltenen Fällen sinnvoll. Cloud-Anbieter bieten Tools wie Google Migrate for Compute Engine und Azure Migrate an, die für die Verwaltung einer großen Anzahl von Migrationen in die Cloud entwickelt wurden.

Testen. Wenn die Migration abgeschlossen ist, können Sie die Workloads, Daten und unterstützenden Dienste neu starten. Entfernen Sie die Workloads und Daten nicht von ihrem lokalen System und behalten Sie die Datensynchronisation bei, bis Sie die Cloud-Bereitstellung gründlich getestet haben. Es ist eine übliche und sinnvolle Praxis, dass Administratoren die Benutzer über die bevorstehende Migration informieren, sie benachrichtigen, wenn die Migration abgeschlossen ist und sie bitten, Feedback zu geben oder Probleme zu melden.

Nachbereitung. Die bisherigen Ausführungen gingen davon aus, dass die Quellserver wiederverwendet oder stillgelegt werden, sobald die Cloud-Migration und die Tests abgeschlossen sind. Bei einigen Cloud-Migrationsprojekten kann es jedoch vorkommen, dass der lokale Server und Datensatz zusammen mit dem Cloud-Workload und -Datensatz laufen. Das Ziel ist hier in der Regel die Verbesserung der Skalierbarkeit und Ausfallsicherheit.

Die grundlegende Idee von Migrationen zwischen On-Premises-Ressourcen und von On-Premises in die Cloud ist zwar dieselbe, doch Servermigrationen sind oft eher taktischer Natur oder erfolgen nach Bedarf, um ein Problem zu lösen. Cloud-Migrationen hingegen sind meist Teil einer Strategie, um langfristige Lösungen für Geschäftsprobleme zu finden.

Oft laufen beide Prozesse im selben Unternehmen nebeneinander her: Im On-Premises-System werden Workloads verschoben, weil eine eigene Serverinfrastruktur aufrechterhalten wird, während zeitgleich geeignete Anwendungen in die Cloud migriert werden.