Kuidas edastada OpenVZ 6 konteiner KVM serverisse murevabalt

Iga, kellel on kunagi elus olnud vajadus viia OpenVZ konteiner serverisse, kus on täieõiguslik KVM virtualiseerimine, on silmitsi seisnud mitmete probleemidega:

• Enamik teavet on lihtsalt vananenud ja oli asjakohane juba ammu möödunud EOL tsükli jaoks.
• Erinevate operatsioonisüsteemide kohta on alati erinev teave ja kunagi ei arvestata migratsiooni võimalikke vigu.
• Mõnikord tuleb tegeleda konfiguratsioonidega, mis pärast migratsiooni ei pruugi lihtsalt töötada.

Kui viid ühe serveri, on alati võimalik midagi jooksvalt parandada, aga kui viid terve kluster?

Selles artiklis püüan ma rääkida, kuidas õigesti migreerida OpenVZ konteinerit KVM-ile minimaalse seisaku ja kiire probleemilahendusega.

Väike selgitus: mis on OpenVZ ja mis on KVM?

Ärme lasku terminoloogiasse, vaid ütleme üldiselt:

OpenVZ — virtualiseerimine operatsioonisüsteemi tasemel, mille saab isegi mikrolaineahjus välja arendada, kuna ei ole vajadust CPU juhiste ja virtualiseerimise tehnoloogiate järele hostmasinas.

KVM — täieõiguslik virtualiseerimine, mis kasutab kogu CPU jõudlust ja suudab virtualiseerida kõike, nagu soovib, lõigata mööda ja üle.

Vaatamata levinud arvamusele, et OpenVZ üle müüakse, aga KVM mitte — õnneks viimaste jaoks, KVM müüakse nüüd üle mitte vähem kui selle õe. hostingu pakkujate Mida me viime?

Eksperimentideks viimiseks tuli kasutada kogu OpenVZ-s saadaval olevate operatsioonisüsteemide 'metsa': CentOS (6 ja 7 versioon), Ubuntu (14, 16 ja 18 LTS), Debian 7.

Eeldati, et suuremal osal OpenVZ konteineritest töötab enam-vähem LAMP, ja osa neist on isegi väga spetsiifiline tarkvara. Kõige sagedamini olid need konfiguratsioonid ISPmanager, VestaCP juhtpaneeliga (ja kõige sagedamini, aastaid mitte uuendatud). Tuleb arvestada ka nende nõudmistega migratsiooni osas.

Migratsioon toimub konteineri säilitamisega, eeldame, et konteineri IP säilib VM-is ja töötab probleemideta.

Enne üleviimist veendume, et meil on kõik olemas: IP-aadressid OpenVZ server, täielik root-juurdepääs hostmasinale, võimalus peatada/montida/jaotada/kustutada konteinerid.

KVM server, täielik root-juurdepääs hostmasinale, kõigi sellega kaasnevate õigustega. Eeldatakse, et kõik on juba seadistatud ja töökorras.

• Migratsiooni korral ensureerime, et kõik nõuded on täidetud.
• Selle kohta eeldatakse, et kõik on juba seadistatud ja töötavat.

Alustame üleviimist

Enne üleviimise alustamist määratleme mõisted, et mitte segadusse minna:

KVM_NODE — KVM hostmasin
VZ_NODE — OpenVZ hostmasin
CTID — OpenVZ konteiner
VM — KVM virtuaalserver

Valmistame üleviimiseks ette ja loome virtuaalmasinad.

Samm 1

Kuna me peame konteineri kuhugi üleviima, loome VM samade parameetritega KVM_NODE.
Oluline! Virtuaalmasin tuleb luua just selle operatsioonisüsteemi peale, mis praegu töötab CTID-l. Näiteks kui CTID-l on paigaldatud Ubuntu 14, siis tuleb ka VM-le paigaldada Ubuntu 14. Alaversiooni mitte ühtimine ei ole nii kriitiline, kuid põhiversioonid peavad olema samad.

Pärast VM-i loomist teeme paketihaldust nii CTID-l kui ka VM-is (ärge segage operatsioonisüsteemi uuendamisega - seda me ei uuenda, uuendame ainult pakette ja vajadusel versiooni põhiversioonis).

CentOS-il näeb see protsess ohutult välja:

# yum clean all
# yum update -y

Ja mitte vähem ohutult Ubuntu, Debian jaoks:

# apt-get update
# apt-get upgrade

Samm 2

Paigaldame CTID, VZ_NODE ja VM utiliit rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Roheline valik ei ole vajalik, ei seal, ega seal.

Samm 3

Teostame peatamise CTID . Tundub, et VZ_NODE käsklusega

vzctl stop CTID

Mountimme pildi CTID:

vzctl mount CTID

Liigume kausta /vz/root/CTID ja teeme

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

Chrooti all loome faili /root/exclude.txt — see sisaldab välja jäetavate objektide nimekirja, mis ei satu 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

Ühendume KVM_NODE ja käivitame meie VM, et see töötaks ja oleks võrgus kergesti ligipääsetav.

Nüüd on kõik üleviimiseks valmis. Läheme!

Samm 4

Olles endiselt chrooti all, teeme

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

Rsync käsk viib üleviimise läbi, loodetavasti on võtmed arusaadavad — üleviimine toimub sümboollinkide, õiguste, omanike ja gruppide säilitamisega ning krüpteerimine on välja lülitatud suurema kiirusena (võiks kasutada mõnda kiiremat cipherit, kuid see ei ole antud ülesande raames nii oluline), samas on välja lülitatud ka kompressioon.

Pärast rsynci käsku lõpetamist väljumme chrootist (vajutades ctrl+d) ja teeme

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

Samm 5

Teeme mõned toimingud, mis aitavad meil VM-i käivitamisel pärast OpenVZ üleviimist.
Serverites, kus on Systemd teeme käsu, mis aitab meil tavalisel konsoolil sisse logida, näiteks VNC serveri ekraani kaudu

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

CentOS 6 serverites CentOS 6 ja CentOS 7 me kindlasti installime värske tuuma:

yum install kernel-$(uname -r)

Server võib olla sellest käivitatud, kuid pärast ülekannet võib see lõpetada töötamise või olla eemaldatud.

Serveris CentOS 7 on vajalik rakendada väike fikseering PolkitD-le, vastasel juhul kukub server igavesse boot'i:

getent group polkitd >/dev/null && echo -e "e[1;32mpolkitd rühm 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 "Kasutaja polkitd jaoks" 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 kontroll läbis[e[0m" || { echo -e "e[1;33mResetime polkit* rpm kasutaja/grupi omandamise & õigused[e[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

Kõikides serverites, kui Apache'ile on installeeritud mod_fcgid, teeme väikese fikseeringu õigustega, vastasel juhul kukuvad saidid, mis kasutavad mod_fcgid, 500 veaga:

chmod +s `which suexec` && apachectl restart

Ja viimane, mis on kasulik Ubuntu ja Debian’i distributsioonide jaoks. See opsüsteem võib langeda igavesse boot'i veaga

looping too fast. throttling execution a little

ebameeldiv, kuid kergesti parandatav, sõltuvalt opsüsteemi versioonist.

Pealehe Debian 9 parandus näeb välja selline:

teeme:

dbus-uuidgen

kui saame vea

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

kontrollime LIBDBUS 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 <-- see on vajalik
libdbus-1.so.3.14.16

kui kõik on korras, teeme:

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 variant probleemi lahendamiseks throttling execution a little sobib praktiliselt kõikidele Ubuntu ja Debian’i distributsioonidele.

Täidame

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

Ja Ubuntu 14, Debian 7 lisaks teeme:

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

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

Mida me tegime? Taastasime messagebus'i, mida ei olnud Debian'i/Ubuntu käivitamiseks ning eemaldasime modules_dep'i, mis tuli OpenVZ-st ja takistas paljude tuumamoodulite laadimist.

Samm 6

Taaskäivitame VM-i, kontrollime VNC-is, kuidas laadimine toimub ja ideaalis — kõik laadib ilma probleemideta. Kuigi pärast migratsiooni võivad mõningad spetsiifilised probleemid ilmneda — kuid need ei kuulu selle artikli rikka, need lahendatakse jooksvalt.

Loodan, et see teave on kasulik! 🙂

Allikas: habr.com