Paano ilipat ang lalagyan ng OpenVZ 6 sa KVM server nang walang pananakit ng ulo

Ang sinumang kailangang maglipat ng container ng OpenVZ sa isang server na may ganap na KVM virtualization kahit isang beses sa kanilang buhay ay nakatagpo ng ilang problema:

• Karamihan sa impormasyon ay hindi na napapanahon at may kaugnayan para sa mga OS na matagal nang pumasa sa EOL cycle
• Ang iba't ibang impormasyon ay palaging ibinibigay para sa iba't ibang mga operating system, at ang mga posibleng error sa panahon ng paglipat ay hindi kailanman isinasaalang-alang
• Minsan kailangan mong harapin ang mga pagsasaayos na sa bawat ngayon at pagkatapos ay hindi nais na gumana pagkatapos ng paglipat

Kapag naglipat ka ng 1 server, palagi kang makakaayos ng isang bagay sa mabilisang paraan, ngunit kapag naglipat ka ng isang buong cluster?

Sa artikulong ito susubukan kong sabihin sa iyo kung paano i-migrate nang tama ang isang container ng OpenVZ sa KVM na may kaunting downtime at isang mabilis na solusyon sa lahat ng problema.

Isang maliit na programang pang-edukasyon: ano ang OpenVZ at ano ang KVM?

Hindi tayo lalalim sa terminolohiya, ngunit sasabihin sa pangkalahatang mga termino:

OpenVZ — virtualization sa antas ng operating system, maaari mo ring i-deploy ito sa isang microwave, dahil hindi na kailangan ang mga tagubilin ng CPU at mga teknolohiya ng virtualization sa host machine.

KVM - ganap na virtualization, gamit ang lahat ng kapangyarihan ng CPU at may kakayahang mag-virtualize ng anuman, sa anumang paraan, pagputol ito nang pahaba at crosswise.

Taliwas sa tanyag na paniniwala na sa mga nagho-host na provider ang OpenVZ ay magiging oversold, ngunit ang KVM ay hindi - sa kabutihang palad para sa huli, ang KVM ay oversold na ngayon nang hindi mas malala kaysa sa kapatid nito.

Ano ang dadalhin natin?

Bilang mga paksa ng pagsubok para sa paglipat, kinailangan naming gamitin ang buong kagubatan ng mga operating system na magagamit sa OpenVZ: CentOS (6 at 7 na bersyon), Ubuntu (14, 16 at 18 LTS), Debian 7.

Ipinapalagay na karamihan sa mga lalagyan ng OpenVZ ay nagpapatakbo na ng ilang uri ng LAMP, at ang ilan ay mayroon nang ilang partikular na software. Kadalasan, ito ay mga pagsasaayos sa ISPmanager, VestaCP control panel (at kadalasan, hindi na-update nang maraming taon). Dapat ding isaalang-alang ang kanilang mga kahilingan sa paglipat.

Isinasagawa ang paglipat habang pinapanatili ang IP address ng inilipat na lalagyan; ipagpalagay namin na ang IP na mayroon ang lalagyan ay naka-save sa VM at gagana nang walang problema.

Bago maglipat, tiyakin natin na nasa kamay natin ang lahat:

• OpenVZ server, ganap na root access sa host machine, kakayahang huminto/mag-mount/magsimula/magtanggal ng mga lalagyan
• KVM server, buong root access sa host machine, kasama ang lahat ng ipinahihiwatig nito. Ipinapalagay na ang lahat ay naka-configure na at handa nang umalis.

Simulan na natin ang paglipat

Bago natin simulan ang paglipat, tukuyin natin ang mga terminong makakatulong sa iyong maiwasan ang pagkalito:

KVM_NODE - KVM host machine
VZ_NODE - OpenVZ host machine
CTID - Lalagyan ng OpenVZ
VM - KVM virtual server

Paghahanda para sa paglipat at paglikha ng mga virtual machine.

Hakbang 1

Dahil kailangan naming ilipat ang container sa isang lugar, gagawa kami VM na may katulad na pagsasaayos sa KVM_NODE.
Mahalaga! Kailangan mong gumawa ng VM sa operating system na kasalukuyang tumatakbo sa CTID. Halimbawa, kung naka-install ang Ubuntu 14 sa CTID, dapat na naka-install ang Ubuntu 14 sa VM. Hindi mahalaga ang mga menor de edad na bersyon at hindi masyadong kritikal ang pagkakaiba ng mga ito, ngunit dapat pareho ang mga pangunahing bersyon.

Matapos gawin ang VM, ia-update namin ang mga pakete sa CTID at sa VM (huwag malito sa pag-update ng OS - hindi namin ito ina-update, ina-update lang namin ang mga pakete at, kung dumating ito, ang bersyon ng OS sa loob ng pangunahing bersyon).

Para sa CentOS ang prosesong ito ay mukhang hindi nakakapinsala:

# yum clean all
# yum update -y

At hindi gaanong hindi nakakapinsala para sa Ubuntu at Debian:

# apt-get update
# apt-get upgrade

Hakbang 2

I-install sa CTID, VZ_NODE и VM utility rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Hindi kami nag-i-install ng kahit ano pa doon o doon.

Hakbang 3

Huminto kami CTID sa VZ_NODE koponan

vzctl stop CTID

Pag-mount ng imahe CTID:

vzctl mount CTID

Pumunta sa /vz/root/ folderCTID at isagawa

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

Sa ilalim ng ugat, lumikha ng file /root/exclude.txt - maglalaman ito ng listahan ng mga exception na hindi makakarating sa bagong server

/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

Kumonekta sa KVM_NODE at ilunsad ang aming VMupang ito ay gumana at naa-access sa network.

Ngayon ang lahat ay handa na para sa paglipat. Go!

Hakbang 4

Still under the spell, nagpe-perform kami

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

Ang utos ng rsync ay gagawa ng paglipat, inaasahan namin na ang mga susi ay malinaw - ang paglilipat ay isinasagawa kasama ang pangangalaga ng mga symlink, mga karapatan sa pag-access, mga may-ari at grupo, at ang pag-encrypt ay hindi pinagana para sa mas mabilis (maaari kang gumamit ng mas mabilis na cipher, ngunit ito ay hindi napakahalaga para sa gawaing ito), pati na rin ang compression ay hindi pinagana.

Pagkatapos makumpleto ang rsync, lumabas sa chroot (sa pamamagitan ng pagpindot sa ctrl+d) at i-execute

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

Hakbang 5

Magsagawa tayo ng ilang hakbang na makakatulong sa ating ilunsad ang VM pagkatapos lumipat mula sa OpenVZ.
Sa mga server na may Systemd magsagawa tayo ng utos na tutulong sa atin na mag-log in sa isang regular na console, halimbawa, sa pamamagitan ng screen ng VNC server

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

Sa mga server CentOS 6 и CentOS 7 Tiyaking mag-install ng sariwang kernel:

yum install kernel-$(uname -r)

Maaaring i-load ang server mula dito, ngunit pagkatapos ng paglipat ay maaaring huminto ito sa paggana o matanggal.

Sa server CentOS 7 kailangan mong mag-aplay ng isang maliit na pag-aayos para sa PolkitD, kung hindi, ang server ay mag-crash magpakailanman:

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

Sa lahat ng mga server, kung ang mod_fcgid para sa Apache ay na-install, magsasagawa kami ng isang maliit na pag-aayos na may mga karapatan, kung hindi, ang mga site na gumagamit ng mod_fcgid ay mag-crash na may error 500:

chmod +s `which suexec` && apachectl restart

At ang huling bagay ay kapaki-pakinabang para sa mga pamamahagi ng Ubuntu at Debian. Ang OS na ito ay maaaring bumagsak sa isang walang hanggang boot na may error

masyadong mabilis ang pag-loop. throttling execution ng kaunti

hindi kasiya-siya, ngunit madaling maayos, depende sa bersyon ng OS.

Sa Debian 9 ang pag-aayos ay ganito:

ating isinasagawa

dbus-uuidgen

kung magkamali tayo

/usr/local/lib/libdbus-1.so.3: bersyon `LIBDBUS_PRIVATE_1.10.8′ hindi nahanap

suriin ang pagkakaroon ng 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

kung maayos ang lahat, ginagawa namin ito

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

Kung hindi ito makakatulong, subukan ang pangalawang opsyon.

Ang pangalawang solusyon sa problema sa throttling execution ng kaunti Angkop para sa halos lahat ng mga distribusyon ng Ubuntu at Debian.

Isinasagawa namin

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

At para sa Ubuntu 14, Debian 7 Bilang karagdagan, ginagawa namin ang:

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

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

Ano'ng nagawa natin? Ibinalik namin ang messagebus, na nawawala upang patakbuhin ang Debian/Ubuntu, at inalis ang modules_dep, na nagmula sa OpenVZ at nakagambala sa paglo-load ng maraming kernel modules.

Hakbang 6

I-reboot namin ang VM, suriin sa VNC kung paano umuusad ang paglo-load at, sa isip, lahat ay maglo-load nang walang problema. Bagama't posibleng may ilang partikular na problema na lilitaw pagkatapos ng paglipat, ang mga ito ay lampas sa saklaw ng artikulong ito at itatama kapag lumitaw ang mga ito.

Umaasa ako na ang impormasyong ito ay kapaki-pakinabang! 🙂

Pinagmulan: www.habr.com