Hetzner - DokuWiki

How to migrate vServers to Cloud
(Partitionieren (optional))
(Ubuntu)
Zeile 246: Zeile 246:
 
===Kernel Update===
 
===Kernel Update===
 
====Ubuntu====
 
====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 und in die chroot Umgebung wechseln:
+
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 ~ # chroot-prepare /mnt ; chroot /mnt
 
  neuer_server ~ # apt-get install --install-recommends linux-generic-lts-trusty
 
  neuer_server ~ # apt-get install --install-recommends linux-generic-lts-trusty

Version vom 28. September 2018, 14:41 Uhr

Inhaltsverzeichnis

Migration von vServern auf Cloud

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

Ablauf Migration:

  1. Erstellung eines vergleichbaren oder besseren CX Cloud Servers
  2. Beide Systeme ins Rescue booten und Dateisysteme mounten
  3. 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.

Robot-Rescue.png Robot-Reset.png

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

Cloud-Rescue-And-Reset.png

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

Sample Output of fdisk.png

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.

auto eth0
iface eth0 inet dhcp

iface eth0 inet6 static
    address <neues IPv6 Subnetz>::1
    netmask 64
    gateway fe80::1

Weitere Zeilen wie address, netmask und gateway müssen im IPv4 Teil (unter iface eth0 inet dhcp) entfernt werden.

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


© 2019. Hetzner Online GmbH. Alle Rechte vorbehalten.