bl0cks1z3
Goto Top

ESX 5.5 große virtuelle Disk verschieben ohne online Migration?

Hallo Admins,

ich muss wegen Speicherproblemem eine ca. 6TB große virtuelle Disk auf einen andern Store verschieben. Ich habe leider und die Essentials-Version, also ohne Online-Migration.
Ich müsste also die virtuelle Maschine herunterfahren, um die Migration durchführen zu können.
Das Problem ist, dass die virtuelle Maschine aber auch unser Domänen-Controller, DNS- und DHCP-Server ist und der Migrationsvorgang sicherlich eine ganze Zeit benötigen wird.

Meine Idee ist es nun die Disk (Laufwerk F auf dem Server) irgendwie offline zu schalten und temporär an eine andere virtuelle Maschine anzuhängen.
Dann die Migration durchzuführen und das Ganze dann wieder zurückzudrehen. Oder vielleicht auch gleich den Speicher über den anderen Server zur Verfügung zu stellen.

Ich habe das aber noch nie so gemacht und fürchte, dass ich einen Fehler mache und alle Daten verliere.
Natürlich habe ich eine Datensicherung, aber selbst das Wiederherstellen der Daten dürfte ein ganzes We dauern - wenn nicht sogar noch länger.

Deshalb möchte ich mir von Euch ein paar Tipps holen, vielleicht hat ja jemand von Euch so was schon mal durchgeführt.

Vielen Dank!

PS: Das ich während der Migration nicht auf die Daten zugreifen kann ist mir natürlich bewußt. Deshalb habe ich mir das Pfingstwochenende vorgenommen.

Content-ID: 373236

Url: https://administrator.de/contentid/373236

Ausgedruckt am: 24.11.2024 um 19:11 Uhr

sabines
sabines 07.05.2018 aktualisiert um 08:03:16 Uhr
Goto Top
Moin,

Du hast doch sicher einen zweiten DC, der in der Downtime die Aufgaben größtenteils übernehmen könnte?
Dann kannst Du das Verschieben ohne Kniffe durchführen.

Meine Idee ist es nun die Disk (Laufwerk F auf dem Server) irgendwie offline zu schalten und temporär an eine andere virtuelle Maschine anzuhängen.

Wie stellst Du Dir das vor? Du kannst doch nicht einfach einen Server an eine andere VM anhängen?

Gruss
Bl0ckS1z3
Bl0ckS1z3 07.05.2018 um 08:09:35 Uhr
Goto Top
Hallo sabines,

ja habe natürlich noch 2 andere DC. Aber auf dem Server laufen auch noch andere Dienste, auf die ich so lange nicht verzichten möchte.
Da ich ja auch nicht 100% weiß wie lange die Migration laufen wird.
Könnte ja vielleicht sein, dass ich in die produktive Zeit reinkomme.

Also mir wäre wohler, wenn meine erste Idee umsetzbar wäre.
Der Datenspeicher kann ruhig mal 2 - 3 Tage fehlen. Der ganze Server ist eher schwierig.

Danke!
Lochkartenstanzer
Lochkartenstanzer 07.05.2018 aktualisiert um 08:17:26 Uhr
Goto Top
Zitat von @Bl0ckS1z3:

Also mir wäre wohler, wenn meine erste Idee umsetzbar wäre.
Der Datenspeicher kann ruhig mal 2 - 3 Tage fehlen. Der ganze Server ist eher schwierig.


Einfach suf einer Testmaschine vorher ausprobiere. face-smile

Und Backup nicht vergessen.

lks

PS: Ich würde einfach auf dem neuen Store eine Virtuelle HDD erstellen, die in die VM einbinden und innerhalb der VM die Daten verschieben.

Danach kann man die "alte" Platte freigeben und entfernen.

Das könnte man z.B. einem Software-Raid1 innerhalb der VM sogar im laufenden Betrieb machen.
Bl0ckS1z3
Bl0ckS1z3 07.05.2018 um 08:16:34 Uhr
Goto Top
Also ich habe jetzt erst einmal folgende Informationen zusammengetragen:

Hinzufügen einer vorhandenen Festplatte zu einer virtuellen Maschine

https://docs.vmware.com/de/VMware-vSphere/6.0/com.vmware.vsphere.vm_admi ...

Bedingungen und Einschränkungen bezüglich großer virtueller Festplatten

https://docs.vmware.com/de/VMware-vSphere/6.0/com.vmware.vsphere.vm_admi ...

Entfernen einer Festplatte

https://docs.vmware.com/de/VMware-Fusion/8.0/com.vmware.fusion.using.doc ...

Vielleicht sollte ich es einfach mal mit 2 Testsystemen durchspielen.

Trotzdem, wer noch gute Ideen hat immer her damit.

Danke.
SeaStorm
SeaStorm 07.05.2018 aktualisiert um 09:40:03 Uhr
Goto Top
Also ganz platt gesagt:
Wenn der Chef keine Downtime haben will, muss er das Geld für EssentialsPlus oder Standard in die Hand nehmen. Dann ist das kein Problem.
Evtl. kannst du ja eine kurzzeitige Trialzeit dafür noch aktivieren?

Wäre das jetzt kein DC, würde ich sagen du machst ein Backup der Maschine und stellst das per Instant Recovery auf dem neuen Store wieder her. Alte VM stoppen und neue hochfahren. Warten bis Recovery durch ist und alte VM entfernen.
Aber: Du hast den üblen Fehler begangen einen DC auch noch mit anderen Diensten zu belegen. Das ist ein NoGo und dafür bekommst du jetzt die Quittung.

Also mein Vorschlag:
Neue VM machen, zum DC erheben, Bisherige VM den DC demoten.
Backup machen, INstantrecovery auf neuem Store usw
Penny.Cilin
Penny.Cilin 07.05.2018 um 09:04:15 Uhr
Goto Top
Hallo,

oder eine leere VMDK mit entsprechender Größe erstellen. Diese an das System anbinden. Backup auf der neuen VMDK wiederherstellen.
Dann mittels Robocopy die Daten der 6 TB Platte auf die erstellte VMDK synchen, damit man die aktuellen Daten hat.

Gruss Penny.
Lochkartenstanzer
Lochkartenstanzer 07.05.2018 aktualisiert um 09:12:59 Uhr
Goto Top
Zitat von @Penny.Cilin:

Dann mittels Robocopy die Daten der 6 TB Platte auf die erstellte VMDK synchen, damit man die aktuellen Daten hat.

Oder wie ich oben schon sagte, gleich die neue VMDK per RAID1 befüllen. face-smile

lks
em-pie
em-pie 07.05.2018 aktualisiert um 09:31:28 Uhr
Goto Top
Moin,

welche Daten liegen denn auf deiner 6TB großen vDisk?

Folgenden Aussage entnehme ich, dass es "lediglich" Daten eines Gruppenlaufwerkes sind, auf die du ggf. 2-3 Tage verzichten könntest:
Meine Idee ist es nun die Disk (Laufwerk F auf dem Server) irgendwie offline zu schalten und temporär an eine andere virtuelle Maschine anzuhängen.
Der Datenspeicher kann ruhig mal 2 - 3 Tage fehlen. Der ganze Server ist eher schwierig.

Wenn dem so ist (also reiner Content eines File-Servers), hättest du zwei Möglichkeiten:

Variante 1 (Die Quick 'n' Dirty):
Die Disk (wie von dir vorgeschlagen) über den vSPhere Client entfernen (aber nicht vom DataStore löschen), die vDisk verschieben und wenn alles fertig, vom neuen Ort wieder einbinden.

Variante 2 (basierend auf bereits genannte Lösungen):
  • Freigaben des alten Server exportieren: https://www.team-debold.de/2014/08/09/windows-freigaben-umziehen/
  • Neue VM hochziehen, die Disk auf dem "alten" Server wieder entfernen und an den neuen Server anhängen.
  • Die Freigaben anpassen:
    • Die vDisk am neuen Server mit dem selben Laufwerksbuchstaben versehen.
    • Freigaben am euen Server importieren (zuvor ggf. unnötiges aus der exportierten registry-Datei entfernen)
  • LoginSkripte/ GPOs auf den neuen Servernamen anpassen

Beides klappt aber zunächst nur Fehlerfrei, wenn keine anderen lebenswichtigen Dienste auf der 6TB großen vDisk abgelegt sind.
Btw: Würde ich ggf. sogar mal schauen, ob man die 6TB nicht im Rahmen des Umzuges in 3-4 kleinere vDisks gesplittet bekommt. Ist aber meine persönliche Meinung. Denn kleinere DIensk lassen sich besser handhaben.

Gruß
em-pie
STITDK
STITDK 07.05.2018 um 11:35:23 Uhr
Goto Top
Servus,

Variante 3(VEEAM Vorrausgesetzt)

Du machst ein Replica auf ein ein anderen Storage, Initial dürfte das etwas dauern, aber ok. Der Abgleich der Daten sollte dann recht schnell innerhlab von 2-3 Stattfinden.


Danach ist einfach dein Replica die neue VM. Nicht die schönste Variante aber sie Funktioniert.


Grüße STITDK

PS: Steinigt mich nicht ;)
Bl0ckS1z3
Bl0ckS1z3 16.05.2018 um 13:16:10 Uhr
Goto Top
Hallo wollte mich noch mal melden.

Habe nun ein Produkt gefunden Paragon Protect & Restore. Das kann auch mit der normalen ESX-Essentials virtuelle Maschinen zwischen den ESX replizieren.
Die Produktvideos sehen sehr vielversprechend aus und preislich ist die Sache auch OK.
Ich habe mir erst einmal die Eval angefordert

Wenn die Software so gut wie in den Produkt-Videos funktioniert, würde ich sogar Backup Exec dadurch ablösen.

Toll finde ich, dass es vollständigen deutschen Support gibt und man nicht nach Vietnam oder sonst wohin telefonieren muss.
Ich kann zwar ganz passabel Englisch, aber wenn der Techniker dort ein Headset auf hat und seinen Akzent mit reinbringt ist das wirklich nicht einfach.