🥇So migrieren Sie OpenVZ 6-Container problemlos auf einen KVM-Server

Jeder, der mindestens einmal in seinem Leben einen OpenVZ-Container auf einen Server mit vollständiger KVM-Virtualisierung übertragen musste, ist auf einige Probleme gestoßen:

Die meisten Informationen sind einfach veraltet und für Betriebssysteme relevant, die den EOL-Zyklus längst überschritten haben
Für unterschiedliche Betriebssysteme werden immer unterschiedliche Informationen bereitgestellt und mögliche Fehler bei der Migration werden nie berücksichtigt
Manchmal hat man es mit Konfigurationen zu tun, die nach der Migration hin und wieder nicht funktionieren wollen

Wenn Sie einen Server übertragen, können Sie jederzeit spontan etwas reparieren, aber wenn Sie einen ganzen Cluster übertragen?

In diesem Artikel werde ich versuchen, Ihnen zu erklären, wie Sie einen OpenVZ-Container mit minimaler Ausfallzeit und einer schnellen Lösung aller Probleme korrekt auf KVM migrieren.

Ein kleines Bildungsprogramm: Was ist OpenVZ und was ist KVM?

Wir gehen nicht näher auf die Terminologie ein, sondern sagen allgemein:

OpenVZ – Virtualisierung auf Betriebssystemebene, Sie können sie sogar auf einer Mikrowelle bereitstellen, da keine CPU-Anweisungen und Virtualisierungstechnologien auf dem Host-Computer erforderlich sind.

KVM - vollwertige Virtualisierung, die die gesamte Leistung der CPU nutzt und in der Lage ist, alles auf jede Art und Weise zu virtualisieren, sowohl in Längsrichtung als auch in Querrichtung.

Entgegen der landläufigen Meinung ist die Umwelt Hosting-Anbieter OpenVZ ist überlaufen, KVM hingegen nicht. Zum Glück für Letzteres ist KVM mittlerweile genauso überlaufen wie sein Pendant.

Was werden wir übertragen?

В качестве подопытных для переноса пришлось использовать весь лес операционных систем, которые доступны на OpenVZ: CentOS (6 и 7 версии), Ubuntu (14, 16 и 18 LTS), Debian 7.

Es wurde angenommen, dass auf den meisten OpenVZ-Containern bereits eine Art LAMP lief und einige sogar über sehr spezifische Software verfügten. Am häufigsten handelte es sich dabei um Konfigurationen mit dem ISPmanager und dem VestaCP-Kontrollfeld (und meistens wurden diese über Jahre hinweg nicht aktualisiert). Auch deren Transferwünsche müssen berücksichtigt werden.

Die Migration erfolgt unter Berücksichtigung der Erhaltung. IP-Adressen Bei einem portablen Container gehen wir davon aus, dass die IP-Adresse des Containers auf der VM erhalten bleibt und problemlos funktioniert.

Stellen wir vor der Überweisung sicher, dass wir alles zur Hand haben:

OpenVZ-Server, vollständiger Root-Zugriff auf den Host-Rechner, Möglichkeit zum Stoppen/Mounten/Starten/Löschen von Containern
KVM-Server, voller Root-Zugriff auf den Host-Rechner, mit allem, was dazu gehört. Es wird davon ausgegangen, dass alles bereits konfiguriert und betriebsbereit ist.

Beginnen wir mit der Übertragung

Bevor wir mit der Übertragung beginnen, definieren wir Begriffe, die Ihnen helfen, Verwirrung zu vermeiden:

KVM_NODE - KVM-Hostmaschine
VZ_NODE - OpenVZ-Hostmaschine
CTID - OpenVZ-Container
VM - Virtueller KVM-Server

Vorbereitung der Migration und Erstellung virtueller Maschinen.

Schritt 1

Da wir den Container irgendwohin bewegen müssen, erstellen wir ihn VM mit einer ähnlichen Konfiguration wie KVM_NODE.
Wichtig! Создавать VM нужно именно на той операционной системе, которая сейчас крутится на CTID. Например, если на CTID установлена Ubuntu 14, то и на VM нужно ставить Ubuntu 14. Минорные версии не важны и их несовпадение не столь критично, а вот мажорные — должны быть одинаковыми.

Nach der Erstellung der VM aktualisieren wir die Pakete auf der CTID und auf der VM (nicht zu verwechseln mit der Aktualisierung des Betriebssystems – wir aktualisieren es nicht, wir aktualisieren nur die Pakete und, falls diese eintreffen, die Betriebssystemversion innerhalb der Hauptversion). Ausführung).

für CentOS этот процесс выглядит безобидно:

# yum clean all
# yum update -y

И не менее безобидно для Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Schritt 2

Installieren auf CTID, VZ_NODE и VM Nützlichkeit rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Wir installieren weder dort noch dort etwas anderes.

Schritt 3

Wir machen einen Stopp CTID auf VZ_NODE Team

vzctl stop CTID

Mounten des Bildes CTID:

vzctl mount CTID

Gehen Sie zum Ordner /vz/root/CTID und ausführen

mount --bind /dev dev && mount --bind /sys sys && mount --bind /proc proc && chroot .

Erstellen Sie im Stammverzeichnis eine Datei /root/exclude.txt – sie enthält eine Liste von Ausnahmen, die nicht auf den neuen Server gelangen

/boot
/proc
/sys
/tmp
/dev
/var/lock
/etc/fstab
/etc/mtab
/etc/resolv.conf
/etc/conf.d/net
/etc/network/interfaces
/etc/networks
/etc/sysconfig/network*
/etc/sysconfig/hwconf
/etc/sysconfig/ip6tables-config
/etc/sysconfig/kernel
/etc/hostname
/etc/HOSTNAME
/etc/hosts
/etc/modprobe*
/etc/modules
/net
/lib/modules
/etc/rc.conf
/usr/share/nova-agent*
/usr/sbin/nova-agent*
/etc/init.d/nova-agent*
/etc/ips
/etc/ipaddrpool
/etc/ips.dnsmaster
/etc/resolv.conf
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/network-scripts/ifcfg-ens3

Verbunden mit KVM_NODE und starten Sie unsere VMdamit es funktioniert und über das Netzwerk erreichbar ist.

Jetzt ist alles zur Übertragung bereit. Gehen!

Schritt 4

Immer noch verzaubert treten wir auf

rsync --exclude-from="/root/exclude.txt" --numeric-ids -avpogtStlHz --progress -e "ssh -T -o Compression=no -x" / root@KVM_NODE:/

Der Befehl rsync führt die Übertragung durch. Wir hoffen, dass die Schlüssel klar sind. Die Übertragung erfolgt unter Beibehaltung von Symlinks, Zugriffsrechten, Eigentümern und Gruppen und die Verschlüsselung ist für eine höhere Geschwindigkeit deaktiviert (Sie könnten jedoch eine schnellere Verschlüsselung verwenden Dies ist für diese Aufgabe nicht so wichtig) und die Komprimierung ist deaktiviert.

Nachdem Sie rsync abgeschlossen haben, verlassen Sie chroot (durch Drücken von Strg+D) und führen Sie es aus

umount dev && umount proc && umount sys && cd .. && vzctl umount CTID

Schritt 5

Führen wir mehrere Schritte aus, die uns beim Starten der VM nach der Übertragung von OpenVZ helfen.
Auf Servern mit Systemiert Lassen Sie uns einen Befehl ausführen, der uns hilft, uns bei einer normalen Konsole anzumelden, beispielsweise über einen VNC-Serverbildschirm

mv /etc/systemd/system/getty.target.wants/getty@tty2.service /etc/systemd/system/getty.target.wants/getty@tty1.service

Auf Servern CentOS 6 и CentOS 7 Stellen Sie sicher, dass Sie einen neuen Kernel installieren:

yum install kernel-$(uname -r)

Der Server kann von dort geladen werden, nach der Übertragung funktioniert er jedoch möglicherweise nicht mehr oder wird gelöscht.

Auf dem Server CentOS 7 Sie müssen einen kleinen Fix für PolkitD anwenden, sonst stürzt der Server für immer ab:

getent group polkitd >/dev/null && echo -e "e[1;32mpolkitd group already existse[0m" || { groupadd -r polkitd && echo -e "e[1;33mAdded missing polkitd groupe[0m" || echo -e "e[1;31mAdding polkitd group FAILEDe[0m"; }

getent passwd polkitd >/dev/null 
&& echo -e "e[1;32mpolkitd user already existse[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "User for polkitd" polkitd && echo -e "e[1;33mAdded missing polkitd usere[0m" || echo -e "e[1;31mAdding polkitd user FAILEDe[0m"; }

rpm -Va polkit* && echo -e "e[1;32mpolkit* rpm verification passede[0m" || { echo -e "e[1;33mResetting polkit* rpm user/group ownership & permse[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

Wenn mod_fcgid für Apache installiert wurde, führen wir auf allen Servern eine kleine Korrektur mit Rechten durch, andernfalls stürzen Websites, die mod_fcgid verwenden, mit Fehler 500 ab:

chmod +s `which suexec` && apachectl restart

И последнее, пригодится для Ubuntu, Debian дистрибутивов. Эта ОС может упасть в вечный бут с ошибкой

Schleife zu schnell. die Ausführung ein wenig drosseln

unangenehm, aber je nach Betriebssystemversion leicht zu beheben.

Auf Debian 9 der Fix sieht so aus:

wir führen durch

dbus-uuidgen

wenn wir eine Fehlermeldung erhalten

/usr/local/lib/libdbus-1.so.3: Version „LIBDBUS_PRIVATE_1.10.8“ nicht gefunden

Überprüfen Sie das Vorhandensein von LIBDBUS

ls -la /lib/x86_64-linux-gnu | grep dbus
libdbus-1.so.3 -> libdbus-1.so.3.14.15 
libdbus-1.so.3.14.15 <-- нужен этот
libdbus-1.so.3.14.16

Wenn alles in Ordnung ist, machen wir es

cd /lib/x86_64-linux-gnu
rm -rf libdbus-1.so.3
ln -s libdbus-1.so.3.14.15  libdbus-1.so.3

Wenn es nicht hilft, versuchen Sie es mit der zweiten Option.

Die zweite Lösung des Problems mit die Ausführung ein wenig drosseln подходит практически для всех Ubuntu и Debian дистрибутивов.

Wir führen aus

bash -x /var/lib/dpkg/info/dbus.postinst configure

Und für Ubuntu 14, Debian 7 Zusätzlich führen wir aus:

adduser --system --home /nonexistent --no-create-home --disabled-password --group messagebus

rm -rf /etc/init.d/modules_dep.sh

Что мы сделали? Восстановили messagebus, которого не хватало для запуска Debian/Ubuntu и удалили modules_dep, который пришел от OpenVZ и мешал загрузки многих модулей ядра.

Schritt 6

Wir starten die VM neu, prüfen in VNC, wie der Ladevorgang voranschreitet und im Idealfall lädt alles ohne Probleme. Obwohl es möglich ist, dass nach der Migration einige spezifische Probleme auftreten, gehen diese über den Rahmen dieses Artikels hinaus und werden behoben, sobald sie auftreten.

Ich hoffe, diese Informationen sind nützlich! 🙂

Source: habr.com