ProHoster > Blogi > Haldamine > Kuidas üle kanda OpenVZ 6 konteiner KVM-serverisse ilma peavaludeta

Kuidas üle kanda OpenVZ 6 konteiner KVM-serverisse ilma peavaludeta

Kõik, kes on vähemalt korra elus pidanud OpenVZ-i konteineri täieliku KVM-virtualiseerimisega serverisse üle kandma, on kokku puutunud mõne probleemiga:

  • Suurem osa teabest on lihtsalt aegunud ja oli asjakohane operatsioonisüsteemide jaoks, mis olid juba ammu EOL-tsükli läbinud
  • Erinevate operatsioonisüsteemide kohta pakutakse alati erinevat teavet ning võimalikke tõrkeid migratsiooni ajal ei arvestata kunagi
  • Mõnikord peate tegelema konfiguratsioonidega, mis aeg-ajalt ei taha pärast migreerimist töötada

Kui teisaldate 1 serveri, saate alati midagi käigupealt parandada, aga kui teisaldate terve klastri?

Selles artiklis püüan teile öelda, kuidas OpenVZ-i konteinerit KVM-i õigesti migreerida minimaalse seisakuajaga ja kõigi probleemide kiire lahendusega.

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

Me ei süvene terminoloogiasse, vaid ütleme üldiselt:

OpenVZ — virtualiseerimine operatsioonisüsteemi tasemel, saate seda isegi mikrolaineahjus juurutada, kuna hostmasinas pole vaja protsessori juhiseid ega virtualiseerimistehnoloogiaid.

KVM - täisväärtuslik virtualiseerimine, kasutades kogu protsessori võimsust ja mis on võimeline virtualiseerima kõike, igal viisil, lõigates seda piki- ja ristisuunas.

Vastupidiselt levinud arvamusele, et hostingu pakkujate seas muutub OpenVZ üle müüdud, aga KVM mitte – viimase õnneks pole KVM nüüd sugugi kehvemini üle müüdud kui tema vend.

Mida me edasi kanname?

Ülekande katsealustena pidime kasutama kogu OpenVZ-s saadaval olevate operatsioonisüsteemide metsa: CentOS (6 ja 7 versioonid), Ubuntu (14, 16 ja 18 LTS), Debian 7.

Eeldati, et enamikus OpenVZ konteinerites töötab juba mingi LAMP ja mõnel oli isegi väga spetsiifiline tarkvara. Enamasti olid need konfiguratsioonid ISPmanageriga, VestaCP juhtpaneeliga (ja enamasti neid ei värskendatud aastaid). Arvestada tuleb ka nende ülekandmistaotlustega.

Migreerimine toimub, säilitades samal ajal ülekantud konteineri IP-aadressi; eeldame, et konteineri IP on VM-is salvestatud ja töötab probleemideta.

Enne teisaldamist veenduge, et meil on kõik käepärast:

  • OpenVZ-server, täielik juurjuurdepääs hostmasinale, võimalus konteinereid peatada/ühendada/käivitada/kustutada
  • KVM-server, täielik juurjuurdepääs hostmasinale koos kõige sellega, mida see eeldab. Eeldatakse, et kõik on juba konfigureeritud ja töövalmis.

Alustame ülekandmist

Enne ülekande alustamist määratleme terminid, mis aitavad teil segadust vältida:

KVM_NODE - KVM-i hostmasin
VZ_SODE - OpenVZ hostmasin
CTID - OpenVZ konteiner
VM - KVM-i virtuaalserver

Migratsiooniks valmistumine ja virtuaalmasinate loomine.

Samm 1

Kuna me peame konteineri kuhugi teisaldama, siis loome VM sarnase konfiguratsiooniga KVM_NODE.
Tähtis! Peate looma VM operatsioonisüsteemis, mis praegu töötab CTID-ga. Näiteks kui CTID-le on installitud Ubuntu 14, siis VM-ile tuleb installida Ubuntu 14. Väiksemad versioonid pole olulised ja nende lahknevus pole nii kriitiline, kuid suuremad versioonid peaksid olema samad.

Pärast VM-i loomist värskendame pakette CTID-s ja VM-is (mitte segi ajada OS-i värskendamisega - me ei värskenda seda, värskendame ainult pakette ja kui see saabub, siis OS-i versiooni põhivõrgus versioon).

CentOS-i jaoks tundub see protsess kahjutu:

# yum clean all
# yum update -y

Ja mitte vähem kahjutu Ubuntu ja Debiani jaoks:

# apt-get update
# apt-get upgrade

Samm 2

Installi sisse CTID, VZ_SODE и VM kasulikkust rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Midagi muud me ei paigalda ei sinna ega sinna.

Samm 3

Teeme peatuse CTID edasi VZ_SODE meeskond

vzctl stop CTID

Pildi paigaldamine CTID:

vzctl mount CTID

Minge kausta /vz/root/CTID ja teostada

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

Loo juure all fail /root/exclude.txt – see sisaldab loendit eranditest, mis uude serverisse ei jõua

/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

Me ühendame KVM_NODE ja käivitage meie VMet see töötaks ja oleks võrgu kaudu juurdepääsetav.

Nüüd on kõik üleandmiseks valmis. Mine!

Samm 4

Endiselt loitsu all esineme

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

Käsk rsync teostab edastuse, loodame, et võtmed on selged - ülekandmine toimub sümlinkide, juurdepääsuõiguste, omanike ja rühmade säilitamisega ning suurema kiiruse huvides on krüpteerimine keelatud (võite kasutada mõnda kiiremat šifrit, kuid see pole selle ülesande jaoks nii oluline), samuti on tihendamine keelatud.

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

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

Samm 5

Teeme mitu sammu, mis aitavad meil pärast OpenVZ-st üleviimist VM-i käivitada.
Serverites koos Systemd käivitame käsu, mis aitab meil sisse logida tavalisse konsooli, näiteks läbi VNC serveri ekraani

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

Serverites 6 CentOS и 7 CentOS Installige kindlasti värske tuum:

yum install kernel-$(uname -r)

Serverit saab sealt laadida, kuid peale ülekandmist võib see lakata töötamast või kustuda.

Serveris 7 CentOS peate PolkitD jaoks väikese paranduse rakendama, vastasel juhul jookseb server igaveseks kokku:

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

Kui mod_fcgid for Apache oli installitud, teeme kõigis serverites õigustega väikese paranduse, vastasel juhul jooksevad mod_fcgid kasutavad saidid kokku veaga 500:

chmod +s `which suexec` && apachectl restart

Ja viimane asi on kasulik Ubuntu ja Debiani distributsioonide jaoks. See OS võib veaga igavesesse alglaadimisse kokku kukkuda

silmus liiga kiiresti. täitmist veidi pidurdades

ebameeldiv, kuid kergesti parandatav, olenevalt OS-i versioonist.

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

teostame

dbus-uuidgen

kui saame vea

/usr/local/lib/libdbus-1.so.3: versiooni `LIBDBUS_PRIVATE_1.10.8′ ei leitud

kontrollige LIBDBUSi 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 <-- нужен этот
libdbus-1.so.3.14.16

kui kõik on korras, siis teeme ära

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 see ei aita, proovige teist võimalust.

Teine lahendus probleemile täitmist veidi pidurdades Sobib peaaegu kõikidele Ubuntu ja Debiani distributsioonidele.

Viime läbi

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

Ja jaoks Ubuntu 14, Debian 7 Lisaks teostame:

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

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

Mida me oleme teinud? Taastasime sõnumibussi, mis Debiani/Ubuntu käitamiseks puudus, ja eemaldasime OpenVZ-st pärit modules_dep, mis segas paljude kerneli moodulite laadimist.

Samm 6

Taaskäivitame VM-i, kontrollime VNC-s, kuidas laadimine edeneb ja ideaalis laaditakse kõik probleemideta. Kuigi on võimalik, et pärast migreerimist ilmnevad mõned konkreetsed probleemid, jäävad need käesoleva artikli reguleerimisalast välja ja neid parandatakse, kui need tekivad.

Loodan, et see teave on kasulik! 🙂

Allikas: www.habr.com

Lisa kommentaar