Sådan overføres OpenVZ 6-beholder til KVM-server uden hovedpine

Enhver, der har haft brug for at overføre en OpenVZ-container til en server med fuld KVM-virtualisering mindst én gang i deres liv, er stødt på nogle problemer:

• De fleste af oplysningerne er simpelthen forældede og var relevante for OS'er, der længe havde bestået EOL-cyklussen
• Der gives altid forskellige oplysninger for forskellige operativsystemer, og mulige fejl under migreringen tages aldrig i betragtning
• Nogle gange er du nødt til at forholde dig til konfigurationer, der nu og da ikke vil fungere efter migrering

Når du overfører 1 server, kan du altid ordne noget med det samme, men når du overfører en hel cluster?

I denne artikel vil jeg forsøge at fortælle dig, hvordan du korrekt migrerer en OpenVZ-container til KVM med minimal nedetid og en hurtig løsning på alle problemer.

Et lille uddannelsesprogram: hvad er OpenVZ, og hvad er KVM?

Vi vil ikke gå dybt ind i terminologien, men vil sige i generelle vendinger:

OpenVZ — virtualisering på operativsystemniveau, du kan endda installere det på en mikrobølgeovn, da der ikke er behov for CPU-instruktioner og virtualiseringsteknologier på værtsmaskinen.

KVM - fuldgyldig virtualisering, der bruger al CPU'ens kraft og er i stand til at virtualisere hvad som helst på nogen måde, skære det på langs og på tværs.

I modsætning til populær tro, at blandt hostingudbydere vil OpenVZ blive oversolgt, men KVM vil ikke - heldigvis for sidstnævnte er KVM nu ikke værre end sin bror.

Hvad vil vi overføre?

Som testpersoner for overførslen var vi nødt til at bruge hele skoven af ​​operativsystemer, der er tilgængelige på OpenVZ: CentOS (6 og 7 versioner), Ubuntu (14, 16 og 18 LTS), Debian 7.

Det blev antaget, at de fleste af OpenVZ-beholderne allerede kørte en slags LAMPE, og nogle havde endda noget meget specifik software. Oftest var disse konfigurationer med ISPmanager, VestaCP kontrolpanel (og oftest ikke opdateret i årevis). Deres overførselsanmodninger skal også tages i betragtning.

Migrering udføres, mens IP-adressen på den overførte container bevares; vi antager, at den IP, som containeren havde, er gemt på VM'en og vil fungere uden problemer.

Før du overfører, lad os sikre os, at vi har alt ved hånden:

• OpenVZ-server, fuld root-adgang til værtsmaskinen, mulighed for at stoppe/montere/starte/slette containere
• KVM-server, fuld root-adgang til værtsmaskinen, med alt hvad det indebærer. Det antages, at alt allerede er konfigureret og klar til at gå.

Lad os begynde at overføre

Før vi begynder overførslen, lad os definere termer, der hjælper dig med at undgå forvirring:

KVM_NODE - KVM værtsmaskine
VZ_NODE - OpenVZ værtsmaskine
CTID - OpenVZ container
VM - Virtuel KVM-server

Forberedelse til migrering og oprettelse af virtuelle maskiner.

Trin 1

Da vi skal flytte containeren et sted hen, opretter vi VM med en lignende konfiguration til KVM_NODE.
Vigtigt! Du skal oprette en VM på det operativsystem, der i øjeblikket kører på CTID. For eksempel, hvis Ubuntu 14 er installeret på CTID, så skal Ubuntu 14 installeres på VM. Mindre versioner er ikke vigtige, og deres uoverensstemmelse er ikke så kritisk, men større versioner bør være de samme.

Efter at have oprettet VM'en, vil vi opdatere pakkerne på CTID'en og på VM'en (ikke at forveksle med opdatering af OS - vi opdaterer det ikke, vi opdaterer kun pakkerne og, hvis det ankommer, OS-versionen i hovedmenuen version).

For CentOS ser denne proces harmløs ud:

# yum clean all
# yum update -y

Og ikke mindre harmløs for Ubuntu og Debian:

# apt-get update
# apt-get upgrade

Trin 2

Installer på CTID, VZ_NODE и VM nytte rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Vi installerer ikke andet hverken der eller der.

Trin 3

Vi gør et stop CTID på VZ_NODE hold

vzctl stop CTID

Montering af billedet CTID:

vzctl mount CTID

Gå til mappen /vz/root/CTID og udføre

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

Under roden skal du oprette en fil /root/exclude.txt - den vil indeholde en liste over undtagelser, der ikke kommer til den nye server

/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

Forbinde til KVM_NODE og lancere vores VMså det fungerer og er tilgængeligt over netværket.

Nu er alt klar til overførsel. Gå!

Trin 4

Stadig under fortryllelsen optræder vi

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

Kommandoen rsync vil udføre overførslen, vi håber, at nøglerne er klare - overførslen udføres med bevarelse af symbolske links, adgangsrettigheder, ejere og grupper, og kryptering er deaktiveret for større hastighed (du kan bruge noget hurtigere kryptering, men dette er ikke så vigtigt for denne opgave), samt komprimering er deaktiveret.

Efter at have fuldført rsync, afslutte fra chroot (ved at trykke på ctrl+d) og udfør

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

Trin 5

Lad os udføre flere trin, der vil hjælpe os med at starte VM'en efter overførsel fra OpenVZ.
På servere med systemd lad os udføre en kommando, der hjælper os med at logge ind på en almindelig konsol, for eksempel gennem en VNC-serverskærm

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

På servere 6 CentOS и 7 CentOS Sørg for at installere en frisk kerne:

yum install kernel-$(uname -r)

Serveren kan indlæses fra den, men efter overførslen kan den stoppe med at fungere eller blive slettet.

På serveren 7 CentOS du skal anvende en lille rettelse til PolkitD, ellers vil serveren gå ned for evigt:

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å alle servere, hvis mod_fcgid til Apache blev installeret, vil vi udføre en lille rettelse med rettigheder, ellers vil websteder, der bruger mod_fcgid, gå ned med fejl 500:

chmod +s `which suexec` && apachectl restart

Og den sidste ting er nyttig til Ubuntu- og Debian-distributioner. Dette operativsystem kan gå ned i en evig boot med en fejl

sløjfer for hurtigt. droslende udførelse lidt

ubehageligt, men let løst, afhængigt af OS-versionen.

On Debian 9 rettelsen ser sådan ud:

vi udfører

dbus-uuidgen

hvis vi får en fejl

/usr/local/lib/libdbus-1.so.3: version `LIBDBUS_PRIVATE_1.10.8' blev ikke fundet

kontrollere tilstedeværelsen af ​​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

hvis alt er i orden, 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

Hvis det ikke hjælper, så prøv den anden mulighed.

Den anden løsning på problemet med droslende udførelse lidt Velegnet til næsten alle Ubuntu- og Debian-distributioner.

Vi udfører

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

Og for Ubuntu 14, Debian 7 Derudover udfører vi:

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

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

Hvad har vi gjort? Vi genoprettede messagebus, som manglede til at køre Debian/Ubuntu, og fjernede modules_dep, som kom fra OpenVZ og forstyrrede indlæsningen af ​​mange kernemoduler.

Trin 6

Vi genstarter VM'en, tjekker i VNC, hvordan indlæsningen skrider frem, og ideelt set vil alt indlæses uden problemer. Selvom det er muligt, at nogle specifikke problemer vil dukke op efter migreringen, er de uden for denne artikels omfang og vil blive rettet, efterhånden som de opstår.

Jeg håber, at disse oplysninger er nyttige! 🙂

Kilde: www.habr.com