🥇Wie man einen OpenVZ 6 Container ohne Kopfschmerzen auf einen KVM-Server migriert

Jeder, der jemals ein OpenVZ-Container auf einen KVM-Server übertragen musste, hat einige Probleme festgestellt:

Die meisten Informationen sind einfach veraltet und betreffen bereits lange abgeschlossene EOL-Zyklen von Betriebssystemen.
Für verschiedene Betriebssysteme gibt es immer unterschiedliche Informationen, und mögliche Fehler während der Migration werden nie berücksichtigt.
Manchmal muss man sich mit Konfigurationen auseinandersetzen, die nach der Migration einfach nicht funktionieren wollen.

Wenn man einen Server überträgt, kann man immer etwas spontan korrigieren, aber was ist, wenn man ein ganzes Cluster migriert?

In diesem Artikel werde ich erklären, 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 zu tief in die Terminologie eintauchen, sondern allgemein sagen:

OpenVZ — Virtualisierung auf Betriebssystemebene, die sogar auf einer Mikrowelle umgesetzt werden kann, da keine speziellen CPU-Anweisungen und Virtualisierungstechnologien auf der Host-Maschine erforderlich sind.

KVM — vollwertige Virtualisierung, die die gesamte CPU-Leistung nutzt und alles nach Belieben virtualisieren kann, ob quer oder längs.

Entgegen der verbreiteten Meinung, dass in der Hosting-Anbieter OpenVZ überprovisioniert wird, während KVM nicht — erfreulicherweise werden auch die KVM-Server mittlerweile nicht besser verschont als ihre Kollegen.

Was wollen wir übertragen?

Als Versuchskandidaten für die Migration mussten wir den gesamten Wald der verfügbaren Betriebssysteme auf OpenVZ nutzen: CentOS (Versionen 6 und 7), Ubuntu (14, 16 und 18 LTS), Debian 7.

Es wurde angenommen, dass auf den meisten OpenVZ-Containern bereits irgendein LAMP läuft und einige sogar sehr spezifische Software installiert haben. Häufig handelt es sich um Konfigurationen mit ISPmanager, VestaCP (und in der Regel seit Jahren nicht aktualisiert). Auch ihre Anforderungen an die Migration müssen berücksichtigt werden.

Die Migration erfolgt unter Beibehaltung IP-Adressen des portablen Containers, wir gehen davon aus, dass die IP, die der Container hatte, auf der VM erhalten bleibt und problemlos funktioniert.

Vor der Migration stellen wir sicher, dass wir alles zur Hand haben:

OpenVZ-Server, vollständiger Root-Zugriff auf die Host-Maschine, Möglichkeit, Container zu stoppen/mounten/starten/löschen.
KVM-Server, mit vollem Root-Zugang zur Hostmaschine und allen damit verbundenen Vorteilen. Es wird vorausgesetzt, dass alles bereits eingerichtet und betriebsbereit ist.

Lass uns mit dem Umzug beginnen

Bevor wir mit dem Umzug starten, klären wir einige Begriffe, um Missverständnisse zu vermeiden:

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

Vorbereitung für den Umzug und die Erstellung virtueller Maschinen.

Schritt 1

Da wir den Container irgendwo hin verschieben müssen, erstellen wir VM mit einer ähnlichen Konfiguration auf KVM_NODE.
Wichtig! Die VM muss genau auf dem Betriebssystem erstellt werden, das derzeit auf dem CTID läuft. Wenn zum Beispiel auf dem CTID Ubuntu 14 installiert ist, muss auch die VM Ubuntu 14 verwenden. Die Minor-Versionen sind nicht kritisch, aber die Major-Versionen müssen identisch sein.

Nach der Erstellung der VM führen wir ein Update der Pakete auf dem CTID und der VM durch (nicht zu verwechseln mit einem OS-Update – das OS wird nicht aktualisiert, nur die Pakete und, falls verfügbar, die OS-Version innerhalb der Hauptversion).

Für CentOS sieht dieser Prozess harmlos aus:

# yum clean all
# yum update -y

Und ebenso harmlos für Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Schritt 2

Installieren wir auf CTID, VZ_NODE und VM ein Tool rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Nichts weiter installieren wir weder dort noch hier.

Schritt 3

Wir stoppen CTID findet man VZ_NODE mit dem Befehl

vzctl stop CTID

Wir mounten das Image 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 .

Im 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 läuft und über das Netzwerk erreichbar ist.

Jetzt ist alles bereit für die Migration. Lassen Sie uns loslegen!

Schritt 4

Während wir uns noch im 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 Befehl rsync wird die Migration durchführen. Wir hoffen, die Optionen sind klar — der Transfer erfolgt mit Beibehaltung von Symlinks, Zugriffsrechten, Eigentümern und Gruppen, und die Verschlüsselung ist für höhere Geschwindigkeit deaktiviert (man hätte einen schnelleren Cipher verwenden können, aber das ist für diese Aufgabe nicht so entscheidend).

Nach Abschluss der rsync-Ausführung verlassen wir den Chroot (mit Strg+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 beim Start der VM nach der Migration von OpenVZ helfen werden.
Auf Servern mit Systemd Wir führen einen Befehl aus, der uns hilft, uns über die reguläre Konsole anzumelden, zum Beispiel über den VNC-Bildschirm des Servers.

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 zwingend einen aktuellen Kernel installieren:

yum install kernel-$(uname -r)

Der Server kann davon booten, aber nach dem Umzug 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 unendlichen Boot-Zyklus:

getent group polkitd >/dev/null && echo -e "e[1;32mpolkitd-Gruppe existiert bereitse[0m" || { groupadd -r polkitd && echo -e "e[1;33mFehlende polkitd-Gruppe hinzugefügt[e[0m" || echo -e "e[1;31mHinzufügen der polkitd-Gruppe ist gescheitert[e[0m"; }\n\ngetent passwd polkitd >/dev/null \n&& echo -e "e[1;32mpolkitd-Benutzer existiert bereits[e[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "Benutzer für polkitd" polkitd && echo -e "e[1;33mFehlenden polkitd-Benutzer hinzugefügt[e[0m" || echo -e "e[1;31mHinzufügen des polkitd-Benutzers ist gescheitert[e[0m"; }\n\nrpm -Va polkit* && echo -e "e[1;32mpolkit*-rpm-Überprüfung bestanden[e[0m" || { echo -e "e[1;33mZurücksetzen des rpm-Besitzers / der Gruppe & der Berechtigungen für polkit*[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 Berechtigungen durch, sonst werden die Websites, die mod_fcgid verwenden, mit einem Fehler 500 abstürzen:

chmod +s `which suexec` && apachectl restart

Und zuletzt, dies ist nützlich für Ubuntu- und Debian-Distributionen. Dieses Betriebssystem kann in einen ewigen Boot mit einem Fehler fallen.

Looping zu schnell. Reduzieren Sie die Ausführung ein wenig.

Unangenehm, lässt sich jedoch leicht beheben, je nach Version des Betriebssystems.

Auf Debian 9 Der Fix sieht so aus:

Führen wir 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 <-- dieses 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 Option.

Die zweite Möglichkeit zur Lösung des Problems mit Reduzieren der Ausführung ein wenig ist praktisch für alle Ubuntu- und Debian-Distributionen geeignet.

Führen wir aus

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

Und für Ubuntu 14, Debian 7 ausführlich:

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, das fehlte, um Debian/Ubuntu zu starten, und haben modules_dep entfernt, das von OpenVZ kam und das Laden vieler Kernel-Module verhinderte.

Schritt 6

Wir starten die VM neu, überprüfen im VNC, wie der Bootprozess verläuft, und idealerweise sollte alles ohne Probleme hochfahren. Es können jedoch einige spezifische Probleme nach der Migration auftreten, aber diese fallen nicht in den Rahmen dieses Artikels und werden nach Bedarf behoben.

Ich hoffe, diese Informationen sind hilfreich! 🙂

Quelle: habr.com