🥇Kuinka siirtää OpenVZ 6 -säilö KVM-palvelimelle ilman päänsärkyä

Jokainen, joka ainakin kerran elämässään on joutunut siirtämään OpenVZ-konttia palvelimelle, jossa on täydellinen KVM-virtualisointi, on kohdannut joitakin ongelmia:

Suurin osa tiedoista on yksinkertaisesti vanhentunutta ja soveltui käyttöjärjestelmille, jotka olivat jo pitkään ohittaneet EOL-syklin
Eri käyttöjärjestelmille tarjotaan aina eri tiedot, eikä mahdollisia virheitä siirron aikana oteta huomioon
Joskus joudut käsittelemään kokoonpanoja, jotka eivät aina silloin tällöin halua toimia siirron jälkeen

Kun siirrät yhden palvelimen, voit aina korjata jotain lennossa, mutta kun siirrät koko klusterin?

Tässä artikkelissa yritän kertoa sinulle, kuinka OpenVZ-säilö siirretään oikein KVM:ään minimaalisella seisokkiajalla ja nopealla ratkaisulla kaikkiin ongelmiin.

Pieni koulutusohjelma: mikä on OpenVZ ja mikä on KVM?

Emme mene syvälle terminologiaan, vaan sanomme yleisesti:

OpenVZ — virtualisointi käyttöjärjestelmätasolla, voit ottaa sen käyttöön jopa mikroaaltouunissa, koska isäntäkoneessa ei tarvita suorittimen ohjeita ja virtualisointitekniikoita.

KVM - täysi virtualisointi, joka käyttää prosessorin koko tehoa ja pystyy virtualisoimaan mitä tahansa, millä tahansa tavalla, leikkaamalla sen pituus- ja poikkisuunnassa.

Toisin kuin yleisesti uskotaan, ympäristössä hosting-palveluntarjoajat OpenVZ on yliostettu, mutta KVM ei. Onneksi jälkimmäiselle KVM on nyt yliostettu aivan yhtä hyvin kuin sen sisarohjelmisto.

Mitä viedään eteenpäin?

В качестве подопытных для переноса пришлось использовать весь лес операционных систем, которые доступны на OpenVZ: CentOS (6 и 7 версии), Ubuntu (14, 16 и 18 LTS), Debian 7.

Oletuksena oli, että suurimmassa osassa OpenVZ-säilöistä oli jo käynnissä jonkinlainen LAMP, ja joissakin oli jopa hyvin erityisiä ohjelmistoja. Useimmiten nämä olivat konfiguraatioita ISPmanagerin, VestaCP-ohjauspaneelin kanssa (ja useimmiten niitä ei ole päivitetty vuosiin). Myös heidän siirtopyyntönsä on otettava huomioon.

Muutto suoritetaan säilyttäen IP-osoitteet Kannettavan säilön tapauksessa oletamme, että säilön IP-osoite säilyy virtuaalikoneella ja se toimii ongelmitta.

Varmista ennen siirtoa, että meillä on kaikki käsillä:

OpenVZ-palvelin, täysi pääkäyttäjän käyttöoikeus isäntäkoneeseen, mahdollisuus pysäyttää/liittää/käynnistää/poistaa säiliöitä
KVM-palvelin, täysi pääkäyttäjän oikeudet isäntäkoneeseen kaikella mitä se tarkoittaa. Oletetaan, että kaikki on jo määritetty ja valmis käytettäväksi.

Aloitetaan siirto

Ennen kuin aloitamme siirron, määritellään termit, jotka auttavat sinua välttämään sekaannuksia:

KVM_NODE - KVM-isäntäkone
VZ_NODE - OpenVZ-isäntäkone
CTID - OpenVZ-säiliö
VM - KVM-virtuaalipalvelin

Siirtoon valmistautuminen ja virtuaalikoneiden luominen.

Vaihe 1

Koska meidän on siirrettävä kontti jonnekin, luomme VM jolla on samanlainen kokoonpano kuin KVM_NODE.
Tärkeää! Создавать VM нужно именно на той операционной системе, которая сейчас крутится на CTID. Например, если на CTID установлена Ubuntu 14, то и на VM нужно ставить Ubuntu 14. Минорные версии не важны и их несовпадение не столь критично, а вот мажорные — должны быть одинаковыми.

VM:n luomisen jälkeen päivitämme paketit CTID:ssä ja VM:ssä (ei pidä sekoittaa käyttöjärjestelmän päivittämiseen - emme päivitä sitä, päivitämme vain paketit ja jos se saapuu, käyttöjärjestelmäversion päähakemistossa versio).

varten CentOS этот процесс выглядит безобидно:

# yum clean all
# yum update -y

И не менее безобидно для Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Vaihe 2

Asenna päälle CTID, VZ_NODE и VM hyödyllisyys rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Emme asenna mitään muuta sinne emmekä sinne.

Vaihe 3

Teemme pysähdyksen CTID päälle VZ_NODE joukkue

vzctl stop CTID

Kuvan asennus CTID:

vzctl mount CTID

Siirry kansioon /vz/root/CTID ja toteuttaa

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

Luo juuren alle tiedosto /root/exclude.txt - se sisältää luettelon poikkeuksista, jotka eivät pääse uudelle palvelimelle

/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

Yhdistää KVM_NODE ja käynnistää meidän VMjotta se toimii ja on käytettävissä verkon kautta.

Nyt kaikki on valmis siirrettäväksi. Mennä!

Vaihe 4

Edelleen loitsussa esiintyy

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

Rsync-komento suorittaa siirron, toivomme, että avaimet ovat selkeitä - siirto suoritetaan siten, että symbolit, käyttöoikeudet, omistajat ja ryhmät säilytetään, ja salaus on poistettu käytöstä nopeuden lisäämiseksi (voit käyttää nopeampaa salausta, mutta tämä ei ole niin tärkeää tämän tehtävän kannalta), samoin kuin pakkaus on poistettu käytöstä.

Kun olet suorittanut rsyncin, poistu chrootista (painamalla ctrl+d) ja suorita

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

Vaihe 5

Suoritetaan useita vaiheita, jotka auttavat meitä käynnistämään virtuaalikoneen OpenVZ:stä siirron jälkeen.
Palvelimilla, joissa on Systemd Suoritetaanko komento, joka auttaa kirjautumaan sisään tavalliseen konsoliin, esimerkiksi VNC-palvelinnäytön kautta

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

Palvelimilla CentOS 6 и CentOS 7 Muista asentaa uusi ydin:

yum install kernel-$(uname -r)

Palvelin voidaan ladata siitä, mutta siirron jälkeen se voi lakata toimimasta tai hävitä.

Palvelimella CentOS 7 sinun on tehtävä pieni korjaus PolkitD:lle, muuten palvelin kaatuu ikuisesti:

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

Jos mod_fcgid for Apache asennettiin kaikille palvelimille, teemme pienen korjauksen oikeuksilla, muuten mod_fcgid-sivustot kaatuvat virheellä 500:

chmod +s `which suexec` && apachectl restart

И последнее, пригодится для Ubuntu, Debian дистрибутивов. Эта ОС может упасть в вечный бут с ошибкой

kiertää liian nopeasti. hidastaen suoritusta hieman

epämiellyttävä, mutta helppo korjata käyttöjärjestelmän versiosta riippuen.

Päälle Debian 9 korjaus näyttää tältä:

toteutamme

dbus-uuidgen

jos saamme virheen

/usr/local/lib/libdbus-1.so.3: versiota `LIBDBUS_PRIVATE_1.10.8′ ei löydy

tarkista LIBDBUS:n olemassaolo

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

jos kaikki on kunnossa, teemme sen

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

Jos se ei auta, kokeile toista vaihtoehtoa.

Toinen ratkaisu ongelmaan hidastaen suoritusta hieman подходит практически для всех Ubuntu и Debian дистрибутивов.

Me toteutamme

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

Ja sillä Ubuntu 14, Debian 7 Lisäksi suoritamme:

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

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

Что мы сделали? Восстановили messagebus, которого не хватало для запуска Debian/Ubuntu и удалили modules_dep, который пришел от OpenVZ и мешал загрузки многих модулей ядра.

Vaihe 6

Käynnistämme VM:n uudelleen, tarkistamme VNC:ssä kuinka lataus etenee ja ihannetapauksessa kaikki latautuu ilman ongelmia. Vaikka on mahdollista, että joitain erityisiä ongelmia ilmaantuu siirron jälkeen, ne eivät kuulu tämän artikkelin piiriin, ja ne korjataan sitä mukaa, kun niitä ilmenee.

Toivottavasti näistä tiedoista on hyötyä! 🙂

Lähde: will.com