🥇Si të transferoni kontenierin OpenVZ 6 në një server KVM pa dhimbje koke

Çdokush që ka nevojë ndonjëherë në jetën e tij të transferojë një kontejner OpenVZ në një server me virtualizim të plotë KVM, përballet me disa probleme:

Shumica e informacionit është thjesht e vjetruar dhe ishte aktual për një cikël EOL të sistemit operativ që ka kaluar kohë.
Për sisteme të ndryshme operuese gjithmonë është ofruar informacion i ndryshëm, dhe kurrë nuk shqyrtohen gabimet e mundshme gjatë migrimit.
Ndonjëherë duhet të përballemi me konfiguracione që s'duan të funksionojnë pas migrimit.

Kur transferon një server, gjithmonë mund të rregullosh diçka në lëvizje, por kur transferon një klaster të tërë?

Në këtë artikull do të përpiqem të tregoj se si të migrash saktë një kontejner OpenVZ në KVM me minimumin e shkëputjes dhe zgjidhje të shpejta për problemet.

Një ligjëratë e vogël: çfarë është OpenVZ dhe çfarë është KVM?

Nuk do të thellohemi në terminologji, por do të themi në terma të përgjithshëm:

OpenVZ — virtualizim në nivelin e sistemit operativ, mund të implementohet edhe në një mikrovalë, sepse nuk ka nevojë për instruksione CPU dhe teknologji virtualizimi në mesin pritës.

KVM — virtualizim i plotë, që shfrytëzon tërë fuqinë e CPU-së dhe është në gjendje të virtualizojë çfarëdo, në çfarëdo mënyre, duke i ndarë në gjatësi dhe gjerësi.

Përkundrejt besimit të zakonshëm se në mjedisin ofruesve të hostimit OpenVZ ka tepricë, ndërsa KVM jo — fatmirësisht për të fundit, KVM sot ka tepricë po aq sa edhe homologu i tij.

Çfarë do të transferojmë?

Për të provuar për transferim, u desh të përdorim gjithë pyllin e sistemeve operative që janë të disponueshme në OpenVZ: CentOS (versionet 6 dhe 7), Ubuntu (14, 16 dhe 18 LTS), Debian 7.

Mendohej se në pjesën më të madhe të kontejnerëve OpenVZ tashmë kishte ndonjë LAMP, dhe disa madje kishin ndonjë soft të shumë specifikuar. Në shumicën e rasteve, këto ishin konfiguracione me panelin e menaxhimit ISPmanager, VestaCP (dhe shpesh, jo të azhurnuar për vite). Duhet të merren parasysh edhe kërkesat e tyre për transferim.

Migrimi kryhet me ruajtjen e IP të përkushtuar kontejnerit të transferuar, le të supozojmë se IP-ja, e cila ishte e kontejnerit, ruhen në VM dhe do të funksionojë pa probleme.

Para transferimit, sigurohemi që kemi gjithçka në duar:

Server OpenVZ, akses të plotë në rrënjë në mesin pritës, mundësia për të ndaluar/montuar/nisur/eleminuar kontejnerët.
Server KVM, akses të plotë në rrënjë në mesin pritës, me të gjitha pasojat. Supozohet që gjithçka është tashmë e konfiguruar dhe e gatshme për punë.

Fillojmë transferimin

Para se të fillojmë transferimin, le të përcaktojmë terminologjinë që do të ndihmojë për të mos u ngatërruar:

KVM_NODE — makina host KVM
VZ_NODE — makina host OpenVZ
CTID — kontejner OpenVZ
VM — server virtual KVM

Përgatitja për transferim dhe krijimi i makinave virtuale.

Hapi 1

Duke qenë se na nevojitet një vend për të transferuar kontejnerin, do të krijojmë VM me një konfigurim të ngjashëm në KVM_NODE.
E rëndësishme! Duhet të krijojmë VM pikërisht me atë sistem operativ që aktualisht funksionon në CTID. Për shembull, nëse në CTID është instaluar Ubuntu 14, atëherë edhe në VM duhet të instalohet Ubuntu 14. Versionet minor nuk kanë rëndësi dhe mos përputhja e tyre nuk është aq kritike, por versionet kryesore duhet të jenë të njëjta.

Pas krijimit të VM, do të kryejmë përditësimin e pakove në CTID dhe në VM (mos e ngatërroni me përditësimin e OS - nuk e përditësojmë atë, përditësojmë vetëm paketat dhe, nëse ka, versionin e OS brenda versionit kryesor).

Për CentOS, ky proces duket i padëmshëm:

# yum clean all
# yum update -y

Dhe po aq i padëmshëm për Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Hapi 2

Instalojmë në CTID, VZ_NODE dhe VM utility rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Nuk instalojmë asgjë tjetër as aty, as këtu.

Hapi 3

Kryejmë ndalimin CTID në VZ_NODE me komandën

vzctl stop CTID

Montojmë imazhin CTID:

vzctl mount CTID

Shkulohemi në dosjen /vz/root/CTID dhe ekzekutojmë

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

Nën chroot krijojmë skedarin /root/exclude.txt — ai do të përmbajë një listë përjashtimesh që nuk do të kalojnë në serverin e ri

/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

Konektimi me KVM_NODE dhe fillojmë tonin tonë VM, në mënyrë që të funksiononte dhe të ishte e qasshme në rrjet.

Tani gjithçka është gati për transferim. Le të shkojmë!

Hapi 4

Ende nën chroot, ekzekutojmë

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

Komanda rsync do të kryejë transferimin, shpresojmë se çelësat janë të kuptueshëm — transferimi bëhet me ruajtjen e lidhjeve simbolike, të drejtave të aksesit, pronarëve dhe grupeve dhe është çaktivizuar enkriptimi për shpejtësi më të madhe (ishte e mundur të përdoret ndonjë cifrues më të shpejtë, por kjo nuk është kaq e rëndësishme në kuadër të këtij detyre), gjithashtu është çaktivizuar dhe kompresimi.

Pas përfundimit të ekzekutimit të rsync, dalim nga chroot (duke shtypur ctrl+d) dhe kryejmë

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

Hapi 5

Kryejmë disa veprime që do të ndihmojnë në fillimin e VM pas transferimit nga OpenVZ.
Në serverët me Systemd kryejmë komandën që do të ndihmojë të lidhemi në konsolën normale, le të themi, përmes ekranit VNC të serverit

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

Në serverët CentOS 6 dhe CentOS 7 sigurisht do të installojmë bërthamën e re:

yum install kernel-$(uname -r)

Serveri mund të ngarkohet nga ai, por pas transferimit mund të ndalojë së funksionuari ose do të hiqet.

Në server CentOS 7 duhet të zbatohet një rregullim i vogël për PolkitD, përndryshe serveri do të bjerë në boot-in e përjetshëm:

getent group polkitd >/dev/null && echo -e "e[1;32mgrupi polkitd tashmë ekziston e[0m" || { groupadd -r polkitd && echo -e "e[1;33mGrupi i munguar polkitd u shtua e[0m" || echo -e "e[1;31mShtimi i grupit polkitd DËSHTOI e[0m"; }

getent passwd polkitd >/dev/null 
&& echo -e "e[1;32mpërdoruesi polkitd tashmë ekziston e[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "Përdorues për polkitd" polkitd && echo -e "e[1;33mPërdoruesi i munguar polkitd u shtua e[0m" || echo -e "e[1;31mShtimi i përdoruesit polkitd DËSHTOI e[0m"; }

rpm -Va polkit* && echo -e "e[1;32mVerifikimi i rpm polkit* kaloi e[0m" || { echo -e "e[1;33mRivendosja e pronësisë dhe lejeve të përdoruesit/grupit polkit* e[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

Në të gjitha serverët, nëse është instaluar mod_fcgid për Apache, do të kryejmë një rregullim të vogël me të drejtat, përndryshe faqet që përdorin mod_fcgid do të përballen me gabim 500:

chmod +s `which suexec` && apachectl restart

Dhe në fund, kjo do të ndihmojë për shpërndarjet Ubuntu dhe Debian. Ky OS mund të bjerë në një boot të përjetshëm me gabimin

looping too fast. throttling execution a little

e pakëndshme, por lehtë mund të rregullohet, varësisht nga versioni i OS.

Në Debian 9 rregullimi duket kështu:

kryejmë

dbus-uuidgen

nëse marrim një gabim

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

kontrollojmë praninë e 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 <-- ky është i nevojshëm
libdbus-1.so.3.14.16

nëse gjithçka është në rregull, kryejmë

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

Nëse nuk ndihmon — provojmë variantin e dytë.

Variant i dytë për zgjidhjen e problemit me throttling execution a little përputhet praktikisht për të gjitha shpërndarjet Ubuntu dhe Debian.

Kryejmë

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

Dhe për Ubuntu 14, Debian 7 për më tepër kryejmë:

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

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

Çfarë bëmë? Rindërtuam messagebus-in që mungonte për nisjen e Debian/Ubuntu dhe fshimë modules_dep që ishte nga OpenVZ dhe kishte bllokuar ngarkimin e shumë modullëve të bërthamës.

Hapi 6

Rinënisim VM-në, kontrollojmë në VNC si po shkon ngarkimi dhe idealisht — gjithçka do të ngarkohet pa probleme. Megjithatë, ndoshta do të shfaqen disa probleme specifike pas migrimit — por ato janë jashtë përmbajtjes së këtij artikulli dhe rregullohen sipas shfaqjes.

Shpresoj se kjo informacion do të jetë e dobishme! 🙂

Burimi: habr.com