🥇Hoe verplaats je een OpenVZ 6-container naar een KVM-server zonder gedoe

Iedereen die ooit in zijn leven een OpenVZ-container naar een server met volledige KVM-virtualisatie heeft moeten verplaatsen, heeft met enkele problemen te maken gehad:

Het meeste van de informatie is simpelweg verouderd en was relevant voor al lang verlopen EOL-cycli van besturingssystemen.
Voor verschillende besturingssystemen wordt altijd verschillende informatie verstrekt, en mogelijke fouten bij de migratie worden nooit overwogen.
Soms moet je omgaan met configuraties die na de migratie keer op keer niet willen werken.

Bij het verplaatsen van één server kun je altijd iets ter plaatse corrigeren, maar wat als je een hele cluster verplaatst?

In dit artikel probeer ik uit te leggen hoe je een OpenVZ-container naar KVM migreert met minimale downtime en een snelle oplossing voor alle problemen.

Een korte uitleg: wat is OpenVZ en wat is KVM?

Laten we niet te diep op de terminologie ingaan, maar het in grote lijnen samenvatten:

OpenVZ — virtualisatie op niveau van het besturingssysteem, die zelfs op een magnetron kan worden uitgerold, omdat er geen behoefte is aan CPU-instructies en virtualisatietechnologieën op de hostmachine.

KVM — volledige virtualisatie die de volledige kracht van de CPU benut en in staat is om alles te virtualiseren, op elke gewenste manier, in elke richting.

In tegenstelling tot de wijdverbreide opvatting dat in de omgeving van hostingproviders OpenVZ overgeproduceerd wordt en KVM niet — tot vreugde van de laatsten, KVM wordt tegenwoordig niet minder overgeproduceerd dan zijn neef.

Wat gaan we verplaatsen?

Als proefobjecten voor de migratie moesten we het volledige woud van besturingssystemen gebruiken die beschikbaar zijn op OpenVZ: CentOS (versies 6 en 7), Ubuntu (14, 16 en 18 LTS), Debian 7.

Het werd verondersteld dat op het grootste deel van de OpenVZ-containers al een soort van LAMP draait, en sommige hebben zelfs zeer specifieke software. Meestal waren dit configuraties met controlepanelen zoals ISPmanager, VestaCP (en meestal, jarenlang niet bijgewerkt). We moeten ook rekening houden met hun vereisten voor de migratie.

De migratie vindt plaats met behoud van IP-adressen de vervoerde container, we gaan ervan uit dat het IP-adres dat de container had, behouden blijft op de VM en zonder problemen zal functioneren.

Voordat we verhuizen, zorgen we ervoor dat we alles in handen hebben:

OpenVZ-server, volledige root-toegang tot de hostmachine, de mogelijkheid om containers te stoppen/montageren/te starten/verwijderen.
KVM-server, volledige root-toegang tot de hostmachine, met alle gevolgen van dien. Er wordt aangenomen dat alles al is ingesteld en klaar is voor gebruik.

We beginnen met de migratie

Voordat we beginnen met de migratie, laten we de termen definiëren die verwarring zullen voorkomen:

KVM_NODE — KVM-hostmachine
VZ_NODE — OpenVZ-hostmachine
CTID — OpenVZ-container
VM — KVM-virtuele server

Voorbereiding van de migratie en creatie van virtuele machines.

Stap 1

Aangezien we de container ergens naartoe moeten verplaatsen, creëren we VM met een vergelijkbare configuratie op KVM_NODE.
Belangrijk! De VM moet precies draaien op hetzelfde besturingssysteem dat momenteel op CTID draait. Bijvoorbeeld, als CTID Ubuntu 14 draait, moet VM ook Ubuntu 14 draaien. Minder belangrijke versies zijn niet cruciaal en hun afwijking is minder kritisch, maar grotere versies moeten identiek zijn.

Na het aanmaken van de VM, voeren we een pakketupdate uit op CTID en op de VM (verwar dit niet met een besturingssysteemupdate — we updaten het besturingssysteem niet, alleen de pakketten en, als het beschikbaar is, de versie van het besturingssysteem binnen de hoofdversie).

Voor CentOS ziet dit proces er onschuldig uit:

# yum clean all
# yum update -y

En even onschuldig voor Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Stap 2

We installeren op CTID, VZ_NODE en VM een tool rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

We installeren verder niets hier of daar.

Stap 3

We stoppen CTID en een werkende opdracht krijgen. VZ_NODE met het commando

vzctl stop CTID

Mounting the image CTID:

vzctl mount CTID

We gaan naar de map /vz/root/CTID en voeren uit

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

Binnen chroot maken we het bestand /root/exclude.txt aan — dit bevat een lijst van uitzonderingen die niet op de nieuwe server komen.

/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

We verbinden met KVM_NODE en starten onze VM, zodat deze draait en beschikbaar is via het netwerk.

Nu is alles klaar voor de migratie. Laten we gaan!

Stap 4

Terwijl we nog onder chroot zijn, voeren we uit

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

De rsync-opdracht zal de migratie uitvoeren, hopelijk zijn de sleutels duidelijk — de migratie wordt uitgevoerd met behoud van symbolische links, toegangsrechten, eigenaren en groepen en versleuteling is uitgeschakeld voor een hogere snelheid (je had een snellere cipher kunnen gebruiken, maar dat is niet zo cruciaal voor deze taak), net als compressie is uitgeschakeld.

Na het voltooien van de rsync, verlaten we chroot (door ctrl+d in te drukken) en voeren we uit

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

Stap 5

We voeren een paar acties uit die ons helpen bij het starten van de VM na de migratie van OpenVZ.
Op servers met Systemd voeren we de opdracht uit die ons helpt in te loggen op de normale console, bijvoorbeeld via een VNC-scherm van de server

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

Op servers CentOS 6 en CentOS 7 moeten we beslist een versere kernel installeren:

yum install kernel-$(uname -r)

De server kan er vanaf worden opgestart, maar na de migratie kan deze stoppen met werken of worden verwijderd.

Op de server CentOS 7 moet een kleine fix voor PolkitD worden toegepast, anders valt de server in een eindeloze bootloop:

getent group polkitd >/dev/null && echo -e "e[1;32mpolkitd groep bestaat alse[0m" || { groupadd -r polkitd && echo -e "e[1;33mToegevoegd ontbrekende polkitd groep[0m" || echo -e "e[1;31mToevoegen van polkitd groep is MISLUKTEde[0m"; }

getent passwd polkitd >/dev/null 
&& echo -e "e[1;32mpolkitd gebruiker bestaat alse[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "Gebruiker voor polkitd" polkitd && echo -e "e[1;33mToegevoegd ontbrekende polkitd gebruiker[0m" || echo -e "e[1;31mToevoegen van polkitd gebruiker is MISLUKTEde[0m"; }

rpm -Va polkit* && echo -e "e[1;32mpolkit* rpm verificatie geslaagd[0m" || { echo -e "e[1;33mHerstellen van polkit* rpm gebruikers/groep eigendom & permse[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

Op alle servers, als mod_fcgid voor Apache is geïnstalleerd, passen we een kleine fix toe met rechten, anders zullen de sites die mod_fcgid gebruiken, falen met een fout 500:

chmod +s `which suexec` && apachectl restart

En tot slot, dit is nuttig voor Ubuntu en Debian distributies. Dit OS kan in een eindeloze bootloop terechtkomen met de fout

looping too fast. throttling execution a little

onaangenaam, maar gemakkelijk op te lossen, afhankelijk van de versie van het OS.

Op Debian 9 de fix ziet er als volgt uit:

we voeren uit

dbus-uuidgen

als we een foutmelding krijgen

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

controleren we op 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 <-- dit is nodig
libdbus-1.so.3.14.16

als alles in orde is, voeren we uit

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

Als dit niet helpt — proberen we de tweede optie.

De tweede optie om het probleem met throttling execution a little werkt vrijwel voor alle Ubuntu en Debian distributies.

We execute

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

Allowed Logout URLs Ubuntu 14, Debian 7 uiteraard, we voeren ook uit:

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

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

Wat hebben we gedaan? We hebben messagebus hersteld, dat ontbrak voor het opstarten van Debian/Ubuntu en we hebben modules_dep verwijderd, dat van OpenVZ kwam en de opstart van veel kernelmodules verstoorde.

Stap 6

We herstarten de VM, controleren in VNC hoe de opstart verloopt en idealiter — alles zal zonder problemen opstarten. Hoewel, mogelijk zullen er enkele specifieke problemen na de migratie optreden — maar deze vallen buiten de reikwijdte van dit artikel en worden opgelost naarmate ze zich voordoen.

Ik hoop dat deze informatie nuttig zal zijn! 🙂

Bron: habr.com