Kiel transdoni OpenVZ 6-ujon al KVM-servilo sen kapdoloroj

Ĉiu, kiu bezonis translokigi OpenVZ-ujon al servilo kun plena KVM-virtualigo almenaŭ unufoje en sia vivo, renkontis kelkajn problemojn:

• La plej granda parto de la informoj estas simple malmodernaj kaj estis signifa por OS-oj kiuj longe pasis la EOL-ciklon
• Malsamaj informoj ĉiam estas provizitaj por malsamaj operaciumoj, kaj eblaj eraroj dum migrado neniam estas konsiderataj
• Kelkfoje vi devas trakti agordojn, kiuj de tempo al tempo ne volas funkcii post migrado

Kiam vi translokigas 1 servilon, vi ĉiam povas ripari ion sur la flugo, sed kiam vi translokigas tutan areton?

En ĉi tiu artikolo mi provos diri al vi kiel ĝuste migri OpenVZ-ujon al KVM kun minimuma malfunkcio kaj rapida solvo al ĉiuj problemoj.

Malgranda eduka programo: kio estas OpenVZ kaj kio estas KVM?

Ni ne profundiĝos en terminologion, sed diros ĝenerale:

OpenVZ — virtualigo je la mastruma sistemo, vi eĉ povas disfaldi ĝin sur mikroondon, ĉar ne necesas CPU-instrukcioj kaj virtualigaj teknologioj sur la gastiga maŝino.

KVM - Plena virtualigo, uzante la tutan potencon de la CPU kaj kapabla virtualigi ion ajn, kiel ajn, tranĉante ĝin laŭlonge kaj kruce.

Kontraŭe al populara kredo, ke inter gastigantaj provizantoj OpenVZ estos supervendita, sed KVM ne - feliĉe por ĉi-lasta, KVM nun estas supervendita ne pli malbona ol sia frato.

Kion ni transportos?

Kiel testobjektojn por la translokigo, ni devis uzi la tutan arbaron de operaciumoj kiuj estas disponeblaj en OpenVZ: CentOS (6 kaj 7 versioj), Ubuntu (14, 16 kaj 18 LTS), Debian 7.

Oni supozis, ke la plej multaj el la OpenVZ-ujoj jam funkciis ian LAMP, kaj iuj eĉ havis iun tre specifan programaron. Plej ofte, ĉi tiuj estis agordoj kun la ISPmanager, VestaCP-kontrolpanelo (kaj plej ofte, ne ĝisdatigitaj dum jaroj). Iliaj translokaj petoj ankaŭ devas esti konsiderataj.

Migrado okazas konservante la IP-adreson de la transdonita ujo; ni supozos, ke la IP, kiun havis la ujo, estas konservita en la VM kaj funkcios senprobleme.

Antaŭ ol translokiĝi, ni certigu, ke ni havas ĉion mane:

• OpenVZ-servilo, plena radika aliro al la gastiga maŝino, kapablo halti/munti/komenci/forigi ujojn
• KVM-servilo, plena radika aliro al la gastiga maŝino, kun ĉio, kion ĝi implicas. Oni supozas, ke ĉio jam estas agordita kaj preta por iri.

Ni komencu translokigi

Antaŭ ol ni komencas la translokigon, ni difinu terminojn, kiuj helpos vin eviti konfuzon:

KVM_NODE - KVM gastiganta maŝino
VZ_NODE - OpenVZ gastiga maŝino
CTID - OpenVZ-ujo
VM - KVM virtuala servilo

Preparado por migrado kaj kreado de virtualaj maŝinoj.

paŝi 1

Ĉar ni devas movi la ujon ien, ni kreos VM kun simila agordo al KVM_NODE.
Grava! Vi devas krei VM sur la operaciumo, kiu nuntempe funkcias per CTID. Ekzemple, se Ubuntu 14 estas instalita sur la CTID, tiam Ubuntu 14 devas esti instalita sur la VM. Malgrandaj versioj ne estas gravaj kaj ilia diferenco ne estas tiom kritika, sed ĉefaj versioj devus esti la samaj.

Post kreado de la VM, ni ĝisdatigos la pakaĵojn sur la CTID kaj sur la VM (ne konfuzu kun ĝisdatigo de la OS - ni ne ĝisdatigas ĝin, ni ĝisdatigas nur la pakaĵojn kaj, se ĝi alvenas, la OS-version ene de la ĉefa versio).

Por CentOS ĉi tiu procezo aspektas sendanĝera:

# yum clean all
# yum update -y

Kaj ne malpli sendanĝera por Ubuntu kaj Debian:

# apt-get update
# apt-get upgrade

paŝi 2

Instali sur CTID, VZ_NODE и VM utileco rsync:

Centos:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Ni ne instalas ion alian nek tie nek tie.

paŝi 3

Ni faras halton CTID sur VZ_NODE teamo

vzctl stop CTID

Muntante la bildon CTID:

vzctl mount CTID

Iru al la dosierujo /vz/root/CTID kaj ekzekuti

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

Sub la radiko, kreu dosieron /root/exclude.txt - ĝi enhavos liston de esceptoj, kiuj ne atingos la novan servilon.

/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

Konekti al KVM_NODE kaj lanĉi nian VMpor ke ĝi funkciu kaj estu alirebla tra la reto.

Nun ĉio estas preta por translokigo. Iru!

paŝi 4

Ankoraŭ sub la sorĉo, ni rezultas

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

La rsync-komando faros la translokigon, ni esperas, ke la ŝlosiloj estas klaraj - la translokigo estas farita kun la konservado de simbolaj ligiloj, alirrajtoj, posedantoj kaj grupoj, kaj ĉifrado estas malŝaltita por pli granda rapideco (vi povus uzi pli rapidan ĉifron, sed ĉi tio ne estas tiel grava por ĉi tiu tasko) , kaj kunpremado estas malŝaltita.

Post kompletigado de rsync, eliru el chroot (premante ctrl+d) kaj ekzekutu

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

paŝi 5

Ni faru plurajn paŝojn, kiuj helpos nin lanĉi la VM post translokado de OpenVZ.
Sur serviloj kun Sistema ni faru komandon, kiu helpos nin ensaluti al regula konzolo, ekzemple per ekrano de VNC-servilo.

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

Sur serviloj CentOS 6 и CentOS 7 Nepre instalu freŝan kernon:

yum install kernel-$(uname -r)

La servilo povas esti ŝargita de ĝi, sed post la translokigo ĝi povas ĉesi funkcii aŭ esti forigita.

Sur servilo CentOS 7 vi devas apliki malgrandan solvon por PolkitD, alie la servilo kraŝos por ĉiam:

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

En ĉiuj serviloj, se mod_fcgid por Apache estis instalita, ni faros malgrandan riparon kun rajtoj, alie retejoj uzantaj mod_fcgid kraŝos kun eraro 500:

chmod +s `which suexec` && apachectl restart

Kaj la lasta afero estas utila por Ubuntu kaj Debian-distribuoj. Ĉi tiu OS povas frakasi en eterna lanĉo kun eraro

buklo tro rapide. stroligante la ekzekuton

malagrabla, sed facile riparebla, depende de la OS-versio.

En Debian 9 la riparo aspektas jene:

ni efektivigas

dbus-uuidgen

se ni ricevas eraron

/usr/local/lib/libdbus-1.so.3: versio `LIBDBUS_PRIVATE_1.10.8′ ne trovita

kontrolu la ĉeeston de 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

se ĉio estas en ordo, ni faras ĝin

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

Se ĝi ne helpas, provu la duan opcion.

La dua solvo al la problemo kun stroligante la ekzekuton Taŭga por preskaŭ ĉiuj Ubuntu kaj Debian-distribuoj.

Ni efektivigas

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

Kaj por Ubuntu 14, Debian 7 Aldone ni plenumas:

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

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

Kion ni faris? Ni restarigis messagebus, kiu mankis por ruli Debian/Ubuntu, kaj forigis modules_dep, kiu venis de OpenVZ kaj malhelpis la ŝarĝon de multaj kernaj moduloj.

paŝi 6

Ni rekomencas la VM, kontrolas en VNC kiel la ŝarĝo progresas kaj, ideale, ĉio ŝarĝos sen problemoj. Kvankam eblas, ke iuj specifaj problemoj aperos post la migrado, ili estas preter la amplekso de ĉi tiu artikolo kaj estos korektitaj kiam ili aperos.

Mi esperas, ke ĉi tiu informo estas utila! 🙂

fonto: www.habr.com