Hetzner - DokuWiki

{{Languages|How_to_migrate_vServers_to_Cloud}}

= Migration von vServern auf Cloud =

Bestehende VQ/VX/CX vServer können auf CX Cloud Server migriert werden.

Ablauf Migration:

#Erstellung eines vergleichbaren oder besseren CX Cloud Servers
#Beide Systeme ins Rescue booten und Dateisysteme mounten
#Mit rsync die Synchronisation anstoßen

== Hinweise ==

Je nach Installation können andere oder mehr Schritte nötig sein, als die im Artikel genannten.

Folgende Betriebssysteme werde '''nicht''' unterstützt.

*Debian 6 und älter
*Ubuntu 11.10 und älter
*CentOS 5.6 und älter
*openSUSE 11.4 und älter

Für diese Betriebsysteme muss vor der Migration ein Upgrade durchgeführt werden,
sonst startet der Cloud Server nicht.

Vor der Migration müssen alle Pakete auf die mindestens erforderliche OS Version aktualisiert sein. Partielle Upgrades und/oder Betriebsysteme mit Paketen aus Drittquellen funktionieren unter Umständen nicht wie beschrieben und sind ebenfalls nicht unterstützt.

== Rescue auf beiden Systemen aktivieren==

Damit die Dateien auch sicher übertragen werden können, müssen sich beide Server im Rescue befinden. Im Robot wird für den VQ/VX/CX vServer das Rescue aktiviert und anschließend im "vServer" Tab der Server resettet.

[[File:Robot-Rescue.png|border|200px]]
[[File:Robot-Reset.png|border|200px]]

Dies wird auch in der Cloud Console gemacht, nur dass der Reset gleich mit dem Aktivieren des Rescues geschieht.

[[File:Cloud-Rescue-And-Reset.png|border|200px]]

===Mounten des Dateisystems===

Nachdem das Rescue gestartet ist, muss das Dateisystem eingebunden werden, um die Dateien auch synchronisieren zu können.

Auf dem VQ/VX/CX vServer variieren die Controller. Um die Partitionen richtig einzubinden, müssen diese abgerufen werden.

 alter_server ~ # fdisk -l

[[File:Sample_Output_of_fdisk.png|border|200px]]

Eingebunden wird das Dateisystem wie folgt:

 alter_server ~ # mount /dev/XXXY /mnt

Hierbei muss das XXX durch das ersetzt werden, was bei fdisk ausgegeben wurde. Das Y ist die Partitions-ID.
Wenn mehrere Partitionen vorhanden sind, müssen diese eingebunden werden, wie bei der Installation angegeben.

Die SWAP-Partition wird unter Type angezeigt. Diese kann wie folgt eingebunden werden:

 alter_server ~ # swapon /dev/XXXY

Falls eine Boot-Partiton vorhanden ist, muss zuerst die Hauptpartition eingebunden werden und danach die Boot-Partition. Die Boot-Partition ist meist die kleinste Partition von allen.

Der Einhängepunkt für die Boot-Partition ist /mnt/boot.

Auf dem Cloud Server erfolgt die Einbindung des Dateisystems erst später.

== Migration auf Cloud Server ==

====Partitionieren (optional)====
Falls ein älteres System (z.b. CentOS 6) mit grub-legacy zum Einsatz kommt, müssen 2 getrennte Partitionen angelegt werden, da der Bootloader kein Ext4 unterstützt.

Zuerst wird die bisherige Partitionstabelle gelöscht

 neuer_server ~ # parted -s /dev/sda mklabel msdos

Anschließend erstellt man eine 512M große Partitions für /boot und eine weitere für den verbleibenden Speicherplatz:

 neuer_server ~ # parted -s /dev/sda mkpart primary 2048s 513MiB
 neuer_server ~ # parted -s /dev/sda mkpart primary 514MiB 100%

=== Dateisystem(e) formatieren ===

Es muss zuerst das Dateisystem vom '''Cloud Server''' gelöscht werden.

 neuer_server ~ # mkfs -O ^64bit,^metadata_csum -t ext4 /dev/sda1

Dies erstellt ein neues Dateisystem (ohne sehr neue Features) und löscht alle bisherigen Daten auf dem '''Cloud Server'''.

Falls im ersten Schritte 2 Partitionen erstellt wurden, müssen diese mit einem ext3 bzw ext4 Dateisystem formatiert werden.

 neuer_server ~ # mkfs.ext3 /dev/sda1
 neuer_server ~ # mkfs -O ^64bit,^metadata_csum -t ext4 /dev/sda2

===Dateisystem einbinden===
Einbinden des neuen leeren Dateisystems:

* bei nur einer Partition

 neuer_server ~ # mount /dev/sda1 /mnt

* bei 2 Partitionen:

 neuer_server ~ # mount /dev/sda2 /mnt
 neuer_server ~ # mkdir /mnt/boot
 neuer_server ~ # mount /dev/sda1 /mnt/boot

===Migration===
Die Datenübertragung erfolgt mit rsync.

 neuer_server ~ #  rsync -avz --progress --numeric-ids IP-DES-ALTEN-SERVERS:/mnt/* /mnt

===fstab Anpassung===

Die fstab muss '''umbedingt''' an den Cloud Server angepasst werden, ansonsten startet der Server nicht!

Die UUID der Festplattenpartition kann wie folgt ausgelesen werden:

 neuer_server ~ # blkid -o value -s UUID /dev/sda1

* falls 2 Partitionen erstellt wurden:
 neuer_server ~ # blkid -o value -s UUID /dev/sda2

Zeile in /mnt/etc/fstab mit UUID vorher:

 UUID=<UUID-root-partition-alter_server> / ext3 defaults 0 0

Bei einer Partition ändern zu:

 UUID=<UUID-sda1-neuer_server> / ext4 discard,errors=remount-ro 0 1

Bei 2 Partitionen

 UUID=<UUID-sda2-neuer_server> / ext4 discard,errors=remount-ro 0 1
 UUID=<UUID-sda1-neuer_server> /boot ext3 defaults 0 2

==Notwendige Anpassungen am neuen Server==
===Umstellung auf DHCP===
====Debian/Ubuntu====

Editieren von /mnt/etc/network/interfaces

Zeilen wie z.B. auto ens3, iface ens3 inet static müssen entfernt werden.

<pre>auto eth0
iface eth0 inet dhcp

iface eth0 inet6 static
    address <neues IPv6 Subnetz>::1
    netmask 64
    gateway fe80::1
</pre>
Weitere Zeilen wie address, netmask und gateway müssen im IPv4 Teil (unter iface eth0 inet dhcp) entfernt werden.

====Ubuntu 18.04====
Ubuntu 18.04 nutzt netplan welches anders konfiguriert wird als bisherige Ubuntu Versionen.
Es muss die .yml Datei im Ordner /etc/netplan/ angepasst werden:

 network:
   version: 2
   renderer: networkd
   ethernets:
     ens3:
       addresses:
         - <IPv6-Adresse>::1/64
       dhcp4: true
       gateway6: fe80::1

====CentOS und openSUSE====

 neuer_server ~ # rm /mnt/etc/sysconfig/network-scripts/route-eth0

Editieren von /mnt/etc/sysconfig/network-scripts/ifcfg-eth0

 BOOTPROTO=dhcp

Die Zeilen IPADDR, NETMASK, SCOPE und BROADCAST müssen entfernt werden.

====Arch Linux====
Wenn die Installation von Arch Linux über das ISO oder das installimage getätigt wurde, wird systemd-network genutzt.

Editieren von /mnt/etc/systemd/network/network/10-ens3.network '''(Dies kann auch 10-eth0.network sein!)'''

 [Match]
 Name=eth0
 [Network]
 DHCP=ipv4

Die Zeilen Address und Gateway müssen entfernt werden.

===Entfernung der udev-Regel der Netzwerkkarte===
Da jeder vServer eine andere MAC Adresse besitzt, muss vor dem Export die udev-Regel entfernt werden, damit der neuen Netzwerkkarte beim Import ebenfalls eth0 zugewiesen wird.

 neuer_server ~ # rm /mnt/etc/udev/rules.d/70-persistent-net.rules
 neuer_server ~ # rm /mnt/etc/udev/rules.d/80-net-setup-link.rules

====Arch Linux====
Unter Arch Linux wird eine Verknüpfung mit /dev/null angelegt. Somit wird wieder eth0 zugewiesen.

 neuer_server ~ # ln -s /dev/null /etc/systemd/network/99-default.link

===GRUB===
Der Bootloader GRUB besitzt noch die alte Konfiguration. Deshalb muss die neue Konfiguration generiert werden. Dies geschieht wie folgt:

====Debian/Ubuntu====

 neuer_server ~ # chroot-prepare /mnt ; chroot /mnt
 neuer_server ~ # grub-mkdevicemap
 neuer_server ~ # grub-install /dev/sda
 neuer_server ~ # update-initramfs -u
 neuer_server ~ # update-grub
 neuer_server ~ # exit

Unter Debian 9 muss vor den nächsten Kommandos noch folgende Zeile in der Datei /etc/default/grub editiert werden:

 GRUB_CMDLINE_LINUX="net.ifnames=0"

Damit wird die Netzwerkkarte als eth0 erkannt und erscheint nicht als ens3 im System.

 neuer_server ~ # update-grub
 neuer_server ~ # exit

==== CentOS 6 ====

 neuer_server ~ # rm /mnt/etc/mtab
 neuer_server ~ # chroot-prepare /mnt ; chroot /mnt
 neuer_server ~ # ln -s /proc/mounts /etc/mtab
 neuer_server ~ # grub-install /dev/sda

In der /boot/grub/grub.cfg muss '''unbedingt''' die UUID manuell geändert werden. Der Grund dafür ist, dass der Bootloader GRUB 1 (Legacy) genutzt wird und daher nicht automatisch geändert wird, bei einem grub-install.

Sobald die Änderungen in der /boot/grub/grub.cfg vorgenommen wurden, müssen noch folgende Commands ausgeführt werden:

 neuer_server ~ # dracut -f
 neuer_server ~ # exit

==== CentOS 7 ====

 neuer_server ~ # chroot-prepare /mnt ; chroot /mnt
 neuer_server ~ # grub2-install /dev/sda
 neuer_server ~ # grub2-mkconfig -o /boot/grub2/grub.cfg
 neuer_server ~ # dracut -f
 neuer_server ~ # exit

====Arch Linux====

 neuer_server ~ # chroot-prepare /mnt ; chroot /mnt
 neuer_server ~ # grub-install /dev/sda
 neuer_server ~ # grub-mkconfig -o /boot/grub/grub.cfg
 neuer_server ~ # mkinitcpio -p linux
 neuer_server ~ # exit

====openSUSE====

 neuer_server ~ # chroot-prepare /mnt ; chroot /mnt
 neuer_server ~ # grub2-install /dev/sda
 neuer_server ~ # grub2-mkconfig -o /boot/grub2/grub.cfg
 neuer_server ~ # mkinitrd
 neuer_server ~ # exit

===Kernel Update===
====Ubuntu====
Bei älteren Ubuntu Versionen wie 12.04 kann es vorkommen, dass das System nicht Bootet, aufgrund von fehlenden Treibern im Kernel. Hier kann ein Update auf einen HWE Kernel helfen. Dafür den Server wieder in das Rescue starten, alle Partition einhängen und in die chroot Umgebung wechseln:

 neuer_server ~ # chroot-prepare /mnt ; chroot /mnt
 neuer_server ~ # apt-get install --install-recommends linux-generic-lts-trusty
 neuer_server ~ # exit

==Letzte Schritte beim Cloud Server==
Um den Cloud Server wieder nutzen zu können, muss das Dateisystem aushängen werden.

 neuer_server ~ # umount -R /mnt
* Aushängen des Dateisystems

Anschließend kann der Cloud Server neugestartet werden.

 neuer_server ~ # reboot

[[Kategorie:Hetzner Cloud]]