Si të transferoni kontejnerin OpenVZ 6 në serverin KVM pa dhimbje koke

Kushdo që ka pasur nevojë të transferojë një kontejner OpenVZ në një server me virtualizim të plotë KVM të paktën një herë në jetën e tij, ka hasur në disa probleme:

• Shumica e informacionit është thjesht e vjetëruar dhe ishte e rëndësishme për OS që kishin kaluar prej kohësh ciklin EOL
• Informacione të ndryshme jepen gjithmonë për sisteme të ndryshme operative dhe gabimet e mundshme gjatë migrimit nuk merren parasysh kurrë
• Ndonjëherë ju duhet të merreni me konfigurime që herë pas here nuk duan të funksionojnë pas migrimit

Kur transferoni 1 server, gjithmonë mund të rregulloni diçka menjëherë, por kur transferoni një grup të tërë?

Në këtë artikull do të përpiqem t'ju tregoj se si të migroni saktë një enë OpenVZ në KVM me kohë minimale joproduktive dhe një zgjidhje të shpejtë për të gjitha problemet.

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

Ne nuk do të hyjmë thellë në terminologji, por do të themi në terma të përgjithshëm:

OpenVZ — virtualizimi në nivelin e sistemit operativ, mund ta vendosni edhe në një mikrovalë, pasi nuk ka nevojë për udhëzime CPU dhe teknologji virtualizimi në makinën pritës.

KVM - virtualizim i plotë, duke përdorur të gjithë fuqinë e CPU-së dhe i aftë për të virtualizuar çdo gjë, në çdo mënyrë, duke e prerë atë për së gjati dhe në tërthore.

Ndryshe nga besimi popullor, në mjedis ofruesit e hostimit OpenVZ është i mbivlerësuar, por KVM jo. Për fat të mirë për këtë të fundit, KVM tani është i mbivlerësuar po aq mirë sa vëllai i tij.

Çfarë do të bartim?

В качестве подопытных для переноса пришлось использовать весь лес операционных систем, которые доступны на OpenVZ: CentOS (6 и 7 версии), Ubuntu (14, 16 и 18 LTS), Debian 7.

Supozohej se shumica e kontejnerëve OpenVZ kishin tashmë një lloj LAMP, dhe disa madje kishin disa softuer shumë specifik. Më shpesh, këto ishin konfigurime me ISPmanager, panelin e kontrollit VestaCP (dhe më shpesh, jo të përditësuar për vite me radhë). Duhet të merren parasysh edhe kërkesat e tyre për transferim.

Migrimi kryhet me ruajtje adresat IP Për një kontejner portativ, do të supozojmë se adresa IP e kontejnerit ruhet në VM dhe do të funksionojë pa probleme.

Përpara transferimit, le të sigurohemi që të kemi gjithçka në dorë:

• Serveri OpenVZ, akses i plotë rrënjësor në makinën pritës, aftësia për të ndaluar/montuar/filluar/fshirë kontejnerët
• Serveri KVM, akses i plotë rrënjë në makinën pritës, me gjithçka që nënkupton. Supozohet se gjithçka tashmë është konfiguruar dhe gati për të shkuar.

Le të fillojmë transferimin

Përpara se të fillojmë transferimin, le të përcaktojmë termat që do t'ju ndihmojnë të shmangni konfuzionin:

KVM_NODE - Makina pritës KVM
VZ_NODE - Makina pritës OpenVZ
CTID - Enë OpenVZ
VM - Server virtual KVM

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

Hapi 1

Meqenëse duhet ta zhvendosim kontejnerin diku, ne do të krijojmë VM me një konfigurim të ngjashëm me KVM_NODE.
Rëndësishme! Создавать VM нужно именно на той операционной системе, которая сейчас крутится на CTID. Например, если на CTID установлена Ubuntu 14, то и на VM нужно ставить Ubuntu 14. Минорные версии не важны и их несовпадение не столь критично, а вот мажорные — должны быть одинаковыми.

Pas krijimit të VM-së, ne do të përditësojmë paketat në CTID dhe në VM (të mos ngatërrohet me përditësimin e sistemit operativ - ne nuk e përditësojmë atë, ne përditësojmë vetëm paketat dhe, nëse arrin, versionin e OS brenda sistemit kryesor version).

Për CentOS этот процесс выглядит безобидно:

# yum clean all
# yum update -y

И не менее безобидно для Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Hapi 2

Instaloni në CTID, VZ_NODE и VM dobishmërisë rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Nuk po instalojmë asgjë tjetër as atje e as atje.

Hapi 3

Ne bëjmë një ndalesë CTID mbi VZ_NODE ekipi

vzctl stop CTID

Montimi i imazhit CTID:

vzctl mount CTID

Shkoni te dosja /vz/root/CTID dhe ekzekutoni

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

Nën rrënjë, krijoni një skedar /root/exclude.txt - ai do të përmbajë një listë përjashtimesh që nuk do të shkojnë 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

Duke u lidhur me KVM_NODE dhe të nisë tonë VMnë mënyrë që të funksionojë dhe të jetë i aksesueshëm përmes rrjetit.

Tani gjithçka është gati për transferim. Shkoni!

Hapi 4

Ende nën magji, ne performojmë

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ë që çelësat të jenë të qartë - transferimi kryhet me ruajtjen e lidhjeve simbolike, të drejtave të aksesit, pronarëve dhe grupeve, dhe enkriptimi është i çaktivizuar për shpejtësi më të madhe (mund të përdorni ndonjë shifër më të shpejtë, por kjo nuk është aq e rëndësishme për këtë detyrë), si dhe kompresimi është i çaktivizuar.

Pasi të keni përfunduar rsync, dilni nga chroot (duke shtypur ctrl+d) dhe ekzekutoni

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

Hapi 5

Le të kryejmë disa hapa që do të na ndihmojnë të hapim VM-në pas transferimit nga OpenVZ.
Në serverët me Systemd le të ekzekutojmë një komandë që do të na ndihmojë të hyjmë në një tastierë të rregullt, për shembull, përmes një ekrani të serverit VNC

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

Në serverë CentOS 6 и CentOS 7 Sigurohuni që të instaloni një kernel të ri:

yum install kernel-$(uname -r)

Serveri mund të ngarkohet prej tij, por pas transferimit mund të ndalojë së punuari ose të fshihet.

Në server CentOS 7 ju duhet të aplikoni një rregullim të vogël për PolkitD, përndryshe serveri do të rrëzohet përgjithmonë:

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

Në të gjithë serverët, nëse mod_fcgid për Apache është instaluar, ne do të kryejmë një rregullim të vogël me të drejta, përndryshe faqet që përdorin mod_fcgid do të rrëzohen me gabimin 500:

chmod +s `which suexec` && apachectl restart

И последнее, пригодится для Ubuntu, Debian дистрибутивов. Эта ОС может упасть в вечный бут с ошибкой

duke u rrotulluar shumë shpejt. mbyt ekzekutimin pak

e pakëndshme, por lehtësisht e rregullueshme, në varësi të versionit të OS.

Mbi Debian 9 rregullimi duket si ky:

ne kryejmë

dbus-uuidgen

nëse marrim një gabim

/usr/local/lib/libdbus-1.so.3: versioni `LIBDBUS_PRIVATE_1.10.8′ nuk u gjet

kontrolloni 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 <-- нужен этот
libdbus-1.so.3.14.16

nëse gjithçka është në rregull, ne e bëjmë atë

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 ju ndihmon, provoni opsionin e dytë.

Zgjidhja e dytë e problemit me mbyt ekzekutimin pak подходит практически для всех Ubuntu и Debian дистрибутивов.

Ne kryejmë

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

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

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

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

Что мы сделали? Восстановили messagebus, которого не хватало для запуска Debian/Ubuntu и удалили modules_dep, который пришел от OpenVZ и мешал загрузки многих модулей ядра.

Hapi 6

Ne rinisim VM-në, kontrollojmë në VNC se si po përparon ngarkimi dhe, në mënyrë ideale, gjithçka do të ngarkohet pa probleme. Edhe pse është e mundur që disa probleme specifike të shfaqen pas migrimit, ato janë përtej qëllimit të këtij neni dhe do të korrigjohen kur të lindin.

Shpresoj që ky informacion të jetë i dobishëm! 🙂

Burimi: www.habr.com