So übertragen Sie den OpenVZ 6-Container ohne Probleme auf den 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, dass OpenVZ unter den Hosting-Anbietern überverkauft sein wird, KVM jedoch nicht – glücklicherweise ist KVM jetzt nicht schlechter überverkauft als sein Bruder.

Was werden wir übertragen?

Als Testpersonen für die Übertragung mussten wir den gesamten Wald an Betriebssystemen nutzen, die auf OpenVZ verfügbar sind: CentOS (Versionen 6 und 7), Ubuntu (14, 16 und 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 Beibehaltung der IP-Adresse des übertragenen Containers; wir gehen davon aus, dass die IP, die der Container hatte, auf der VM gespeichert ist 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! Sie müssen eine VM auf dem Betriebssystem erstellen, das derzeit unter CTID ausgeführt wird. Wenn beispielsweise Ubuntu 14 auf der CTID installiert ist, muss Ubuntu 14 auf der VM installiert werden. Nebenversionen sind nicht wichtig und ihre Diskrepanz ist nicht so kritisch, Hauptversionen sollten jedoch gleich sein.

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 sieht dieser Vorgang harmlos aus:

# yum clean all
# yum update -y

Und nicht weniger harmlos für Ubuntu und 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/[email protected] /etc/systemd/system/getty.target.wants/[email protected]

Auf Servern 6 CentOS и 7 CentOS 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 7 CentOS 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

Und das Letzte ist nützlich für Ubuntu- und Debian-Distributionen. Dieses Betriebssystem kann beim ewigen Booten mit einem Fehler abstürzen

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 Geeignet für fast alle Ubuntu- und Debian-Distributionen.

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 

Was haben wir getan? Wir haben den Messagebus wiederhergestellt, der zum Ausführen von Debian/Ubuntu fehlte, und die Modules_dep entfernt, die von OpenVZ stammte und das Laden vieler Kernel-Module beeinträchtigte.

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