🥇 Sådan flytter du en OpenVZ 6-container til en KVM-server uden hovedpine

Alle som en gang i livet har haft brug for at overføre en OpenVZ-container til en server med fuld virtualisering KVM, har mødt nogle problemer:

Mest af informationen er simpelthen forældet og var relevant for operativsystemer, der længe har nået EOL-cyklussen.
Der gives altid forskellige informationer for forskellige OS, og der overvejes aldrig mulige fejl under migreringen.
Nogle gange må man håndtere konfigurationer, der ikke vil fungere efter migreringen.

Når man flytter én server, kan man altid rette noget undervejs, men hvad med at flytte en hel klynge?

I denne artikel vil jeg forsøge at forklare, hvordan man korrekt migrerer en OpenVZ-container til KVM med minimal nedetid og hurtige løsninger på alle problemer.

Lidt undervisning: hvad er OpenVZ og hvad er KVM?

Vi vil ikke dykke ned i terminologien, men sige det i generelle træk:

OpenVZ — virtualisering på niveau med operativsystemet, kan implementeres selv på en mikrobølgeovn, da der ikke er behov for CPU-instruktioner og virtualiseringsteknologier på værtmaskinen.

KVM — fuld virtualisering, der bruger hele CPU's kraft og kan virtualisere hvad som helst, som man vil, på kryds og tværs.

På trods af den udbredte opfattelse om, at i miljøet hostingudbydere oversælges OpenVZ, men KVM ikke — heldigvis for sidstnævnte, oversælges KVM nu ikke ringere end sin bror.

Hvad skal vi overføre?

Som testobjekter til overførslen måtte vi bruge hele skoven af operativsystemer, der er tilgængelige på OpenVZ: CentOS (versionerne 6 og 7), Ubuntu (14, 16 og 18 LTS), Debian 7.

Det antages, at der i størstedelen af OpenVZ-containerne allerede kører en eller anden LAMP, og nogle har endda en meget specifik software. Oftest var det konfigurationer med kontrolpanelet ISPmanager, VestaCP (og oftest, ikke opdateret i årevis). Der må også tages hensyn til deres krav til overførslen.

Migreringen udføres med bevaring af IP-adresser den overførbare container, lad os antage, at IP'en, som containeren havde, bevares på VM og vil fungere uden problemer.

Før vi overfører, skal vi sikre os, at vi har alt på plads:

OpenVZ-server, fuld root-adgang til værtmaskinen, mulighed for at stoppe/mount/muliggøre/slette containere
KVM-server, fuld root-adgang til hostmaskinen, med alle tilhørende funktioner. Det antages, at alt allerede er konfigureret og klar til brug.

Lad os begynde overførslen

Inden vi starter overførslen, lad os definere termerne, der gør det lettere at forstå:

KVM_NODE — KVM-hostmaskinen
VZ_NODE — OpenVZ-hostmaskinen
CTID — OpenVZ-container
VM — KVM-virtuel server

Forberedelse til overførsel og oprettelse af virtuelle maskiner.

Trin 1

Da vi skal overføre containeren, opretter vi VM med en tilsvarende konfiguration på KVM_NODE.
Vigtigt! VM'en skal oprettes på det samme operativsystem, som kører på CTID. For eksempel, hvis CTID har Ubuntu 14 installeret, så skal VM også have Ubuntu 14. Mindre versioner er ikke så vigtige, og deres uoverensstemmelse er ikke kritisk, men hovedversionerne skal være ens.

Efter oprettelsen af VM, opdaterer vi pakkerne på CTID og VM (forveksl ikke med opdatering af OS — vi opdaterer ikke OS, kun pakkerne og, hvis det er nødvendigt, OS-versionen inden for hovedversionen).

For CentOS ser denne proces harmløs ud:

# yum clean all
# yum update -y

Og ikke mindre harmløs for Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Trin 2

Installerer på CTID, VZ_NODE og VM værktøjet rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Installer ikke noget andet hverken dér eller dér.

Trin 3

Vi stopper CTID og få en fungerende kommando. VZ_NODE med kommandoen

vzctl stop CTID

Vi monterer billedet CTID:

vzctl mount CTID

Vi går ind i mappen /vz/root/CTID og udfører

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

Under chroot opretter vi filen /root/exclude.txt — den vil indeholde en liste over undtagelser, der ikke kommer over på 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

Vi opretter forbindelse til KVM_NODE og starter vores VM, så det fungerer og er tilgængeligt over netværket.

Nu er alt klar til overførslen. Lad os komme i gang!

Trin 4

Mens vi stadig er under chroot, udfører vi

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

rsync-kommandoen vil udføre overførslen, og vi håber, at nøgleoperationerne er klare — overførslen foretages med bevarelse af symlinks, adgange, ejerskaber og grupper uden kryptering for større hastighed (man kunne have brugt en hurtigere cipher, men det var ikke så vigtigt i denne opgave), ligesom kompressionen også er deaktiveret.

Efter afslutningen af rsync forlader vi chroot (ved at trykke ctrl+d) og udfører

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

Trin 5

Vi udfører nogle handlinger, der vil hjælpe os med at starte VM efter overførslen fra OpenVZ.
På servere med Systemd viabiliserer vi en kommando, der hjælper os med at logge ind i den almindelige konsol, lad os sige, via VNC-skærmen på serveren

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

På serverne CentOS 6 og CentOS 7 vi skal sørge for at installere en ny kerne:

yum install kernel-$(uname -r)

Serveren kan starte fra den, men efter flytningen kan det stoppe med at fungere eller blive slettet.

På serveren CentOS 7 er det nødvendigt at anvende et lille fix til PolkitD, ellers vil serveren falde i en evig boot:

getent group polkitd >/dev/null && echo -e "e[1;32mpolkitd gruppe eksisterer alleredee[0m" || { groupadd -r polkitd && echo -e "e[1;33mTilføjede manglende polkitd gruppee[0m" || echo -e "e[1;31mTilføjelse af polkitd gruppe FEILEDe[0m"; }

getent passwd polkitd >/dev/null 
&& echo -e "e[1;32mpolkitd bruger eksisterer alleredee[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "Bruger for polkitd" polkitd && echo -e "e[1;33mTilføjede manglende polkitd bruger e[0m" || echo -e "e[1;31mTilføjelse af polkitd bruger FEILEDe[0m"; }

rpm -Va polkit* && echo -e "e[1;32mpolkit* rpm verifikation bestod e[0m" || { echo -e "e[1;33mNulstiller polkit* rpm bruger/gruppe ejerskab & perms e[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

På alle servere, hvis mod_fcgid blev installeret til Apache, anvender vi et lille fix med rettigheder, ellers vil websites, der bruger mod_fcgid, falde med en fejl 500:

chmod +s `which suexec` && apachectl restart

Og sidst, dette vil være nyttigt for Ubuntu, Debian-distributioner. Dette OS kan falde i en evig boot med fejlen

looping too fast. throttling execution a little

ubehageligt, men let at fixe, afhængigt af OS-versionen.

På Debian 9 fixet ser således 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′ not found

tjekker vi for 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 <-- denne er nødvendig
libdbus-1.so.3.14.16

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

Hvis det ikke hjælper — prøver vi den anden mulighed.

Den anden mulighed for at løse problemet med throttling execution a little gælder praktisk talt for alle Ubuntu og Debian-distributioner.

Vi udfører

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

Allowed Logout URLs Ubuntu 14, Debian 7 yderligere 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 har genoprettet messagebus, som manglede for at starte Debian/Ubuntu, og fjernet modules_dep, der kom fra OpenVZ og forstyrrede indlæsningen af mange kerne-moduler.

Trin 6

Vi genstarter VM, tjekker i VNC, hvordan indlæsningen går, og i ideelt set — vil alt starte uden problemer. Selvom der muligvis opstår nogle specifikke problemer efter migreringen — men de falder uden for rammerne af denne artikel og rettes efterhånden som de opstår.

Jeg håber, at denne information vil være nyttig! 🙂

Kilde: habr.com