Proxtalks 2016 - Migration zu Proxmox VE

253 Aufrufe

Veröffentlicht am

Vortrag auf der Proxtalks 2016 Berlin: Wie man erfolgreich von bestehender Hardware oder anderen Virtualisierungsumgebungen zu Proxmox VE migriert

Veröffentlicht in: Präsentationen & Vorträge
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
253
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
154
Aktionen
Geteilt
0
Downloads
1
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Proxtalks 2016 - Migration zu Proxmox VE

  1. 1. Proxtalks 2016 Migration zu ProxmoxVE BestehendeVirtualisierungsumgebungen zu ProxmoxVE migrieren 10/2016 – Marco Gabriel Bild: (CC BY SA 2.0) flickr.com - Melv_L - MACASR
  2. 2. inett GmbH • Linux Systemhaus in Saarbrücken • Gegründet 2007 • ~10 Mitarbeiter • Proxmox Partner und ProxmoxTraining Partner • ProxmoxVE Projekte undTrainings in Deutschland, Österreich, Schweiz, Luxemburg und weiteren Ländern
  3. 3. Gründe für die Migration Die bestehendeVirtualisierungslösung... • ist „in die Jahre“ gekommen • genügt zukünftigen Anforderungen nicht mehr • läuft nicht auf neuer Hardware • unterstützt neue Gastbetriebssysteme nicht • verursacht zu hohe Betriebskosten • verursacht bei einer Erweiterung hohe Kosten (CC BY SA 2.0) flickr.com - Karl Baron
  4. 4. Voraussetzungen prüfen • Server / Hardware • Hochverfügbarkeit geplant? • Wie viele Server mit welcher Ausstattung? • Storage weiterverwenden oder ersetzen? • Welche Storage für meine Anforderungen? Lokal, zentral, verteilt? • Netzwerkinfrastruktur • 10 Gbit/s benötigt, z.B. für Ceph Storage? • Redundanz bedacht?
  5. 5. Quelle • Physikalischer Server (P2V) • Vmware • XEN • Hyper-V • OpenVZ • Sonstige
  6. 6. Möglichkeiten • Einfach, wenn ein gängiges Image existiert • raw, qcow2, vmdk (flat, nicht gestückelt) • Auf ProxmoxVE Host kopieren • NeueVM Konfiguration erstellen • Image einbinden • Eventuelle Inkompatibilitäten beiTreibern
  7. 7. Möglichkeiten • Oft zumindest möglich, selbst bei exotischen Images • qemu-img CLITool verwenden • Supported formats: vhdx vmdk blkreplay gluster file bochs raw vdi luks iscsi qcow host_cdrom sheepdog host_device qed quorum parallels null-aio cloop null-co blkverify zeroinit nbd tftp ftp blkdebug ftps https http dmg rbd vvfat qcow2 vpc • qemu-img convert [--object objectdef] [--image-opts] [-c] [-p] [-q] [-n] [-f fmt] [-t cache] [-T src_cache] [-O output_fmt] [-o options] [-s snapshot_id_or_name] [-l snapshot_param] [-S sparse_size] filename [filename2 [...]] output_filename • qemu-img convert –f vhdx –O qcow2 QuellImage.vhdx ZielImage.qcow2
  8. 8. Möglichkeiten • Häufiger: Backup und Restore direkt aus derVM • Toll:Wiederherstellung auf abweichender (VM) Hardware • Immer seltener: Converter von anderen Hypervisoren • VMware Converter, Microsoft Systems Center • Eigentlich für eine andere Zielplattform • Kann funktionieren
  9. 9. Der letzte Strohhalm • Manchmal: Applikationsmigration • Server Neuinstallation mit Datenmigration • Je nachApplikation sogar ohne Downtime möglich • Aufwendig • Eher für wenigeAusnahmen geeignet, nicht für die generelle Migration
  10. 10. Tools • Open Source • CloneZilla Boot CD • SystemRescueCD • fsarchiver, mondobackup, dd, (g)ddrescue • Kommerziell • Windows Backup • Sonstige Backup Hersteller mit Imaging und Bare Metal Restore
  11. 11. Weiterführend: PVEWiki • ProxmoxVEWiki: Migration von Servern  http://pve.proxmox.com/wiki/Migration_of_servers_ to_Proxmox_VE
  12. 12. „Andere“ • OpenVZ Container  LXC Container • KVM/Vmware/Hyper-V/<Sonstige> Linux  LXC Container • OpenVZ Container  KVM
  13. 13. OpenVZ  LXC • OpenVZ bis ProxmoxVE 3.4, LXC ab ProxmoxVE 4.0 • Einfach: OpenVZ Backup, Restore mit LXC • Netzwerk muss neu konfiguriert werden • Nicht für alle Distributionen möglich, vor allem ältere funktionieren nicht • ProxmoxVE gibt beim Restore einen Fehler aus •  dann benötigen wir eine andere Strategie
  14. 14. *  LXC • Neuen LXCContainer mit gleicher Distribution undVersion installieren • rsync zur Übernahme der Files • Auslassen von /etc und den üblichenVerdächtigen wie proc, sys, mnt, dev, ... • Nacharbeit im Ziel (z.B. /etc zusammenführen) • Quelle runterfahren, dann finales rsync, Ziel starten • Höherer, auch manueller Aufwand • Funktioniert mit fast jeder Quelle, auch mit physikalischen Servern • Funktioniert sogar umgekehrt, z.B. für OpenVZ  KVM
  15. 15. Vorbereiten der Gäste • Backup erstellen • Snapshots vor jedem Schritt • IDETreiber für HDD Controller aktivieren / installieren • Nicht benötigte Software und alteTreiber deinstallieren • Gasterweiterungen des alten Hypervisors deinstallieren STOP: 0x0000007B (0xF741B84C,0xC0000034,0x00000000,0x00000000) INACCESSIBLE_BOOT_DEVICE
  16. 16. Vielen Dank für Ihre Aufmerksamkeit! Marco Gabriel inett GmbH E-Mail: mgabriel@inett.de Telefon: +49 681 410993-11 Twitter: @MarcoMGabriel Facebook: fb.com/marcomgabriel Google+: google.com/+MarcoMGabriel XING: xing.com/profile/Marco_Gabriel LinkedIn: linkedin.com/in/marcogabriel1

×