ProHoster > Blog > administratë > Si të transferoni kontejnerin OpenVZ 6 në serverin KVM pa dhimbje koke

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 se midis ofruesve të pritjes, OpenVZ do të jetë i mbishitur, por KVM nuk do të jetë - për fat të mirë për këtë të fundit, KVM tani është mbishitur jo më keq se vëllai i tij.

Çfarë do të bartim?

Si subjekte testimi për transferimin, na u desh të përdornim të gjithë pyllin e sistemeve operative që janë në dispozicion në OpenVZ: CentOS (versionet 6 dhe 7), Ubuntu (14, 16 dhe 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 duke ruajtur adresën IP të kontejnerit të transferuar; ne do të supozojmë se IP-ja që kishte kontejneri është ruajtur 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! Ju duhet të krijoni një VM në sistemin operativ që aktualisht po funksionon në CTID. Për shembull, nëse Ubuntu 14 është i instaluar në CTID, atëherë Ubuntu 14 duhet të instalohet në VM. Versionet e vogla nuk janë të rëndësishme dhe mospërputhja e tyre nuk është aq kritike, por versionet kryesore duhet të jenë të njëjta.

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 ky proces duket i padëmshëm:

# yum clean all
# yum update -y

Dhe jo më pak e padëmshme për Ubuntu dhe 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/[email protected] /etc/systemd/system/getty.target.wants/[email protected]

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

Dhe gjëja e fundit është e dobishme për shpërndarjet Ubuntu dhe Debian. Ky OS mund të rrëzohet në një nisje të përjetshme me një gabim

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 I përshtatshëm për pothuajse të gjitha shpërndarjet Ubuntu dhe 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

Çfarë kemi bërë? Ne rivendosëm messagebus, i cili mungonte për të ekzekutuar Debian/Ubuntu, dhe hoqëm modules_dep, që vinin nga OpenVZ dhe ndërhynin në ngarkimin e shumë moduleve të kernelit.

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

Shto një koment