🥇Si të transferoni një konteiner OpenVZ 6 në server KVM pa mundime

Të gjithë ata që kanë pasur ndonjëherë nevojë të transferojnë një konteiner OpenVZ në një server me virtualizim të plote KVM, janë përballur me disa probleme:

Shumica e informacionit është thjesht e tejkaluar dhe ka qenë e rëndësishme për një cikël EOL të sistemit operacional që tashmë ka kaluar.
Informacioni gjithmonë ofrohet ndryshe për sisteme të ndryshme operative dhe asnjëherë nuk shqyrtohen problemet e mundshme gjatë migrimit.
Ndonjëherë duhet të merremi me konfigurime që nuk duan të punojnë pas migrimit.

Kur transferoni një server, gjithmonë mund të rregulloni diçka gjatë procesit, por çfarë ndodh kur transferoni një grup të tërë?

Në këtë artikull do të përpiqem të shpjegoj se si të migroni siç duhet një konteiner OpenVZ në KVM me downtime minimal dhe zgjidhje të shpejta për të gjitha problemet.

Një shpjegim i vogël: çfarë është OpenVZ dhe çfarë është KVM?

Një përmbledhje e përgjithshme:

OpenVZ — virtualizim në nivel të sistemit operativ, mund të vendoset edhe në një mikrovalë, pasi nuk ka nevojë për instrukcione CPU dhe teknologji virtualizimi në makinën pritëse.

KVM — virtualizim i plote, që shfrytëzon tërë fuqinë e CPU-së dhe është në gjendje të virtualizojë çfarëdo, në çfarëdo mënyre, duke e prishur dhe modifikuar si dëshiron.

Përkundër besimeve të përhapura se në mjedisin të ofruesve të hostimit OpenVZ ka mbingarkesë, ndërsa KVM jo — për fat të mirë për të fundit, KVM sot mbingarkohet asnjëherë më pak se shoku i tij.

Çfarë do të transferojmë?

Si subjekte për transferim, u nevojitet të përdoren të gjithë sistemet operative që janë në dispozisyon në OpenVZ: CentOS (versionet 6 dhe 7), Ubuntu (14, 16 dhe 18 LTS), Debian 7.

Parashikohej që në shumicën e konteinerëve OpenVZ tashmë funksionon një LAMP në ndonjë formë, dhe disa prej tyre madje kanë ndonjë soft të shumë specifikuar. Në shumicën e rasteve, këto ishin konfigurime me panel administrimi ISPmanager, VestaCP (dhe më shpesh, të papërditësuara për vite me radhë). Është e nevojshme të merret parasysh edhe kërkesa e tyre për transferim.

Migrimi kryhet me ruajtjen Adresa IP e konteinerit të transferueshëm, le të konsiderojmë se IP-ja që kishte konteineri, ruhet në VM dhe do të funksionojë pa probleme.

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

Server OpenVZ, qasje të plotë rrënjë në makinën pritëse, mundësia për të ndaluar/montuar/nisur/çfarë do që të bëni me konteinerët.
Server KVM, qasje të plotë rrënjë në makinën pritëse, me të gjitha pasojat. Parashikohet që gjithçka është tashmë e konfiguruar dhe gati për punë.

Fillojmë transferimin

Para se të fillojmë transferimin, do të shpjegojmë disa terma që do të ndihmojnë në kuptimin e procesit:

KVM_NODE — makina host KVM
VZ_NODE — makina host OpenVZ
CTID — kontenieri OpenVZ
VM — serveri virtual KVM

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

Hapi 1

Pasi kemi nevojë për një vend për të transferuar kontenierët, do të krijojmë VM me konfigurim të ngjashëm në KVM_NODE.
Ë rëndësishme! Duhet të krijoni VM pikërisht në sistemin operativ që aktualisht është aktiv në CTID. Për shembull, nëse në CTID është instaluar Ubuntu 14, atëherë edhe në VM duhet të vendoset Ubuntu 14. Versionet minor nuk janë aq kritike, por ato mazhore duhet të jenë identike.

Pas krijimit të VM, do të përditësojmë paketat në CTID dhe në VM (mos e ngatërroni me përditësimin e sistemit operativ — nuk e përditësojmë sistemin operativ, vetëm paketat dhe, nëse është e nevojshme, versionin e sistemit operativ brenda versionit kryesor).

Për CentOS, ky proces duket pa shumë probleme:

# yum clean all
# yum update -y

Dhe njësoj pa shumë probleme për Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Hapi 2

Instalojmë në CTID, VZ_NODE dhe VM një utilitar rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

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

Hapi 3

Kryejmë ndalimin CTID në VZ_NODE nëpërmjet komandës.

vzctl stop CTID

Muntimi i imazhit CTID:

vzctl mount CTID

Kalohet 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ë listën e përjashtimeve që nuk do të transmetohen 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

Këtu lidhemi me KVM_NODE dhe fillojmë VM, që të punojë dhe të jetë e aksesueshme në rrjet.

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

Hapi 4

Në vazhdim të 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ë qartë — transferimi bëhet me ruajtjen e lidhjeve simbolike, të drejtave të qasjes, pronarëve dhe grupeve dhe është çaktivizuar enkripti për një shpejtësi më të lartë (mund të ishte përdorur një cifër më e shpejtë, por kjo nuk është aq thelbësore në kuadër të kësaj detyre), ashtu siç është çaktivizuar dhe kompresimi.

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

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

Hapi 5

Do të kryejmë disa veprime që do të na ndihmojnë në fillimin e VM pas transferimit nga OpenVZ.
Në serverat me Systemd do të ekzekutojmë komandën që do të na ndihmojë të lidhemi në konsolën normale, për shembull, përmes VNC të ekranit të serverit

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

Në serverat CentOS 6 dhe CentOS 7 do të instalojmë patjetër një bërthamë të re:

yum install kernel-$(uname -r)

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

Në server CentOS 7 është e nevojshme të zbatohet një fix i vogël për PolkitD, ndryshe serveri do të hyjë në një boot të pafund:

getent group polkitd >/dev/null && echo -e "e[1;32mgrupi polkitd tashmë ekziston e[0m" || { groupadd -r polkitd && echo -e "e[1;33mShtuar grupi i munguar polkitde[0m" || echo -e "e[1;31mShtimi i grupit polkitd DËSHTOIe[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;33mShtuar përdoruesin e munguar polkitde[0m" || echo -e "e[1;31mShtimi i përdoruesit polkitd DËSHTOIe[0m"; } 

rpm -Va polkit* && echo -e "e[1;32mpolkit* verifikimi i rpm kaloi e[0m" || { echo -e "e[1;33mRivendosja e pronësisë dhe lejeve të përdoruesve/grupeve 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ë zbatojmë një fix të vogël me të drejtat, ndryshe faqet që përdorin mod_fcgid do të bien me gabimin 500:

chmod +s `which suexec` && apachectl restart

Dhe e fundit, kjo do të jetë e dobishme për Ubuntu dhe Debian distribucione. Ky OS mund të hyjë në një boot të pafund me gabimin

looping too fast. throttling execution a little

është e pakëndshme, por lehtë zgjidhet, në varësi të versionit të OS.

Në Debian 9 fixi duket kështu:

zbatojmë

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, zbatojmë

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 — provoni variantin e dytë.

Varianti i dytë për zgjidhjen e problemit me throttling execution a little i përshtatet praktikisht të gjitha distribucioneve Ubuntu dhe Debian.

Kryejmë

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

Dhe për Ubuntu 14, Debian 7 shtojmë gjithashtu:

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

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

Çfarë kemi bërë? E rikthyem messagebus, i cili mungonte për fillimin e Debian/Ubuntu dhe fshimë modules_dep, i cili erdhi nga OpenVZ dhe pengonte ngarkimin e shumë moduleve të bërthamës.

Hapi 6

Rikthemi VM, kontrollojmë në VNC si po shkon ngarkimi dhe në mënyrë ideale — gjithçka do të ngarkohet pa probleme. Megjithatë, ndoshta do të shfaqen disa probleme specifike pas migrimit — por ato bien jashtë fushës së këtij artikulli dhe rregullohen sipas shfaqjes.

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

Burimi: habr.com