🥇Ako presunúť OpenVZ 6 kontajner na KVM server bez bolesti hlavy

Každý, kto niekedy potreboval preniesť OpenVZ kontajner na server s plnohodnotnou virtualizáciou KVM, sa stretol s niekoľkými problémami:

Väčšina informácií je už dávno zastaraná a bola aktuálna pre dávno ukončené EOL cykly OS.
Pre rôzne OS je vždy k dispozícii rôzna informácia a nikdy nie sú zohľadnené možné chyby pri migrácii.
Niekedy sa treba vysporiadať s konfiguráciami, ktoré sa po migrácii neustále nechcú spustiť.

Pri prenose jedného servera sa vždy dá niečo opraviť za pochodu, ale čo pri prenose celého klastru?

V tomto článku sa pokúsim vysvetliť, ako správne migrovať OpenVZ kontajner na KVM s minimálnym downtime a rýchlym riešením všetkých problémov.

Malý prehľad: čo je OpenVZ a čo je KVM?

Nebudeme sa zaoberať terminológiou, a tak si povieme vo všeobecnosti:

OpenVZ — virtualizácia na úrovni operačného systému, ktorá sa dá spustiť dokonca aj na mikrovlnke, pretože nie je potrebné, aby procesor mal inštrukcie a technológie virtualizácie na hostiteľskom stroji.

KVM — plnohodnotná virtualizácia, ktorá využíva celú silu CPU a dokáže virtualizovať čokoľvek, akýmkoľvek spôsobom, podlomiť a prekrižovať.

Napriek všeobecne akceptovanému názoru, že v prostredí hostingových poskytovateľov OpenVZ sa preťažuje, zatiaľ čo KVM nie — našťastie pre posledný spomenutý, KVM sa dnes preťažuje rovnako ako jeho kolega.

Čo budeme prenášať?

Ako pokusy na prenos sme museli použiť celý les operačných systémov, ktoré sú dostupné na OpenVZ: CentOS (verzia 6 a 7), Ubuntu (14, 16 a 18 LTS), Debian 7.

Predpokladalo sa, že na väčšine kontajnerov OpenVZ už beží nejaký LAMP, a niektoré majú dokonca veľmi špecifický softvér. Najčastejšie to boli konfigurácie s ovládacou panelom ISPmanager, VestaCP (a najčastejšie, neaktualizované celé roky). Je potrebné zohľadniť aj ich požiadavky na prenos.

Migrácia sa vykonáva so zachovaním IP adresy prenášaného kontajnera, predpokladajme, že IP, ktorá bola u kontajnera, zostáva na VM a bude fungovať bez problémov.

Pred prenosom sa uistíme, že máme všetko pripravené:

Server OpenVZ, plný root prístup k hostiteľskému stroju, možnosť zastavovať/montovať/spúšťať/odstraňovať kontajnery.
Server KVM, plný root prístup k hostiteľskému stroju, so všetkými výhodami. Predpokladáme, že všetko už je nastavené a pripravené na prácu.

Začíname s migráciou

Predtým, ako začneme s migráciou, definujeme pojmy, ktoré nám pomôžu nezmýliť sa:

KVM_NODE — KVM hostiteľský server
VZ_NODE — OpenVZ hostiteľský server
CTID — OpenVZ kontajner
VM — KVM virtuálny server

Príprava na migráciu a vytvorenie virtuálnych strojov.

Krok 1

Keďže potrebujeme presunúť kontajner, vytvoríme VM s podobnou konfiguráciou na KVM_NODE.
Dôležité! VM treba vytvoriť na tej operacnej sústave, ktorá aktuálne beží na CTID. Napríklad, ak je na CTID nainštalovaný Ubuntu 14, aj na VM musíme nainštalovať Ubuntu 14. Menšie verzie nie sú dôležité a ich nezhody nie sú také kritické, ale hlavné verzie musia byť rovnaké.

Po vytvorení VM vykonáme aktualizáciu balíkov na CTID a na VM (nezamieňajte s aktualizáciou OS — tú neaktualizujeme, aktualizujeme len balíky a, ak sa objaví, verziu OS v rámci hlavnej verzie).

Pre CentOS tento proces vyzerá zdanlivo bez problémov:

# yum clean all
# yum update -y

A rovnako bez problémov pre Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Krok 2

Inštalujeme na CTID, VZ_NODE a VM nástroj rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Nič iné neinštalujeme ani tu, ani tam.

Krok 3

Vykonávame zastavenie CTID na VZ_NODE príkazom

vzctl stop CTID

Pripojíme obraz CTID:

vzctl mount CTID

Prejdeme do zložky /vz/root/CTID a vykonáme

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

V prostredí chroot vytvoríme súbor /root/exclude.txt — ten bude obsahovať zoznam výnimiek, ktoré sa nedostanú na nový 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

Pripojíme sa k KVM_NODE a spustíme náš VM, aby fungoval a bol prístupný cez sieť.

Teraz je všetko pripravené na migráciu. Ideme na to!

Krok 4

Ešte v chroute vykonávame

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

Príkaz rsync vykoná migráciu, dúfame, že klávesy sú jasné — migrácia sa vykonáva so zachovaním symbolických odkazov, oprávnení, vlastníkov a skupín a šifrovanie je vypnuté pre vyššiu rýchlosť (mohli by sme použiť nejaký rýchlejší cipher, ale to nie je také zásadné v rámci tejto úlohy), rovnako ako kompresia je vypnutá.

Po dokončení vykonávania rsync vyjdeme z chroot (stlačením ctrl+d) a vykonáme

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

Krok 5

Vykonáme niekoľko krokov, ktoré nám pomôžu v spustení VM po migrácii z OpenVZ.
Na serveroch s Systemd vykonáme príkaz, ktorý nám pomôže sa prihlásiť do bežnej konzoly, povedzme, cez VNC na obrazovke servera

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

Na serveroch CentOS 6 a CentOS 7 určite nainštalujeme čerstvé jadro:

yum install kernel-$(uname -r)

Server can be booted from it, but after migration it may stop working or be removed.

On the server CentOS 7 it is necessary to apply a small fix for PolkitD, otherwise, the server will fall into an endless boot:

getent group polkitd >/dev/null && echo -e "e[1;32mpolkitd group already exists e[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 & perms e[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

On all servers, if mod_fcgid was installed for Apache, we will perform a small fix with permissions; otherwise, websites using mod_fcgid will crash with a 500 error:

chmod +s `which suexec` && apachectl restart

And lastly, this will be useful for Ubuntu and Debian distributions. This OS can fall into an endless boot with the error

looping too fast. throttling execution a little

unpleasant, but easily fixed, depending on the OS version.

Na Debian 9 the fix looks like this:

execute

dbus-uuidgen

if we get an error

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

check for the presence of 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 <-- this one is needed
libdbus-1.so.3.14.16

if everything is fine, execute

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

If that doesn't help — we try the second option.

The second option for solving the problem with throttling execution a little is suitable for almost all Ubuntu and Debian distributions.

Execute

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

A pre Ubuntu 14, Debian 7 additionally execute:

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

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

What did we do? We restored the missing messagebus needed for starting Debian/Ubuntu and removed modules_dep, which came from OpenVZ and interfered with booting many kernel modules.

Krok 6

Reboot the VM, check in VNC how the boot is going and ideally — everything will boot up without issues. However, some specific problems may arise after migration — but they are beyond the scope of this article and are fixed as they occur.

I hope this information will be useful! 🙂

Zdroj: habr.com