Server in virtuelle Maschinen übertragen

15.02.2006 von Dennis Zimmer
Die Einrichtung virtueller Server erfordert nicht zwingend eine Neuinstallation. Mehrere Toolshelfen bei der Umstellung bestehender physikalischer Systeme.

Fast jedes Unternehmen hat IT-Systeme, die schwer oder gar nicht neu installierbar sind. Sei es eine al- te undokumentierte Windows-NT-4-Anwendung für die Buchhaltung, deren Entwickler schon lange nicht mehr im Unternehmen tätig ist, oder ein über die Jahre gewachsener Server, der eine Vielzahl von Anwendungen beherbergt, deren erneute Installation etliche Wochen in Anspruch nehmen würde.

Hier lesen Sie …

  • warum eine manuelle Migration von Systemen in eine Virtualisierungsumgebung schwierig ist;

  • worin sich "Physical-to- Virtual"-Werkzeuge voneinander unterscheiden;

  • worauf Anwender bei der Migration achten müssen.

Die Migration eines physikalischen Systems auf einen virtuellen Server lässt sich mit dem Klonen von bestehenden Installationen auf neuer Hardware vergleichen.

Aufwändig gestaltet sich ebenfalls das erneute Einrichten ganzer Server-Farmen, etwa aus fünf und mehr Systemen. Deren Neuinstallation kann Ressourcen lange binden, und das kostet in der IT bekanntlich nicht nur Zeit.

Migration theoretisch einfach

In solchen Fällen liegt es nahe, bestehende Konfigurationen auf virtuelle Server zu übernehmen. Eine solche Migration, auch P2V ("physical-to-virtual") genannt, lässt sich mit dem Klonen eines Systems auf eine andere Hardware vergleichen. P2V ist ein Schlüssel zur Einführung einer virtuellen Infrastruktur in bestehenden IT-Server-Landschaften.

Die Übertragung physikalischer Systeme in virtuelle läuft zumindest theoretisch einfach ab und unterteilt sich grob in folgende Schritte:

  1. Imaging der bestehenden physikalischen Betriebssystempartition;

  2. Wiederherstellen des Images im virtuellen System;

  3. Kopieren der Datenpartitionen (falls vorhanden) auf das virtuelle System;

  4. Installation der Virtualisierungstreiber und -programme (VMware Tools, MS Virtual Tools);

  5. Testen der Anwendung auf dem neuen Server (vorheriges Abschalten des physikalischen Systems)

Danach existiert das identische System Bit-genau in der virtuellen Welt.

In der Praxis geht es leider komplizierter zu. Meistens tauchen zwischen Schritt 1 und 2, also bei der Migration des Betriebssystems, Probleme auf, da es sich bei beiden Systemen um unterschiedliche Hardwaretypen handelt. Der Hauptgrund für zahllose Abstürze ist der Festplatten-Controller, da sich das Betriebssystem beim Hochfahren nicht mehr selbst findet. IT-Experten kennen diese Situation. Sie tritt bei jedem physikalischen Rechnertausch mit unterschiedlicher Hardware auf. Neben der Hardware existieren auch Haken und Ösen bei der Software, beispielsweise in Form von Dongles oder Hardwareprüfsummen.

Schwierig: Manuelle Migration

Um den Hardwareproblemen zumindest einigermaßen aus dem Weg zu gehen, kann man sich an Anleitungen für die manuelle Migration orientieren, die im Internet zu finden sind. Alternativ hilft auch eine Reihe von Tools, die viele der anfallenden Aufgaben übernehmen können.

Stolpersteine

  • IDE- zu SCSI-Konvertierung,

  • SCSI- zu IDE-Konvertierung,

  • Multi-Boot-Systeme,

  • Verwendung dynamischer Systemfestplatten,

  • Ein- zu Multi-Prozessor- Konvertierung,

  • Multi- zu Einprozessor- Konvertierung,

  • spezielle Einsteckkarten, zum Beispiel Fax- oder ISDN Karten,

  • Hardwaredongle auf dem Quellsystem,

  • Hardwareprüfsummen,

  • USB-Geräte.

Der manuelle Weg setzt tief gehende Betriebssystem-Kenntnisse voraus, da er unter anderem Treiberanpassungen, Treiberaustausch oder auch den Wechsel des Hardware Abstraction Layer (HAL) einschließt. Es gibt zwar Tricks, etwa durch die Verwendung von IDE-Festplatten, aber auch diese garantiert keine erfolgreiche Migration. Deshalb sind eine vorherige Sicherung und entsprechende Tests oberstes Gebot.

Vorsicht Domänen-Controller

Darüber hinaus müssen Anwender sich das Quellsystem genau anschauen. Handelt es sich um den einzigen Domänen-Controller (PDC) unter Windows NT 4, ist mit Anmeldeproblem zu rechnen. Auch Aspekte wie Hardware-Dongle oder Faxkarten müssen bedacht werden. In diesem Fall kommt es auch auf die durch das Virtualisierungsprodukt unterstützte Hardware an. "VMware ESX" erlaubt beispielsweise keine USB-Geräte in der virtuellen Maschine, und zusätzliche PCI- Karten lassen sich bei keinem virtuellen System verwenden. Daher sind externe USB-over-Ethernet, Faxrouter oder Netzwerk CAPI Software (etwa "AVM Ken") eine durchaus praktikable Alternative.

Wie schon erwähnt, existiert eine Vielzahl von Software, die die Migration vereinfacht und so dem Systemverantwortlichen Zeit sparen und seine Nerven schonen.

Physical-to-Virtual-Werkzeuge im Vergleich

Produkt

Powerconvert

P>V direct

P2V Assistant

CBMR

MS VSMT

Hersteller

Platespin

Leostream

EMC/VMware

Christie Data Products

Microsoft

Windows Gast

NT 4 SP6, 2000, XP, 2003

NT 4 SP6, 2000, XP, 2003

NT 4 SP6, 2000, XP, 2003,

2000, XP, 2003

2000, XP, 2003

Linux Gast

Red Hat 7.3, Red Hat 8

nein

nein

teilweise

nein

Verfahren

TCP/ IP-Verbindung, Kopie auf Sektorebene

TCP/ IP-Verbindung, Kopie auf Sektorebene

TCP/ IP-Verbindung, Kopie auf Sektorebene

TCP/ IP- oder Direktverbindung zu Bandlaufwerk, Kopie auf Dateiebene

TCP/ IP-Verbindung, PXE, auf Sektorebene

Besonderheit

Zentrale Verwaltungsoberfläche, Red-Hat-Unterstützung, Desaster Recovery

V2V, online Migration

-

Dissimilar-Hardware-Server, Desaster Recovery

Nicht eigenständig (setzt auf Zusatzdiensten auf)

Zielsystem

VMware GSX; VMware ESX; MS Virtual Server

VWware Workstation; VMware GSX; VMware ESX; MS Virtual Server

VWware Workstation; VMware GSX; VMware ESX

Beliebige VM mit emulierter x86 Hardware

MS Virtual PC; MA Virtual Server

Lizenzkosten

25 Lizenzen für 3000 Dollar

Pro Migration

-

Pro Server

keine

WAN-fähig

ja

nein

nein

nein

nein

Partitionierung der Zielpartition

ja

ja

ja

ja

nein

Unterstützung fremder Imaging-Software

nein

Acronis Trueimage; Symantec Ghost

Acronis Trueimage; Symantec Livestate Recovery

nein

nein

Virtual to Virtual

-

nur zwischen MS Virtual Server und VMware ESX

-

ja

nein

Virtual to Physical

ja

nein

-

ja

nein

Physical to Physical

ja

nein

-

ja

nein

Platespin Powerconvert

Die Firma Platespin Ltd. aus Toronto bietet mit Abstand das innovativste Produkt, da es über die bloße P2V-Funktion weit hinausgeht. Hinter "Powerconvert" versteckt sich ein Tool zur Erstellung und Migration vieler virtueller und physischer Systeme, daher wird auch ein eigener Server für das Produkt empfohlen (kann auch eine virtuelle Maschine sein). Der Funktionsumfang ist enorm und automatisiert Massenmigrationen. Außerdem ist es derzeit das einzige Produkt am Markt, das eingeschränkt auch Linux-Systeme (Red Hat) übertragen kann. Als Zielsysteme können VMs unter VMware GSX, ESX und Microsoft Virtual Server dienen. Platespin Powerconvert existiert in mehreren Ausführungen, die je nach Version einen unterschiedlichen Funktionsumfang bieten.

Grundsätzlich besteht Platespins Produkt aus einer zweigeteilten Verwaltungsoberfläche, in der alle verfügbaren Quell- und Zielsysteme im Netzwerk angezeigt werden. Einem oder mehreren beliebigen Ausgangsrechnern kann man die Funktion des Image-Servers übertragen. Dieser dient bei der späteren Migration als Ablageort für die Systemabbilder. Diese Funktion lässt sich auch über schmalbandige WAN-Verbindungen einrichten lässt, beispielsweise auf einem Filial-Server mit genügend freiem Festplattenspeicher, so können spätere Migrationen in dieser Filiale nur im LAN ablaufen. Über die WAN-Leitung werden lediglich die Steuerungsdaten transportiert.

Platespin bietet über den Image-Server vielfältige Migrationsmöglichkeiten, etwa P2V sowie die Übertragung zwischen virtuellen Systemen (V2V = Virtual-to-Virtual). Außerdem gehören Übertragungen zwischen VM und Physik (V2P) und zwischen physikalischen Systemen (P2P) zum Funktionsumfang.

Leostream P>V direct

Leostreams "P>V direct" ist ein reines Migrationsprodukt für die Umsetzung physischer Windows-Server in die virtuelle Welt. Sein größtes Alleinstellungsmerkmal ist die Live-Migration, das heißt, das physikalische System wird im laufenden Betrieb in eine virtuelle Maschine umgezogen. Die Ausfallzeiten lassen sich so verringern, allerdings ist daran zu denken, das Quellsystem nach der Migration abzuschalten.

Migration oder Neuinstallation?

Migration

Neuinstallation

Schwieriger Prozess der Betriebssystem-Migration

Betriebssystem-Installation wie von physikalischen Systemen gewohnt

Anwendungen können unverändert beibehalten werden

Anwendungsinstallation kann viel Zeit in Anspruch nehmen

Schnelle Massenmigration vieler Server

Massenneuinstallation ist aufgrund der Anwendungen sehr aufwändig

Tiefes Know-how von Virtualisierungsprodukt und Gastbetriebssystem notwendig

Neuinstallation bereits bekannter Software ist Routine

System bleibt so „chaotisch“ wie vorher, das heißt, auch alle nicht mehr benötigten Treiber und Programme werden mitgenommen

System ist von allen unnötigen Programmen und Aktualisierungen bereinigt

P>V direct arbeitet als reine Client-Server-Anwendung und setzt einen installierten Agenten auf dem VMware GSX, ESX oder Microsoft Virtual Server und eine Client-Software auf der zu migrierenden Maschine voraus. Anschließend stellt der Client als Quellsystem die Verbindung zum Ziel her und nach Angabe der Destination und ihrer Eigenschaften (Lokation, Partitionsgröße) beginnt die Umstellung. Diese läuft vollautomatisch ab, und nach Abschluss kann das Quellsystem verwendet werden.

VMware P2V Assistant

VMware bietet mit "P2V Assistant" ein Client-Server-Produkt an, mit dem physische Systeme unter Windows in VMs unter VMware Workstation, GSX und ESX überführt werden können. P2V Assistant besteht aus zwei Modulen, der Boot-CD und der eigentlichen Software. Mittels CD wird das Quellsystem in ein Linux gebootet, welches die existierende Hardware teilweise erkennt (Controller, Festplatten und Netzwerkkarten) und nach Angabe der TCP/IP-Informationen einen P2V-Server startet. Während der Server läuft, muss sich der Administrator mit diesem über die P2V-Software verbinden. Danach und nach Auswahl der betroffenen Partitionen wird ein Image auf der Festplatte des Clients angelegt. Dieser Schritt ist nicht zwingend notwendig: Anwender können auch Images von Produkten wie "Acronis Trueimage" oder "Symantec Ghost" verwenden.

Außerdem kann der P2V Assistant das Image in eine für die Virtualisierungssoftware nutzbare Version konvertieren, indem die Treiber für Festplatten-Controller ausgetauscht werden. Am Ende der Konvertierung findet man meist mehrere 2 GB große .vmdk-Festplattendateien, die man je nach Zielsystem einfach in ein Verzeichnis kopieren oder im Falle des ESX Servers importieren muss.

Cristie CBMR

Das Produkt "CBMR" (Cristie Bare Metal Restore) der Firma Cristie Data Products aus Niedernberg kommt eigentlich aus einer anderen Ecke, dem Desaster Recovery. Allerdings ist dieses Gebiet von der P2V-Migration nicht weit entfernt. Auch hier wird quasi ein abgeschaltetes System auf neuer Hardware wiederhergestellt.

Cristie besitzt mit "Dissimilar Hardware Servers" eine Erweiterung des bekannten Desaster Recovery und kann ein gesichertes System über eine Treiberanpassung auf einer anderen Hardware wiederbeleben.

Durch diese Funktion eignet sich das Produkt unabhängig vom Virtualisierungssystem ebenfalls sehr gut für P2V-Zwecke. Eine Linux-Unterstützung existiert zwar für Desaster Recovery, leider aber ohne die Dissimilar-Hardware-Option, wodurch man sich an eine mitgelieferte manuelle Anleitung halten muss.

Cristie CBMR setzt entweder auf einer vorhandenen Backup-Software auf ("Tivoli TSM" von IBM) oder nutzt das lokal angeschlossene Bandlaufwerk. Optional kann eine komplette oder inkrementelle Sicherung gewählt werden. Dies bietet den Vorteil, dass bei einer 20-GB-Festplatte mit 25-prozentiger Belegung nur 5 GB zu sichern sind.

Die Rücksicherung leitet der Systemverwalter über eine Boot-CD ein, die auf Linux basierend, eine eigene Oberfläche startet. Nach dem eigentlichen Restore startet man über das Menü den Dissimilar Hardware Server. Nun muss der Administrator auf einem beliebigen Windows-System eine kleine ausführbare Datei starten (welche auf der Website zum Download bereitsteht) und kann sich dann mit dem Dissimilar Hardware Server verbinden und beliebige Windows-.inf-Treiberdateien einspielen.

Sobald dieser Prozess abgeschlossen ist, lässt sich die Ziel-VM starten. Um alle Berechtigungen wiederherzustellen, muss über die Cristie-Oberfläche zwingend eine Rücksicherung auf des Zielsystems angestoßen werden.

Microsoft VSMT

Microsofts "VSMT" (Virtual Server Migration Tool) ist das einzige kostenfreie Produkt im Feld. Es nutzt einen PXE-Boot, womit man sich in manch produktiver Umgebung eine blutige Nase holt, wenn dort auch eine Softwareverteilung läuft (es darf pro Netzwerksegment nur ein PXE-Server existieren, daher muss gegebenenfalls eine Trennung über Router oder VLANs erfolgen). VSMT ist eher eine Mischung aus verschiedenen Diensten und Skripten aus dem Microsoft-Fundus, die mehr oder weniger zusammenspielen und zwingend manuelle Eingriffe erfordern. Zu den erwähnten Diensten gehört auch der "Application Deployment Service", welcher nur mit Windows 2003 Enterprise oder dem Datacenter Server funktioniert. Wenn ein solcher Server nicht im Haus ist, wird das an sich kostenlose Tool sehr teuer.