ProHoster > Blog > Administrácia > Ako preniesť kontajner OpenVZ 6 na server KVM bez bolesti hlavy

Ako preniesť kontajner OpenVZ 6 na server KVM bez bolesti hlavy

Každý, kto aspoň raz v živote potreboval preniesť kontajner OpenVZ na server s plnou virtualizáciou KVM, sa stretol s niekoľkými problémami:

  • Väčšina informácií je jednoducho zastaraná a bola relevantná pre operačné systémy, ktoré už dávno prešli cyklom EOL
  • Pre rôzne operačné systémy sa vždy poskytujú rôzne informácie a možné chyby počas migrácie sa nikdy nezohľadňujú
  • Niekedy sa musíte vysporiadať s konfiguráciami, ktoré po migrácii z času na čas nechcú fungovať

Keď prenášate 1 server, môžete vždy niečo opraviť za chodu, ale keď prenášate celý klaster?

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

Malý vzdelávací program: čo je OpenVZ a čo je KVM?

Nebudeme zachádzať hlboko do terminológie, ale povieme všeobecne:

OpenVZ — virtualizácia na úrovni operačného systému, môžete ju dokonca nasadiť na mikrovlnke, keďže na hostiteľskom počítači nie sú potrebné inštrukcie CPU a virtualizačné technológie.

KVM - plnohodnotná virtualizácia využívajúca všetok výkon CPU a schopná virtualizovať čokoľvek akýmkoľvek spôsobom, rezať to pozdĺžne aj naprieč.

Na rozdiel od všeobecného presvedčenia, že medzi poskytovateľmi hostingu sa OpenVZ stane prepredaným, ale KVM nie – našťastie pre druhého nie je KVM teraz prepredaný o nič horšie ako jeho brat.

Čo si prenesieme?

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

Predpokladalo sa, že väčšina kontajnerov OpenVZ už bežala na nejakom druhu LAMP a niektoré dokonca mali nejaký veľmi špecifický softvér. Najčastejšie to boli konfigurácie s ISPmanager, ovládacím panelom VestaCP (a najčastejšie roky neaktualizované). Do úvahy treba vziať aj ich žiadosti o prevod.

Migrácia prebieha pri zachovaní IP adresy prenášaného kontajnera, budeme predpokladať, že IP, ktorú kontajner mal, je uložená na VM a bude fungovať bez problémov.

Pred prevodom sa uistite, že máme všetko po ruke:

  • OpenVZ server, úplný root prístup k hostiteľskému počítaču, schopnosť zastaviť/pripojiť/spustiť/vymazať kontajnery
  • KVM server, úplný root prístup k hostiteľskému počítaču so všetkým, čo to znamená. Predpokladá sa, že všetko je už nakonfigurované a pripravené na použitie.

Začnime prenášať

Skôr než začneme s prevodom, definujme pojmy, ktoré vám pomôžu vyhnúť sa nejasnostiam:

KVM_NODE - hostiteľský stroj KVM
VZ_NODE - Hostiteľský stroj OpenVZ
CTID - kontajner OpenVZ
VM - virtuálny server KVM

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

Krok 1

Keďže kontajner potrebujeme niekam presunúť, vytvoríme VM s podobnou konfiguráciou ako KVM_NODE.
Dôležité! Musíte vytvoriť VM v operačnom systéme, ktorý momentálne beží na CTID. Napríklad, ak je na CTID nainštalovaný Ubuntu 14, na virtuálnom počítači musí byť nainštalovaný Ubuntu 14. Menšie verzie nie sú dôležité a ich rozpor nie je taký kritický, ale hlavné verzie by mali byť rovnaké.

Po vytvorení VM aktualizujeme balíčky na CTID a na VM (nepliesť s aktualizáciou OS - neaktualizujeme ho, aktualizujeme iba balíčky a ak príde, tak verziu OS v rámci hlavného verzia).

Pre CentOS tento proces vyzerá neškodne:

# yum clean all
# yum update -y

A nemenej neškodné pre Ubuntu a Debian:

# apt-get update
# apt-get upgrade

Krok 2

Inštalovať na CTID, VZ_NODE и VM užitočnosť rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Nič iné tam ani tam neinštalujeme.

Krok 3

Robíme zastávku CTID na VZ_NODE tímom

vzctl stop CTID

Montáž obrazu CTID:

vzctl mount CTID

Prejdite do priečinka /vz/root/CTID a vykonať

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

Pod koreňom vytvorte súbor /root/exclude.txt - bude obsahovať zoznam výnimiek, ktoré sa na nový server nedostanú

/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 spustiť náš VMaby fungoval a bol dostupný cez sieť.

Teraz je všetko pripravené na prenos. Choď!

Krok 4

Stále pod kúzlom vystupujeme

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

Príkaz rsync vykoná prenos, dúfame, že kľúče sú jasné - prenos sa uskutoční so zachovaním symbolických odkazov, prístupových práv, vlastníkov a skupín a pre väčšiu rýchlosť je vypnuté šifrovanie (mohli by ste použiť nejakú rýchlejšiu šifru, ale to nie je pre túto úlohu také dôležité), ako aj kompresia je zakázaná.

Po dokončení rsync ukončite chroot (stlačením ctrl+d) a vykonajte

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

Krok 5

Urobme niekoľko krokov, ktoré nám pomôžu spustiť VM po prenose z OpenVZ.
Na serveroch s systemd vykonajme príkaz, ktorý nám pomôže prihlásiť sa do bežnej konzoly, napríklad cez obrazovku servera VNC

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

Na serveroch 6 CentOS и 7 CentOS Nezabudnite nainštalovať nové jadro:

yum install kernel-$(uname -r)

Server sa z neho dá načítať, ale po prenose môže prestať fungovať alebo byť vymazaný.

Na serveri 7 CentOS musíte použiť malú opravu pre PolkitD, inak server navždy zlyhá:

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; }

Ak bol na všetkých serveroch nainštalovaný mod_fcgid pre Apache, vykonáme malú opravu s právami, inak stránky používajúce mod_fcgid spadnú s chybou 500:

chmod +s `which suexec` && apachectl restart

A posledná vec je užitočná pre distribúcie Ubuntu a Debian. Tento OS môže naraziť do večného zavádzania s chybou

opakovanie príliš rýchlo. trochu priškrtenie popravy

nepríjemné, ale ľahko opraviteľné v závislosti od verzie OS.

Na Debian 9 oprava vyzera takto:

vykonávame

dbus-uuidgen

ak dostaneme chybu

/usr/local/lib/libdbus-1.so.3: verzia `LIBDBUS_PRIVATE_1.10.8′ sa nenašla

skontrolujte prítomnosť 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

ak je všetko v poriadku, urobíme to

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

Ak to nepomôže, skúste druhú možnosť.

Druhé riešenie problému s trochu priškrtenie popravy Vhodné pre takmer všetky distribúcie Ubuntu a Debian.

Vykonávame

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

A pre Ubuntu 14, Debian 7 Okrem toho vykonávame:

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

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

čo sme urobili? Obnovili sme messagebus, ktorý chýbal na spustenie Debian/Ubuntu, a odstránili sme modules_dep, ktorý pochádzal z OpenVZ a zasahoval do načítania mnohých modulov jadra.

Krok 6

Reštartujeme VM, skontrolujeme vo VNC ako prebieha načítanie a v ideálnom prípade sa všetko načíta bez problémov. Aj keď je možné, že sa po migrácii objavia nejaké špecifické problémy, sú nad rámec tohto článku a budú opravené, keď sa vyskytnú.

Dúfam, že tieto informácie sú užitočné! 🙂

Zdroj: hab.com

Pridať komentár