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.

I motsats till vad många tror, ​​i miljön webbhotellleverantörer OpenVZ är översålt, men det är inte KVM. Lyckligtvis för den senare är KVM nu lika översålt som sin bror.

Vad ska vi bära över?

Hela skogen av operativsystem som finns tillgängliga på OpenVZ var tvungna att användas som testpersoner för överföringen: CentOS (versionerna 6 och 7), 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.

Migrering utförs med bevarande IP-adresser För en portabel behållare antar vi att behållarens IP-adress bevaras på den virtuella datorn och fungerar 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 maskin på samma operativsystem som för närvarande körs på CTID:t. Om till exempel CTID:t körs Ubuntu 14, då måste du installera det på den virtuella maskinen också Ubuntu 14. Mindre versioner är inte viktiga och deras avvikelser är inte så kritiska, men större versioner måste 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 Denna process ser harmlös ut:

# yum clean all
# yum update -y

Och inte mindre ofarlig för Ubuntu, 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/getty@tty2.service /etc/systemd/system/getty.target.wants/getty@tty1.service

På servrar CentOS 6 и CentOS 7 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 CentOS 7 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 slutligen kommer det att vara användbart för Ubuntu, Debian distributioner. Detta operativsystem kan krascha och starta permanent med ett felmeddelande

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 и Debian utdelningar.

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 gjorde vi? Vi återställde meddelandebussen, som saknades vid uppstart. Debian/Ubuntu och tog bort modules_dep, som kom från OpenVZ och förhindrade att många kärnmoduler laddades.

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