7
Migration von XenServer zu Hyper-V 2
Hallo,
ich habe vor unsere Server Infrastruktur bestehend aus:
- Windows Server 2008 R2 Exchange Server 2010
- Windows Server 2008 R2 FileServer
- Windows Server 2008 R2 SQL Server 2008
- Windows Server 2008 R2 DPM Server 2010
- Windows Server 2008 R2 Domain Controller
von unserem Citrix XenServer auf Windows Server 2008 R2 Hyper-V zu migrieren.
Ich mache jeden Mittwoch und Freitag ein komplettes Backup der jeweiligen VMs mittels Windows Server Sicherung auf einer externer USB Festplatte.
Hierbei habe ich einige Fragen:
1. Die Sicherung soll dann zum Migrieren in das Netzwerk auf eine NAS und dann mittels Windows Server 2008 R2 ISO und Reparaturoption Wiederhergestellt werden. Ist das Problemlos möglich? Ist dieser Weg der richtige?
2. Ich möchte nun bevor ich mit dem Migrieren anfange, wissen, auf welche Stolperfallen ich zb bei dem Exchange Server und SQL Server achten muss.
3. Die XenServer Tools möchte ich dann nach dem Wiederherstellen entfernen und mit den HyperV Integrationsdiensten aktualisieren. gibt es hier noch Dienste oder Hardware (virtuelle) welche ich noch entfernen muss?
Habt Ihr erfahrungen? Könnt Ihr mir Tips geben, sodass ich erfolgreich und ohne komplikationen Migrieren kann?
Vielen Dank für eure Antworten
ich habe vor unsere Server Infrastruktur bestehend aus:
- Windows Server 2008 R2 Exchange Server 2010
- Windows Server 2008 R2 FileServer
- Windows Server 2008 R2 SQL Server 2008
- Windows Server 2008 R2 DPM Server 2010
- Windows Server 2008 R2 Domain Controller
von unserem Citrix XenServer auf Windows Server 2008 R2 Hyper-V zu migrieren.
Ich mache jeden Mittwoch und Freitag ein komplettes Backup der jeweiligen VMs mittels Windows Server Sicherung auf einer externer USB Festplatte.
Hierbei habe ich einige Fragen:
1. Die Sicherung soll dann zum Migrieren in das Netzwerk auf eine NAS und dann mittels Windows Server 2008 R2 ISO und Reparaturoption Wiederhergestellt werden. Ist das Problemlos möglich? Ist dieser Weg der richtige?
2. Ich möchte nun bevor ich mit dem Migrieren anfange, wissen, auf welche Stolperfallen ich zb bei dem Exchange Server und SQL Server achten muss.
3. Die XenServer Tools möchte ich dann nach dem Wiederherstellen entfernen und mit den HyperV Integrationsdiensten aktualisieren. gibt es hier noch Dienste oder Hardware (virtuelle) welche ich noch entfernen muss?
Habt Ihr erfahrungen? Könnt Ihr mir Tips geben, sodass ich erfolgreich und ohne komplikationen Migrieren kann?
Vielen Dank für eure Antworten
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 191866
Url: https://administrator.de/forum/migration-von-xenserver-zu-hyper-v-2-191866.html
Ausgedruckt am: 25.12.2024 um 13:12 Uhr
7 Kommentare
Neuester Kommentar
Sers,
vorab: Lass den 2008r2 in der Ecke liegen und nimm gleich den 2012er Hyper-V Server ran.
-> DC-bewusstheit (Leider nur bei 2012+ DC)
-> SMB3.0
-> (Shared-Nothing) Livemigration, auch ohne Cluster
-> Teaming-NIC Modell lässt sich QoS in deinem virtuellen Switch machen, Teaming auf Hypervisorebene und unabhänig von den NICs (z.B. aus 2 Broadcom, 1 Dlink und 1 Intel mit je 1Gbit ergeben Gesamtbandbreite von bis zu 4Gbit und nicht 4x1Gbit)
-> bessere Clusterdienste
-> wesentlich bessere Replikation
-> leichtere Verwaltbarkeit über PowerShell
-> VHDX Format erlaubt dir dynamische virtuelle Festplatten mit fast inexistentem Performanceverlust (im Gegensatz zu ~5% bei VHD) und viele andere Verbesserungen wie TRIM Unterstützung, etc, etc, pp
-> Bessere Cloningmechanismen, robusterer VM-Import
-> Mehr Ressourcen stehen bereit für VMs
-> RemoteFX kann emuliert werden
-> Mehr Möglichkeiten der Speicheranbindung (e.g. FC, StoragePools)
-> Stark verbessertes Fail-Over
...uvm.
Einziger "Nachteil": du brauchst nen Win8 wenn du die Kiste bunt über RSAT administrieren willst.
Zur Migrationsfrage:
Ich würde die VMs via Xen-Center exportieren, passende Hyper-V-VMs bauen, die exportierten VHDs in die passenden VMs integrieren (Boot-VHD muss als IDE integriert werden) und gut ist.
Ginge alternativ auch direkt über den XenConvert, aber ob das mit ner LiveVM geht kann ich dir nicht sagen: http://www.mytechrants.com/2011/06/24/converting-citrix-xva-file-to-mic ...
:edit: wenn du z.B. iSCSI-Targets als Speicherbenutzt kannst dir die VHDs natürlich sparen.
Solltest du beim 2008r2 Hyper-V Server bleiben, und deine VMs alle mit SP1 bespielt sind bringen die ihre Integrationstools selbst schon mit.
Wenn alles läuft kannst die XenTools dann runterwerfen.
Dran denken das VHDs nur bis 2 TB fassen können, VHDX iirc bis 64 TB.
Hoffe das hilft dir weiter,
Grüße,
Philip
vorab: Lass den 2008r2 in der Ecke liegen und nimm gleich den 2012er Hyper-V Server ran.
-> DC-bewusstheit (Leider nur bei 2012+ DC)
-> SMB3.0
-> (Shared-Nothing) Livemigration, auch ohne Cluster
-> Teaming-NIC Modell lässt sich QoS in deinem virtuellen Switch machen, Teaming auf Hypervisorebene und unabhänig von den NICs (z.B. aus 2 Broadcom, 1 Dlink und 1 Intel mit je 1Gbit ergeben Gesamtbandbreite von bis zu 4Gbit und nicht 4x1Gbit)
-> bessere Clusterdienste
-> wesentlich bessere Replikation
-> leichtere Verwaltbarkeit über PowerShell
-> VHDX Format erlaubt dir dynamische virtuelle Festplatten mit fast inexistentem Performanceverlust (im Gegensatz zu ~5% bei VHD) und viele andere Verbesserungen wie TRIM Unterstützung, etc, etc, pp
-> Bessere Cloningmechanismen, robusterer VM-Import
-> Mehr Ressourcen stehen bereit für VMs
-> RemoteFX kann emuliert werden
-> Mehr Möglichkeiten der Speicheranbindung (e.g. FC, StoragePools)
-> Stark verbessertes Fail-Over
...uvm.
Einziger "Nachteil": du brauchst nen Win8 wenn du die Kiste bunt über RSAT administrieren willst.
Zur Migrationsfrage:
Ich würde die VMs via Xen-Center exportieren, passende Hyper-V-VMs bauen, die exportierten VHDs in die passenden VMs integrieren (Boot-VHD muss als IDE integriert werden) und gut ist.
Ginge alternativ auch direkt über den XenConvert, aber ob das mit ner LiveVM geht kann ich dir nicht sagen: http://www.mytechrants.com/2011/06/24/converting-citrix-xva-file-to-mic ...
:edit: wenn du z.B. iSCSI-Targets als Speicherbenutzt kannst dir die VHDs natürlich sparen.
Solltest du beim 2008r2 Hyper-V Server bleiben, und deine VMs alle mit SP1 bespielt sind bringen die ihre Integrationstools selbst schon mit.
Wenn alles läuft kannst die XenTools dann runterwerfen.
Dran denken das VHDs nur bis 2 TB fassen können, VHDX iirc bis 64 TB.
Hoffe das hilft dir weiter,
Grüße,
Philip
Ja das hilft mir schon weiter.
Ich würde aber gerne:
1. Bei Windows Server 2008 R2 bleiben und Server 2012 besser kennenlernen.
2. Die Sicherung mittels Windows Server Sicherung sichern, denn diesen Umweg über irgendwelche Converter ist mir zu unsicher.
3. Ist es denn ratsam mit SRV 2012 Produktiv zu arbeiten?
Gruß
Ich würde aber gerne:
1. Bei Windows Server 2008 R2 bleiben und Server 2012 besser kennenlernen.
2. Die Sicherung mittels Windows Server Sicherung sichern, denn diesen Umweg über irgendwelche Converter ist mir zu unsicher.
3. Ist es denn ratsam mit SRV 2012 Produktiv zu arbeiten?
Gruß
Also die Tests die ich bisher mit dem HVS2012 am Laufen hatte sind soweit in Ordnung und stabil.
Kannst ja gern bei den VMs auf 2008r2 bleiben. Bei meiner Empfehlung ging es nur um den Unterbau, also den Hyper-V Server.
Die VMs via Sicherungsrückspielung zu füllen ist natürlich ein legitimer Weg, auch wenn er etwas länger ist. Im Endeffekt entscheidest du womit du komfortabel bist. Kannst dir über den Rücksicherungsweg natürlich sicher sein dass die VHD(X) die du befüllst auch wirklich sauber erstellt wurde und ist.
Wie gesagt, wenn das Storage via iSCSI in die VMs reingeht kannst dir das VHD-befüll-Drama sparen.
Was du machen kannst: Steig erstmal wie geplant auf den Hyper-V Server 2008r2 als Hypervisor um, und teste nebenbei auf ner separaten Kiste den 2012er HVS. Die VMs kannst du dann testweise mal auf den 2012er schieben und schaun wie es dir gefällt.
Der finale Umstieg ist dann problemlos möglich.
Grüße,
Philip
Kannst ja gern bei den VMs auf 2008r2 bleiben. Bei meiner Empfehlung ging es nur um den Unterbau, also den Hyper-V Server.
Die VMs via Sicherungsrückspielung zu füllen ist natürlich ein legitimer Weg, auch wenn er etwas länger ist. Im Endeffekt entscheidest du womit du komfortabel bist. Kannst dir über den Rücksicherungsweg natürlich sicher sein dass die VHD(X) die du befüllst auch wirklich sauber erstellt wurde und ist.
Wie gesagt, wenn das Storage via iSCSI in die VMs reingeht kannst dir das VHD-befüll-Drama sparen.
Was du machen kannst: Steig erstmal wie geplant auf den Hyper-V Server 2008r2 als Hypervisor um, und teste nebenbei auf ner separaten Kiste den 2012er HVS. Die VMs kannst du dann testweise mal auf den 2012er schieben und schaun wie es dir gefällt.
Der finale Umstieg ist dann problemlos möglich.
Grüße,
Philip
Vielen Dank,
genau das habe ich vor.
Ich werde Produktiv erstmal den HVS 2008 R2 in betrieb nehmen und dann ist es ja ein kinderspiel die VMs zu HVS 2012 zu migrieren.
Hauptsache ich komme erstmal von dem XenServer weg.
Wie schauts denn aus, ich lese häufiger, dass bei einer Windows Server Sicherung von Exchange Servern bei Erweiterte Einstellungen das Vollständige VSS Sicherung eingestellt werden "MUSS".
Hier sichert der VSS die komplette Größe der Source-Festplatte und auch den "leeren Platz". Macht das sinn?
Muss ich darauf beim Migrieren achten?
genau das habe ich vor.
Ich werde Produktiv erstmal den HVS 2008 R2 in betrieb nehmen und dann ist es ja ein kinderspiel die VMs zu HVS 2012 zu migrieren.
Hauptsache ich komme erstmal von dem XenServer weg.
Wie schauts denn aus, ich lese häufiger, dass bei einer Windows Server Sicherung von Exchange Servern bei Erweiterte Einstellungen das Vollständige VSS Sicherung eingestellt werden "MUSS".
Hier sichert der VSS die komplette Größe der Source-Festplatte und auch den "leeren Platz". Macht das sinn?
Muss ich darauf beim Migrieren achten?
Windows Server Sicherung (Im Prinzip mal ne Image Sicherung) & VSS & Exchange: Verhält sich wie mit jeder anderen Datenbankanwendung auch. Es wird ein Zeitpunkt X festgelegt. Zu dem Zeitpunkt wird ein VSS-Snapshot erstellt. Alle Änderungen nach diesem Zeitpunkt werden nicht mehr für die Sicherung berücksichtigt. VSS stellt damit sicher dass Daten, die nach Zeitpunkt X überschrieben wurden, trotzdem später mit dem Inhalt von Zeitpunkt X gesichert werden können. Sonst hättest du ja z.B. Inkonsistenzen zwischen DB und Transaktionslog. Fatal!
Also, ja, wenn du die Windows Server Sicherung bemühst *MUSS* VSS dabei genutzt werden. Bzw. wird eigentlich sowieso immer von der genutzt.
Vollständig weil du da einfach keine Inkrementelle Sicherung willst. Viel zu viel Spielraum für Probleme.
Im Fall vom Exchange muss du dir überlegen ob du Exchange nicht über die Exchangesicherung backuppen willst, statt dich auf die Windows Server Sichrung zu verlassen. Das leidige Thema "richtige Datensicherung" vs. "Image-Sicherung" eben.
Also, ja, wenn du die Windows Server Sicherung bemühst *MUSS* VSS dabei genutzt werden. Bzw. wird eigentlich sowieso immer von der genutzt.
Vollständig weil du da einfach keine Inkrementelle Sicherung willst. Viel zu viel Spielraum für Probleme.
Im Fall vom Exchange muss du dir überlegen ob du Exchange nicht über die Exchangesicherung backuppen willst, statt dich auf die Windows Server Sichrung zu verlassen. Das leidige Thema "richtige Datensicherung" vs. "Image-Sicherung" eben.
Okay, Danke.
also ist es mit der VSS Sicherung von Windows Server möglich eine Datenbank bzw Exchange zu sichern und Wiederherzustellen? Was passiert wenn Transaktionslog und Datenbank nicht zueinanderpassen, musste ich schon erfahren... NICHT LUSTIG
Deshalb meine Frage und ich muss mir der Sache wirklich "Sicher" sein.
Mit dem SQL Datenbank-Server habe ich nun ein Testlauf hinter mir.
Es sieht also so aus, dass die Migration / Der Test erfolgreich war.
Jedoch bin ich mir, wie gesagt bei Exchange, nicht ganz so sicher, da ich schon wie oben geschrieben, Probleme hatte.
Gruß
also ist es mit der VSS Sicherung von Windows Server möglich eine Datenbank bzw Exchange zu sichern und Wiederherzustellen? Was passiert wenn Transaktionslog und Datenbank nicht zueinanderpassen, musste ich schon erfahren... NICHT LUSTIG
Deshalb meine Frage und ich muss mir der Sache wirklich "Sicher" sein.Mit dem SQL Datenbank-Server habe ich nun ein Testlauf hinter mir.
Es sieht also so aus, dass die Migration / Der Test erfolgreich war.
Jedoch bin ich mir, wie gesagt bei Exchange, nicht ganz so sicher, da ich schon wie oben geschrieben, Probleme hatte.
Gruß
Sicher ist es einigermaßen. Wie gesagt, was du bekommst ist ein Image eines Zustandes im Livebetrieb. Ein Datensatz der zum Zeitpunkt X nur zur Hälfte in der Datenbank ist, e.g. weil die WAN-Leitung lahm ist, der wird dann auch bei der Wiederherstellung nur zur Hälfte drin sein.
Im Allgemeinen geht das in Ordnung, aber wirklich sicher ist es eigentlich nur wenn du die Sicherungsfunktionen der entsprechenden Datenbanken verwendest.
Auf der anderen Seite: Ich führ mindestens monatlich ein Testrestore für einen 2008er SBS durch der mit Acronis (Image, GVS) gesichert wird. Im Zusammenhang mit Exchange ist da noch nie ein Problem aufgetreten.
Zu DB & Transaktionslog: Wenn das Log vollständig ist reicht es ja die UrsprungsDB zu packen und die Transaktionen drüber laufen zu lassen. Klar, kann ewig brauchen, aber zumindest kriegst so wieder ne "saubere" DB rekonstruiert.
Schlimm isses wenn DB und Log korrupt sind. Dann sieht der Lastminute-Flug in die Dom.Rep seeehr attraktiv aus ;)
:edit: Wenn du dir ganz sicher sein willst, mach ein vollständiges Backup mittels Windows Server Sicherung, und führ zusätzlich noch eine Sicherung der Exchangedatenbank & Logs über Exchange selbst durch. Noch sicherer geht dann wirklich nicht.
Im Allgemeinen geht das in Ordnung, aber wirklich sicher ist es eigentlich nur wenn du die Sicherungsfunktionen der entsprechenden Datenbanken verwendest.
Auf der anderen Seite: Ich führ mindestens monatlich ein Testrestore für einen 2008er SBS durch der mit Acronis (Image, GVS) gesichert wird. Im Zusammenhang mit Exchange ist da noch nie ein Problem aufgetreten.
Zu DB & Transaktionslog: Wenn das Log vollständig ist reicht es ja die UrsprungsDB zu packen und die Transaktionen drüber laufen zu lassen. Klar, kann ewig brauchen, aber zumindest kriegst so wieder ne "saubere" DB rekonstruiert.
Schlimm isses wenn DB und Log korrupt sind. Dann sieht der Lastminute-Flug in die Dom.Rep seeehr attraktiv aus ;)
:edit: Wenn du dir ganz sicher sein willst, mach ein vollständiges Backup mittels Windows Server Sicherung, und führ zusätzlich noch eine Sicherung der Exchangedatenbank & Logs über Exchange selbst durch. Noch sicherer geht dann wirklich nicht.
