Hur man överför OpenVZ 6-behållare till KVM-server utan huvudvärk

Alla som har behövt överföra en OpenVZ-behållare till en server med full KVM-virtualisering minst en gång i sitt liv har stött på några problem:

• Det mesta av informationen är helt enkelt föråldrad och var relevant för operativsystem som länge hade passerat EOL-cykeln
• Olika information tillhandahålls alltid för olika operativsystem, och eventuella fel under migreringen beaktas aldrig
• Ibland måste man hantera konfigurationer som då och då inte vill fungera efter migreringen

När du överför 1 server kan du alltid fixa något i farten, men när du överför ett helt kluster?

I den här artikeln kommer jag att försöka berätta hur du korrekt migrerar en OpenVZ-behållare till KVM med minimal driftstopp och en snabb lösning på alla problem.

Ett litet utbildningsprogram: vad är OpenVZ och vad är KVM?

Vi kommer inte att gå djupt in i terminologin, utan kommer att säga i allmänna termer:

OpenVZ — virtualisering på operativsystemnivå, du kan till och med distribuera den på en mikrovågsugn, eftersom det inte finns något behov av CPU-instruktioner och virtualiseringstekniker på värddatorn.

KVM - Fullfjädrad virtualisering, som använder all kraft från CPU:n och kan virtualisera vad som helst, hur som helst, skära det på längden och tvären.

Tvärtemot vad många tror att bland värdleverantörer kommer OpenVZ att bli översålt, men KVM kommer inte att göra det - lyckligtvis för den senare är KVM nu inte värre än sin bror.

Vad ska vi bära över?

Som testpersoner för överföringen var vi tvungna att använda hela skogen av operativsystem som är tillgängliga på OpenVZ: CentOS (6 och 7 versioner), Ubuntu (14, 16 och 18 LTS), Debian 7.

Det antogs att de flesta av OpenVZ-behållarna redan körde någon form av LAMPA, och vissa hade till och med mycket specifik programvara. Oftast var dessa konfigurationer med ISPmanager, VestaCP kontrollpanel (och oftast inte uppdaterade på flera år). Deras önskemål om överföring måste också beaktas.

Migreringen utförs samtidigt som IP-adressen för den överförda behållaren bevaras; vi antar att IP-adressen som behållaren hade sparas på den virtuella datorn och kommer att fungera utan problem.

Innan du överför, låt oss se till att vi har allt till hands:

• OpenVZ-server, full root-åtkomst till värddatorn, möjlighet att stoppa/montera/starta/ta bort behållare
• KVM-server, full root-åtkomst till värddatorn, med allt vad det innebär. Det antas att allt redan är konfigurerat och redo att gå.

Låt oss börja överföra

Innan vi börjar överföringen, låt oss definiera termer som hjälper dig att undvika förvirring:

KVM_NODE - KVM-värdmaskin
VZ_NODE - OpenVZ värdmaskin
CTID - OpenVZ container
VM - Virtuell KVM-server

Förbereder migrering och skapar virtuella maskiner.

Steg 1

Eftersom vi behöver flytta behållaren någonstans skapar vi VM med en liknande konfiguration som KVM_NODE.
Viktigt! Du måste skapa en virtuell dator på operativsystemet som för närvarande körs på CTID. Till exempel, om Ubuntu 14 är installerat på CTID, måste Ubuntu 14 installeras på den virtuella datorn. Mindre versioner är inte viktiga och deras avvikelse är inte så kritisk, men större versioner bör vara desamma.

Efter att ha skapat den virtuella datorn kommer vi att uppdatera paketen på CTID och på den virtuella datorn (inte att förväxla med uppdatering av operativsystemet - vi uppdaterar inte det, vi uppdaterar bara paketen och, om det kommer, OS-versionen i huvudet version).

För CentOS ser denna process ofarlig ut:

# yum clean all
# yum update -y

Och inte mindre ofarligt för Ubuntu och Debian:

# apt-get update
# apt-get upgrade

Steg 2

Installera på CTID, VZ_NODE и VM verktyg rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Vi installerar inget annat varken där eller där.

Steg 3

Vi gör ett stopp CTID på VZ_NODE team

vzctl stop CTID

Montering av bilden CTID:

vzctl mount CTID

Gå till mappen /vz/root/CTID och verkställa

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

Under roten, skapa en fil /root/exclude.txt - den kommer att innehålla en lista med undantag som inte kommer 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

Koppla till KVM_NODE och lansera vår VMså att den fungerar och är tillgänglig över nätverket.

Nu är allt klart för överföring. Gå!

Steg 4

Fortfarande under förtrollning uppträder vi

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

Kommandot rsync kommer att utföra överföringen, vi hoppas att nycklarna är tydliga - överföringen utförs med bevarande av symboliska länkar, åtkomsträttigheter, ägare och grupper, och kryptering är inaktiverad för högre hastighet (du kan använda något snabbare chiffer, men detta är inte så viktigt för den här uppgiften), liksom komprimering är inaktiverat.

När du har slutfört rsync, avsluta från chroot (genom att trycka på ctrl+d) och kör

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

Steg 5

Låt oss utföra flera steg som hjälper oss att starta den virtuella datorn efter överföring från OpenVZ.
På servrar med SYSTEMD låt oss köra ett kommando som hjälper oss att logga in på en vanlig konsol, till exempel via en VNC-serverskärm

mv /etc/systemd/system/getty.target.wants/[email protected] /etc/systemd/system/getty.target.wants/[email protected]

På servrar 6 CentOS и 7 CentOS Se till att installera en ny kärna:

yum install kernel-$(uname -r)

Servern kan laddas från den, men efter överföringen kan den sluta fungera eller tas bort.

På servern 7 CentOS du måste tillämpa en liten fix för PolkitD, annars kommer servern att krascha för alltid:

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; }

På alla servrar, om mod_fcgid för Apache installerades, kommer vi att utföra en liten fix med rättigheter, annars kommer webbplatser som använder mod_fcgid att krascha med fel 500:

chmod +s `which suexec` && apachectl restart

Och det sista är användbart för Ubuntu och Debian-distributioner. Detta operativsystem kan krascha in i en evig start med ett fel

loopar för snabbt. strypande utförande lite

obehagligt, men lätt att fixa, beroende på OS-versionen.

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

vi genomför

dbus-uuidgen

om vi får ett fel

/usr/local/lib/libdbus-1.so.3: version `LIBDBUS_PRIVATE_1.10.8' hittades inte

kontrollera förekomsten av 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

om allt är i sin ordning gör vi det

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.

Den andra lösningen på problemet med strypande utförande lite Lämplig för nästan alla Ubuntu- och Debian-distributioner.

Vi genomför

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

Och för ubuntu 14, Debian 7 Dessutom utför vi:

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

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

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

Steg 6

Vi startar om den virtuella datorn, kontrollerar i VNC hur laddningen fortskrider och, idealiskt, kommer allt att laddas utan problem. Även om det är möjligt att vissa specifika problem kommer att dyka upp efter migreringen ligger de utanför denna artikels omfattning och kommer att korrigeras när de uppstår.

Jag hoppas att denna information är användbar! 🙂

Källa: will.com