🥇Hur man flyttar en OpenVZ 6-container till en KVM-server utan huvudvärk

Alla som någon gång har behövt flytta en OpenVZ-container till en server med fullständig KVM-virtualisering har stött på vissa problem:

Det mesta av informationen är helt enkelt föråldrad och var relevant för operativsystem med EOL-cykler som passerat för länge sedan.
Olika operativsystem erbjuder alltid olika information, och möjliga fel vid migration beaktas sällan.
Ibland måste man hantera konfigurationer som ständigt vägrar att fungera efter migration.

När man flyttar en server går det alltid att åtgärda något under tiden, men vad händer när man flyttar ett helt kluster?

I den här artikeln kommer jag att försöka förklara hur man korrekt migrerar en OpenVZ-container till KVM med minimal nedtid och snabba lösningar på alla problem.

En liten introduktion: vad är OpenVZ och vad är KVM?

Vi går inte in på terminologi, utan säger i allmänna drag:

OpenVZ — virtualisering på operativsystemsnivå, vilket kan implementeras även på en mikrovågsugn, eftersom det inte finns något behov av CPU-instruktioner och virtualiseringstekniker på värdmaskinen.

KVM — fullständig virtualisering som utnyttjar all CPU-kraft och kan virtualisera vad som helst, hur som helst, dela upp och kombinera.

Trots den allmänna uppfattningen att i miljön hostingleverantörer OpenVZ översäljs, medan KVM inte gör det — till lycka för sistnämnda, översäljs KVM numera inte sämre än sin motsvarighet.

Vad ska vi flytta?

För våra experiment för att flytta har vi använt hela skogen av operativsystem som är tillgängliga på OpenVZ: CentOS (versioner 6 och 7), Ubuntu (versioner 14, 16 och 18 LTS), Debian 7.

Det antogs att en stor del av OpenVZ-containrarna redan kör något slags LAMP, och några har till och med mycket specifik mjukvara. Oftast var det konfigurationer med ISPmanager eller VestaCP (som ofta inte har uppdaterats på flera år). Deras krav på migration måste också beaktas.

Migrationen genomförs med bevarande av IP-adresser den flyttade containern, vi förutsätter att IP-adressen som innehades av containern behålls på VM och kommer att fungera utan problem.

Innan flytten, låt oss se till att vi har allt vi behöver:

OpenVZ-server, full root-åtkomst till värdmaskinen, möjlighet att stoppa/mounta/starta/ta bort containrar.
KVM-server, full root-åtkomst till värdmaskinen, med alla konsekvenser. Det förutsätts att allt redan är inställt och klart för användning.

Vi påbörjar flytten

Innan vi börjar flytten, definierar vi termer som gör det lättare att förstå:

KVM_NODE — KVM värdmaskin
VZ_NODE — OpenVZ värdmaskin
CTID — OpenVZ behållare
VM — KVM virtuell server

Förberedelse för flytt och skapande av virtuella maskiner.

Steg 1

Eftersom vi behöver flytta behållaren, låt oss skapa VM med en liknande konfiguration på KVM_NODE.
Viktigt! VM måste skapas på det operativsystem som för närvarande körs på CTID. Till exempel, om CTID har Ubuntu 14 installerat, ska VM också ha Ubuntu 14. Mindre versioner spelar ingen roll och deras skillnader är inte så kritiska, men större versioner måste vara identiska.

Efter att VM har skapats, uppdaterar vi paketen på CTID och VM (blanda inte med att uppdatera OS — vi uppdaterar inte operativsystemet, utan endast paketen och om det behövs, OS-versionen inom huvudversionen).

För CentOS ser denna process ofarlig ut:

# yum clean all
# yum update -y

Och lika ofarlig för Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Steg 2

Installera på CTID, VZ_NODE och VM verktyget rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Inga andra installationer görs varken där eller där.

Steg 3

Vi utför stopp CTID till VZ_NODE med kommandot

vzctl stop CTID

Montera bilden CTID:

vzctl mount CTID

Vi går till mappen /vz/root/CTID och utför

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

Under chroot skapar vi filen /root/exclude.txt — den kommer att innehålla en lista över undantag som inte kommer att flyttas till den nya servern

/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

Vi ansluter till KVM_NODE och startar vår VM, så den fungerar och är tillgänglig över nätverket.

Nu är allt klart för flytt. Låt oss köra!

Steg 4

Medan vi fortfarande är under chroot, utför vi

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

rsync-kommandot kommer att utföra flytten, vi hoppas att nycklarna är tydliga — flytten görs med bevarande av symlänkar, rättigheter, ägare och grupper, och kryptering är avstängd för högre hastighet (man kunde ha använt en snabbare cipher, men det är inte så kritiskt i den här uppgiften), krympning är också avstängd.

Efter att rsync har avslutats, går vi ut från chroot (genom att trycka ctrl+d) och utför

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

Steg 5

Vi utför några åtgärder som hjälper oss att starta VM efter flytten från OpenVZ.
På servrar med Systemd utför vi ett kommando som hjälper oss att logga in i den vanliga konsolen, till exempel via VNC-anslutningen på servern

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

På servrar CentOS 6 och CentOS 7 måste vi absolut installera en ny kärna:

yum install kernel-$(uname -r)

Servern kan laddas från det, men efter flytt kan det sluta fungera eller tas bort.

På servern CentOS 7 måste en liten fix appliceras för PolkitD, annars kommer servern att falla i en oändlig boot:

getent group polkitd >/dev/null && echo -e "e[1;32mpolkitd gruppen finns redane[0m" || { groupadd -r polkitd && echo -e "e[1;33mLa till den saknade polkitd-gruppen[0m" || echo -e "e[1;31mAtt lägga till polkitd-gruppen MISSLYCKADEe[0m"; }

getent passwd polkitd >/dev/null 
&& echo -e "e[1;32mpolkitd-användaren finns redane[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "Användare för polkitd" polkitd && echo -e "e[1;33mLa till den saknade polkitd-användaren[0m" || echo -e "e[1;31mAtt lägga till polkitd-användaren MISSLYCKADEe[0m"; }

rpm -Va polkit* && echo -e "e[1;32mpolkit* rpm-verifiering passeradee[0m" || { echo -e "e[1;33mÅterställer polkit* rpm användar-/gruppägande & rättighetere[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

På alla servrar, om mod_fcgid har installerats för Apache, kör vi en liten fix med rättigheter, annars kommer webbplatser som använder mod_fcgid att falla med fel 500:

chmod +s `which suexec` && apachectl restart

Och sist, det här kan vara användbart för Ubuntu, Debian-distributioner. Detta operativsystem kan falla i en oändlig boot med felmeddelandet

looping too fast. throttling execution a little

obehagligt, men enkelt att fixa, beroende på versionen av OS.

På Debian 9 fixen ser ut så här:

vi kör

dbus-uuidgen

om vi får ett fel

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

kontrollerar vi om LIBDBUS finns

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 <-- den här behövs
libdbus-1.so.3.14.16

om allt är i ordning kör vi

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

Om det inte hjälper - prova det andra alternativet.

Det andra alternativet för att lösa problemet med throttling execution a little fungerar praktiskt taget för alla Ubuntu och Debian-distributioner.

Kör

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

Allowed Logout URLs Ubuntu 14, Debian 7 ytterligare utför vi:

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

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

Vad gjorde vi? Vi återställde messagebus, som saknades för att starta Debian/Ubuntu och tog bort modules_dep, som kom från OpenVZ och störde laddningen av många kärnmoduler.

Steg 6

Vi omstartar VM, verifierar via VNC hur starten går och i bästa fall - allt laddas utan problem. Även om det kan uppstå vissa specifika problem efter migreringen - men de ligger utanför denna artikel och åtgärdas när de dyker upp.

Jag hoppas att denna information kommer att vara användbar! 🙂

Källa: habr.com