VMware-Forum

Hallo,

wir haben vor einen Server mit einigen Partitionen und entsprechend viel Daten (knapp 2TB) zu migrieren. Wir haben dazu schon einmal einen Testlauf auf einen temporären ESXi 4.1 gemacht. Dieser soll den migrierten Server "empfangen", dann wird er kurz getestet und anschließend wird der migrierte Host selbst ESXi Server und bekommt dann das migrierte OS (Win2k3 64-bit).

Im ersten Testlauf dauerte die Migration (VMware Converter) schon sehr lang (ich kann leider keine Zeit nennen) und brach irgendwann bei 42% ab. Der temporäre ESXi wurde dabei irgendwie in Mitleidenschaft gezogen. Die VMs die da drauf liefen (nicht produktiv) sind nämlich alle ausgestiegen, das heißt sie waren nicht mehr ansprechbar. Wir konnten die VMs auch nicht stoppen, auch nicht über die Konsole. Wir haben am Ende den Reset-Knopf des Servers bedient. Der ESXi fuhr wieder korrekt hoch und die VMs auch.


Jetzt meine Frage ...
Wie können wir den Server "besser" migrieren? Problem dabei ist, dass wir kaum Ausfallzeit hinnehmen können.

Ich habe schon von einer Möglichkeit des Cold Clone gelesen. Dies kommt aber kaum in Frage, da zuviel Ausfallzeit. Wir müssen das aber noch entgültig diskutieren.

Ist die Cold Clone ISO CD frei erhältlich und mit einem Win2k3 64-bit nutzbar?

Der aktuelle Host hat einige Partitionen in einem RAID 5. Wie kann ich die Partitionen sinnvoll in einzelne VMDKs migrieren (ich will die VMDKs nicht partitionieren)? Muss ich dafür jeweils einen Converter-Job anlegen und dabei immer nur eine Partition auswählen und diese in eine VMDK konvertieren lassen?

Wenn ich den Host irgendwann mal final migriere, würde ich gerne zu einer beliebigen Zeit X schon mal den zu diesem zeitpunkt aktuellen Datenbestand migrieren und dann später nochmal "synchronisieren" mit dem Stand bevor wir ihn dann endgültig abschalten. Gibt es so eine Möglichkeit?

Wer bis zu dieser Zeile mit Lesen schon gekommen ist, dem danke ich für die Aufmerksamkeit und Zeit und würde mich noch mehr über ein paar Antworten freuen. Vielen Dank!

Viele Grüße, Tom

Hallo pauLee,

also knapp 2TB sind ja schon mal ne Hausnummer.
Was läauft denn alles so auf der physikalischen Maschine?
Steckt in den knapp 2TB viel an "Bewegungsdaten" drin die sich ständig ändern?

Hast du als Alternative schon mal darüber nachgedacht eine VM parallel zu deiner physikalischen Maschine zu installieren,
auf dieser alle deinen genutzten Produkte zu installieren, und den gesamten Server "nach Möglichkeit" identisch zu konfigurieren?

Dann könntest du evtl. die Daten per Robcopy auf die VM schieben und müsstest zum Schluss nur noch einmal das letzte Delta übertragen
die phy. Maschine ausschalten, der VM den gleichen Namen und die gleiche IP wie der phy. Maschine geben und los geht's.

Ablauf nochmal der Reihe nach (ist nur ne Idee):
- VM installieren inkl. aller benötigter Software
- Software und OS soweit möglich identisch wie Phy. Maschine konfigurieren
- Daten per Robocopy nach und nach rüber schieben
- alle Dienste auf der phy. Maschine beenden
- per Robocopy das letzte Delta übertragen
- phy. Maschine aus der Domäne entfernen und ausschalten
- der VM den Namen und die IP der phy. Maschine verpassen
- Neustart der VM und hoffen dass alles drüben ist

Der Converter ist sicherlich oft die bequemere Möglichkeit, aber gerade bei einer so großen Daten Menge und der wie du sagst
nicht aktzeptablen Ausfallzeit beim ColdClone ist es evtl. ratsam andere Varianten ins Auge zu fassen.

Alles natürlich nur ein Gedankespiel von mir, allerdings haben wir hier eben auch schn gelgentlich auf Robocopy zurück gegriffen,
und das hat zumindest bei uns soweit gut funktioniert.

Obs für deine Umgebung praktikabel ist wirst du wohl nur selbst entscheiden können.

Gruß
Stefan

straight_way hat geschrieben:Hallo pauLee,

also knapp 2TB sind ja schon mal ne Hausnummer.
Was läauft denn alles so auf der physikalischen Maschine?
Steckt in den knapp 2TB viel an "Bewegungsdaten" drin die sich ständig ändern?

Hast du als Alternative schon mal darüber nachgedacht eine VM parallel zu deiner physikalischen Maschine zu installieren,
auf dieser alle deinen genutzten Produkte zu installieren, und den gesamten Server "nach Möglichkeit" identisch zu konfigurieren?

Dann könntest du evtl. die Daten per Robcopy auf die VM schieben und müsstest zum Schluss nur noch einmal das letzte Delta übertragen
die phy. Maschine ausschalten, der VM den gleichen Namen und die gleiche IP wie der phy. Maschine geben und los geht's.

Ablauf nochmal der Reihe nach (ist nur ne Idee):
- VM installieren inkl. aller benötigter Software
- Software und OS soweit möglich identisch wie Phy. Maschine konfigurieren
- Daten per Robocopy nach und nach rüber schieben
- alle Dienste auf der phy. Maschine beenden
- per Robocopy das letzte Delta übertragen
- phy. Maschine aus der Domäne entfernen und ausschalten
- der VM den Namen und die IP der phy. Maschine verpassen
- Neustart der VM und hoffen dass alles drüben ist

Der Converter ist sicherlich oft die bequemere Möglichkeit, aber gerade bei einer so großen Daten Menge und der wie du sagst
nicht aktzeptablen Ausfallzeit beim ColdClone ist es evtl. ratsam andere Varianten ins Auge zu fassen.

Alles natürlich nur ein Gedankespiel von mir, allerdings haben wir hier eben auch schn gelgentlich auf Robocopy zurück gegriffen,
und das hat zumindest bei uns soweit gut funktioniert.

Obs für deine Umgebung praktikabel ist wirst du wohl nur selbst entscheiden können.

Gruß
Stefan

Hallo Stefan,

deine Gedanken sind sehr gut. An Robocopy habe ich bei einem Teil der Daten auch schon dran gedacht. Das würde die größte Partition betreffen.

Was nicht funktioniert ist eine nahezu identische VM daneben zu installieren, da es sich um den Domain Controller handelt. Damit ist diese Idee aus dem Rennen. Ich werde wohl den Converter bemühen müssen.

Im Grunde bestätigst du mir aber in etwa meine Gedanken die ich schon hatte einen Teil der Daten mit Robocopy zu migrieren. Ich brauche jetzt nurnoch einen sinnvollen Weg die ganzen Partitionen aus dem RAID in einzelne VMDKs zu konvertieren.


Grüße, Tom

Ich würde an deiner Stelle DC und Files auf neue Server trennen.

Files einfach mittels dem File Server Migration Toolkit auf den neuen Fileserver übertragen, hat bisher bei uns immer geklappt:
http://www.microsoft.com/downloads/deta ... layLang=de

Hat den Vorteil das man den neuen Fileserver beliebig vorkonfigurieren kann (Anzahl und Größe der vmdks) und über das FSMT nur noch die Daten wie gewünscht migriert.

Den DC kannst du dann ja auch relativ einfach auf einen neuen Server migrieren:

neuen Server zum dc promoten
dhcp/dns verschieben/konfigurieren
global catalog verschieben
efs übertragen (falls genutzt)
alten DC herabstufen

konvertieren eines Domain Controllers kann (bzw. wird mit an Sicherheit grenzender Wahrscheinlichkeit) ins Auge gehen,
spätestens dann, wenn du das ganze nicht im Cold sonder Hot Clone Verfahren machst.

Also scheidet der Converter m.E.nach sowieso aus.

In Sofern würde ich dir auch empfehlen das ganze ein wenig aufzuteilen.

Wie diego schon geschrieben hat, würde ich mir auch eine VM als DC installieren, den dann promoten und alle AD Rollen
übernehmen lassen (du solltest dich aber entsprechend schlau machen wie das genau zu funktionieren hat, denn das kann ich dir leider auch nicht im Detail erklären).
Dann deiner phy. Maschine die DC Rollen weg nehmen.

Damit wärst du schon mal das erste "Übel" los.

Und beim Transfer der großen Datenmengen würde ich nach wie vor bei Robocopy bleiben. Wenn es sich um unterschiedliche
Anwendungsbereiche handelt, könntest du so auch Funktion um Funktion nach einander auf eine 2.te VM übertragen und dann auch
schon produktiv schalten. So hättest du kleinere Happen und müsstest nicht alles in einm großen "kalten" Schlag durchziehen.
Außerdem wärst dann auch das Problem "Partition auf einzelne vmdks migrieren" los, da du ja die virtuellen Festplatten dann schon angelegt hättest.

Mal abgesehen vom o.g. würde ich es mir eh überlegen eine einzige VM mit allen Möglichen (und offensichtlich Speicherplatz hungrigen)
Anwendungen/Funktionen zu betreiben und im Zweifelsfall lieber ein paar mehr kleinere VMs bauen.
Das macht dir auch so Sachen wie Backup/Restore leichter

Gruß Stefan

Hallo,

RoboCopy ist wirklich nicht übel, hat aber einen nicht unerheblichen Nachteil.
Es kopiert die Daten nur mit einem Thread, und das verzögert die Migration großer Datenmengen ganz gewaltig.

RichCopy dagegen verwendet mehrere Threads und bietet darüber hinaus den gleichen Funktionsumfang wie RoboCopy.
RichCopy bulk file copy tool released – get it here

Ich empfehle auch, nicht mit der Migration der Daten zu beginnen, sondern zuerst nur die Directory Strukturen anlegen zu lassen.
Das hat bei großen Partitionen den entscheidenden Vorteil, das die komplette Verzeichnisstruktur sequentiell gelesen werden kann.
Für den User fühlt sich so ein Filesystem daher deutlich schneller an, da der Explorer die Datei und Vezeichnisinformationen schneller anzeigt.

Viel Erfolg beim Umzug.
Ralf

wie wäre es mit dfs, dadurch könntest du die Daten ohne downtime immer zur verfügung stellen, nach dem sync den alten server downgrade und vom dfs rausnehemen. davor natürlich einen zweiten dc aufsetzen, alle fsmo rollen auf den neuen dc verschieben und den alten downgraden.

DFS ist auch eine gute Idee, macht das Umschalten erheblich einfacher und mann muss den zugreifenden Geräten keine neuen Pfade unterjubeln.
Allerdings würde ich bei DFS nicht auf die integrierte Replikation vertrauen.
Meines Wissens nach gibt es da (zumindest war das unter W2k3 so) doch Probleme bei großen Datenmengen (die ja hier zweifelsohne vorliegen).

Gruß stefan