🥇Wie man einen OpenVZ 6-Container ohne Kopfschmerzen auf einen KVM-Server überträgt

Jeder, der mindestens einmal im Leben einen OpenVZ-Container auf einen Server mit vollständiger KVM-Virtualisierung verschieben musste, hatte mit einigen Problemen zu kämpfen:

Der Großteil der Informationen ist schlichtweg veraltet und war nur für längst vergangene EOL-Zyklen von Betriebssystemen relevant.
Für verschiedene Betriebssysteme werden unterschiedliche Informationen bereitgestellt, und mögliche Fehler während der Migration werden nie betrachtet.
Manchmal muss man mit Konfigurationen umgehen, die nach der Migration einfach nicht mehr funktionieren wollen.

Wenn man einen Server umzieht, kann man immer etwas spontan anpassen, aber wie ist es, wenn man ein ganzes Cluster migriert?

In diesem Artikel werde ich erläutern, wie man einen OpenVZ-Container mit minimaler Ausfallzeit und schnellen Lösungen für alle Probleme richtig auf KVM migriert.

Ein kurzer Überblick: Was ist OpenVZ und was ist KVM?

Wir werden nicht in die Terminologie eintauchen, sondern allgemein sagen:

OpenVZ — Virtualisierung auf Betriebssystemebene, die sogar auf einer Mikrowelle durchgeführt werden kann, da keine speziellen CPU-Befehle und Virtualisierungstechnologien auf der Host-Maschine notwendig sind.

KVM — vollständige Virtualisierung, die die gesamte Leistung der CPU nutzt und alles, wie man will, virtualisieren kann, entlang und quer.

Entgegen der weit verbreiteten Meinung, dass in der Umgebung von Hosting-Anbietern OpenVZ überverkauft wird und KVM nicht — zu unserem Glück wird auch KVM heutzutage nicht schlechter überverkauft als sein Pendant.

Was werden wir übertragen?

Als Versuchskaninchen für die Migration mussten alle verfügbaren Betriebssysteme auf OpenVZ herhalten: CentOS (Versionen 6 und 7), Ubuntu (14, 16 und 18 LTS), Debian 7.

Es wurde davon ausgegangen, dass auf den meisten OpenVZ-Containern bereits irgendein LAMP läuft, und einige haben sogar spezielle Software. Oft handelte es sich um Konfigurationen mit den Kontrollpanel-Lösungen ISPmanager, VestaCP (und meist seit Jahren nicht aktualisiert). Man muss auch deren Anforderungen an die Migration berücksichtigen.

Die Migration erfolgt mit der Beibehaltung des IP-Adressen migrierten Containers, wir gehen davon aus, dass die IP, die der Container hatte, auf der VM beibehalten wird und ohne Probleme funktioniert.

Vor der Migration stellen wir sicher, dass wir alles bereit haben:

Ein OpenVZ-Server, voller Root-Zugang zur Host-Maschine, die Möglichkeit, Container anhalten/montieren/starten/löschen zu können.
KVM-Server, vollständiger Root-Zugriff auf die Host-Maschine, mit all den damit verbundenen Möglichkeiten. Es wird davon ausgegangen, dass alles bereits eingerichtet und bereit zur Nutzung ist.

Wir beginnen mit dem Transfer

Bevor wir mit dem Transfer beginnen, definieren wir die Begriffe, die helfen, nicht durcheinanderzukommen:

KVM_NODE — KVM-Host-Maschine
VZ_NODE — OpenVZ-Host-Maschine
CTID — OpenVZ-Container
VM — KVM-virtueller Server

Vorbereitung auf den Transfer und Erstellung von virtuellen Maschinen.

Schritt 1

Da wir den Container irgendwohin transferieren müssen, erstellen wir VM mit einer ähnlichen Konfiguration auf KVM_NODE.
Wichtig! Die VM sollte genau auf dem Betriebssystem erstellt werden, das derzeit auf CTID läuft. Zum Beispiel, wenn auf CTID Ubuntu 14 installiert ist, sollte auch auf der VM Ubuntu 14 installiert werden. Nebenversionen sind nicht wichtig und ihr Abweichen ist nicht so kritisch, aber Hauptversionen müssen identisch sein.

Nach der Erstellung der VM führen wir ein Update der Pakete auf CTID und auf der VM durch (nicht zu verwechseln mit der Betriebssystemaktualisierung — das Betriebssystem selbst wird nicht aktualisiert, nur die Pakete und, falls vorhanden, die Version des Betriebssystems innerhalb der Hauptversion).

Für CentOS sieht dieser Prozess harmlos aus:

# yum clean all
# yum update -y

Und nicht weniger harmlos für Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Schritt 2

Wir installieren auf CTID, VZ_NODE und VM Dienstprogramm rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Wir installieren nichts weiter, weder dort noch hier.

Schritt 3

Wir stoppen CTID auf VZ_NODE Wir setzen ein eigenes Passwort für den Benutzer

vzctl stop CTID

Wir mounten das Abbild CTID:

vzctl mount CTID

Wir wechseln in das Verzeichnis /vz/root/CTID und führen aus

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

Unter chroot erstellen wir die Datei /root/exclude.txt — sie wird eine Liste von Ausnahmen enthalten, die nicht auf den neuen Server übertragen werden.

/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

Wir verbinden uns mit KVM_NODE und starten unser VM, damit es funktioniert und über das Netzwerk zugänglich ist.

Jetzt ist alles bereit für den Transfer. Los geht’s!

Schritt 4

Während wir uns noch unter chroot befinden, führen wir aus

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

Der rsync-Befehl wird den Transfer durchführen, wir hoffen, dass die Parameter klar sind — der Transfer erfolgt unter Beibehaltung von Symlinks, Zugriffsrechten, Besitzern und Gruppen, und die Verschlüsselung ist für eine höhere Geschwindigkeit deaktiviert (man hätte einen schnelleren Cipher verwenden können, aber das ist für diese Aufgabe nicht so entscheidend), ebenso ist die Komprimierung deaktiviert.

Nach Abschluss der rsync-Ausführung verlassen wir das chroot (durch Drücken von ctrl+d) und führen aus

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

Schritt 5

Wir führen einige Aktionen durch, die uns helfen werden, die VM nach dem Transfer von OpenVZ zu starten.
Auf Servern mit Systemd Wir führen den Befehl aus, der uns hilft, uns über die gewöhnliche Konsole, zum Beispiel über den VNC-Bildschirm des Servers, anzumelden.

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

Auf den Servern CentOS 6 und CentOS 7 müssen wir unbedingt einen neuen Kernel installieren:

yum install kernel-$(uname -r)

Der Server kann von ihm gebootet werden, aber nach der Verschiebung kann es sein, dass er nicht mehr funktioniert oder gelöscht wird.

Auf dem Server CentOS 7 muss ein kleiner Fix für PolkitD angewendet werden, sonst fällt der Server in einen endlosen Bootvorgang:

getent group polkitd >/dev/null && echo -e "e[1;32mpolkitd group already exists e[0m" || { groupadd -r polkitd && echo -e "e[1;33mMissing polkitd group added e[0m" || echo -e "e[1;31mAdding polkitd group FAILED e[0m"; }

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

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

Auf allen Servern, wenn mod_fcgid für Apache installiert wurde, führen wir einen kleinen Fix mit den Rechten durch, sonst fallen die Websites, die mod_fcgid verwenden, mit einem Fehler 500 aus:

chmod +s `which suexec` && apachectl restart

Und zuletzt, nützlich für Ubuntu- und Debian-Distributionen. Dieses Betriebssystem kann in eine Endless Boot-Schleife mit dem Fehler fallen

looping too fast. throttling execution a little

unangenehm, lässt sich aber leicht beheben, abhängig von der Version des Betriebssystems.

Auf Debian 9 Der Fix sieht wie folgt aus:

wir führen aus

dbus-uuidgen

wenn wir einen Fehler erhalten

/usr/local/lib/libdbus-1.so.3: version `LIBDBUS_PRIVATE_1.10.8′ not found

überprüfen wir 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 <-- das wird benötigt
libdbus-1.so.3.14.16

wenn alles in Ordnung ist, führen wir aus

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 das nicht hilft, probieren wir die zweite Variante.

Die zweite Variante zur Problemlösung mit throttling execution a little ist praktisch für alle Ubuntu- und Debian-Distributionen geeignet.

Wir führen aus

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

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

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

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

Was haben wir gemacht? Wir haben messagebus wiederhergestellt, der für den Start von Debian/Ubuntu fehlte, und modules_dep gelöscht, das von OpenVZ kam und viele Kernelmodule beim Start störte.

Schritt 6

Wir starten die VM neu, überprüfen über VNC, wie der Bootvorgang verläuft, und idealerweise - alles lädt ohne Probleme. Obwohl möglicherweise einige spezifische Probleme nach der Migration auftreten - aber diese fallen nicht in den Rahmen dieses Artikels und werden nach Erscheinen behoben.

Ich hoffe, diese Informationen sind nützlich! 🙂

Quelle: habr.com