Kuidas migreerida OpenVZ 6 konteinerit KVM serverisse murede vabalt

Igaüks, kes on kunagi pidanud migreerima OpenVZ konteineri tõeliselt virtuaalsesse KVM serverisse, on silmitsi seisnud mitmete probleemidega:

• Enamik teavet on lihtsalt vananenud ja tundub olevat asjakohane juba ammu möödunud EOL-i tsükli jaoks.
• Erinevate operatsioonisüsteemide kohta on alati erinevat teavet ning migreerimise võimalikke vigu arutatakse kunagi.
• Mõnikord tuleb tegeleda konfigureerimisega, mis migratsiooni pärast ei tööta.

Kui migreerida üks server, on alati võimalik midagi jooksu pealt parandada, aga mis siis, kui migreeritakse terve klaster?

Selles artiklis püüan selgitada, kuidas migreerida OpenVZ konteinerit KVM-ile minimaalsete seisakute ja kiirete probleemilahendustega.

Lühike ülevaade: mis on OpenVZ ja mis on KVM?

Ärme süvene terminoloogiasse, vaid ütleme üldiselt:

OpenVZ — virtualiseerimine operatsioonisüsteemi tasemel, mida saab käivitada isegi mikrolaineahjus, kuna ei ole vaja CPU juhiseid ja virtualiseerimiseks tehnoloogiaid hostmasinas.

KVM — täiuslik virtualiseerimine, mis kasutab kogu CPU võimsust ja suudab virtualiseerida kõike, nagu soovitakse, lõigates nii edasi-tagasi.

Vastupidiselt levinud arvamusele, et hõlvab teenusepakkujate OpenVZ, samas kui KVM ei ole — õnneks viimasel ajal on KVM samuti hakanud ületama oma konkurente.

Mida me hakkame ümber kolima?

Experimentideks ümberkolimiseks kasutasime kogu avatud süsteemide metsa, mis on saada OpenVZ-l: CentOS (6 ja 7 versioon), Ubuntu (14, 16 ja 18 LTS), Debian 7.

Oletati, et suurem osa OpenVZ konteineritest töötavad juba mingisuguse LAMP-i peal, ja mõnedel on isegi väga spetsiifiline tarkvara. Enamasti olid need konfiguratsioonid ISPmanageri, VestaCP juhtpaneeliga (ja tavaliselt mitte aastaid uuendatud). Tuleb arvestada ka nende ümberkolimise nõudmisi.

Migratsioon toimub IP-aadressid ümberkantava konteineri säilitamisega, oletame, et IP, mis oli konteineril, jääb VM-ile ja töötab probleemideta.

Enne kolimist veendume, et meil on kõik käepärast:

• OpenVZ server, täielik root-juurdepääs hostmasinale, võimalus peatada/mountida/käivitada/kustutada konteinerid.
• KVM-server, täielik root-juurdepääs host-masinale, koos kõigi sellest tulenevate funktsioonidega. Eeldatakse, et kõik on juba seadistatud ja valmis kasutamiseks.

Hakkame üleviimisega pihta

Enne üleviimise alustamist määratlegime mõisted, mis aitavad segadusse sattumisel:

KVM_NODE — KVM host-masin
VZ_NODE — OpenVZ host-masin
CTID — OpenVZ konteiner
VM — virtuaalne KVM-server

Valmistume üleviimiseks ja virtuaalmasinate loomiseks.

Samm 1

Kuna meil on vaja konteiner kuhugi üle viia, loome VM sarnase konfiguratsiooniga KVM_NODE.
Oluline! VM peab olema loodud just selle operatsioonisüsteemiga, mis praegu CTID-l töötab. Näiteks, kui CTID-l on installitud Ubuntu 14, siis peab ka VM-le olema paigaldatud Ubuntu 14. Väiksemad versioonid ei ole olulised ja nende mitteühtlustamine ei ole nii kriitiline, kuid peamised versioonid peavad olema samad.

Pärast VM loomist uuendame pakette nii CTID-l kui ka VM-l ( ära ajada segamini operatsioonisüsteemi uuendamisega - seda ei uuendata, uuendame vaid pakette ja, kui tuleb, OS-i versiooni peamise versiooni piires).

CentOS-i puhul näeb see protsess kahjutuna välja:

# yum clean all
# yum update -y

Ja mitte vähem kahjutuna Ubuntu, Debian puhul:

# apt-get update
# apt-get upgrade

Samm 2

Paigaldame CTID, VZ_NODE ja VM utiliidi rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Ei installi seal ega seal midagi muud.

Samm 3

Teostame peatamise CTID järgnevaga VZ_NODE käsku

vzctl stop CTID

Seame pilt CTID:

vzctl mount CTID

Liigume kausta /vz/root/CTID ja teeme

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

Chrootis loome faili /root/exclude.txt — see sisaldab nimekirja eranditest, mis ei jõua uuele serverile

/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

Ühendame KVM_NODE ja käivitame meie VM, et see töötaks ja oleks võrgu kaudu ligipääsetav.

Nüüd on kõik valmis ülekolimiseks. Alustame!

4. samm

Endiselt chrootis, täidame

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

Rsynci käsk viib üle kolimise läbi, loodame, et võtmed on arusaadavad — üle kolimine toimub sümboolsete linkide, õiguste, omanikute ja gruppide säilitamisega ning krüptimine on välja lülitatud suurema kiirus saavutamiseks (kuigi oleks võinud kasutada mõnda kiiremat cipherit, pole see antud ülesande kontekstis nii oluline), samuti on välja lülitatud kompressioon.

Pärast rsynci lõpetamist väljuge chrootist (vajutades ctrl+d) ja täidame

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

Samm 5

Teeme mitu toimingut, mis aitavad meil VM-i käivitada pärast OpenVZ-st üleviimist.
Serverites, kus Systemd Käivitame käsu, mis aitab meil siseneda tavalisesse konsolisse, näiteks serveri VNC-ekraani kaudu.

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

Serverites CentOS 6 ja CentOS 7 kindlasti installime värske tuuma:

yum install kernel-$(uname -r)

Server võib sellelt käivituda, kuid pärast üleviimist võib see lõpetada töötamise või olla kustutatud.

Serveril CentOS 7 on vaja rakendada väike paranduste PolkitD jaoks, vastasel juhul kukub server lõputusse buutimiseks:

getent group polkitd >/dev/null && echo -e "e[1;32mpolkitd rühma juba eksisteerib e[0m" || { groupadd -r polkitd && echo -e "e[1;33mLisatud puuduv polkitd rühm e[0m" || echo -e "e[1;31mPolkitd rühma lisamine EBAÕNNESTUS e[0m"; }

getent passwd polkitd >/dev/null 
&& echo -e "e[1;32mpolkitd kasutaja juba eksisteerib e[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "PolkitD kasutaja" polkitd && echo -e "e[1;33mLisatud puuduv polkitd kasutaja e[0m" || echo -e "e[1;31mPolkitd kasutaja lisamine EBAÕNNESTUS e[0m"; }

rpm -Va polkit* && echo -e "e[1;32mpolkit* rpm verifitseerimine läbitud e[0m" || { echo -e "e[1;33mPolkit* rpm kasutaja/grupi omandi ja õiguste taastamine e[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

Kuna kõikidel серверites, kui mod_fcgid Apache'ile on installitud, teeme väikese paranduse õigustes, vastasel juhul kukuvad mod_fcgid'i kasutavad saidid 500 veaga:

chmod +s `which suexec` && apachectl restart

Ja viimane, tuleb kasuks Ubuntu ja Debian'i distributsioonidele. See operatsioonisüsteem võib sattuda lõputusse buutimise vea tõttu.

liigselt kiiresti. aeglusta käivitamist natuke

ebameeldiv, kuid lihtsalt lahendatav, olenevalt operatsioonisüsteemi versioonist.

VDS-l on võimalik installida: Debian 9 lahendus näeb välja selline:

täidame

dbus-uuidgen

kui saame vea

/usr/local/lib/libdbus-1.so.3: version `LIBDBUS_PRIVATE_1.10.8′ not found

kontrollime LIBDBUS'i olemasolu

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 <-- seda on vaja
libdbus-1.so.3.14.16

kui kõik on korras, täidame

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

Kui ei aita — proovime teist varianti.

Teine lahendus probleemile liigselt kiiresti sobib praktiliselt kõigile Ubuntu ja Debian'i distributsioonidele.

Täidame

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

Ja jaoks Ubuntu 14, Debian 7 täiendavalt täidame:

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

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

Mida me tegime? Taastasin messagebus'i, mida oli puudu Debian'i/Ubuntu käivitamiseks ja eemaldasin modules_dep'i, mis tuli OpenVZ-st ja takistas paljude tuumamoodulite laadimist.

Samm 6

Kaustame VM-i, kontrollime VNC-s, kuidas käivitamine läheb, ja ideaalis – kõik käivitub probleemideta. Kuigi võivad esineda mõned spetsiifilised probleemid pärast migratsiooni – kuid need on väljaspool selle artikli ulatust ja lahendatakse ilmnemisel.

Loodan, et see teave on kasulik! 🙂

Allikas: habr.com