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.

Vastoin yleistä luuloa, että isännöintipalveluntarjoajien keskuudessa OpenVZ tulee ylimyydyksi, mutta KVM ei - jälkimmäisen onneksi KVM ei ole nyt ylimyyty yhtään huonommin kuin veljensä.

Mitä viedään eteenpäin?

Siirron koehenkilöinä jouduimme käyttämään koko OpenVZ:ssä saatavilla olevien käyttöjärjestelmien metsää: CentOS (6 ja 7 versiot), Ubuntu (14, 16 ja 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.

Siirto suoritetaan säilyttäen siirretyn kontin IP-osoite; oletamme, että kontin IP-osoite on tallennettu VM:lle ja toimii ilman ongelmia.

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ää! Sinun on luotava virtuaalikone käyttöjärjestelmään, joka on tällä hetkellä käynnissä CTID:llä. Esimerkiksi jos CTID:lle on asennettu Ubuntu 14, niin VM:lle on asennettava Ubuntu 14. Pienet versiot eivät ole tärkeitä eikä niiden erot ole niin kriittisiä, mutta pääversioiden tulee olla samat.

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).

CentOS:lle tämä prosessi näyttää vaarattomalta:

# yum clean all
# yum update -y

Ja yhtä vaaratonta Ubuntulle ja Debianille:

# 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/[email protected] /etc/systemd/system/getty.target.wants/[email protected]

Palvelimilla 6 CentOS и 7 CentOS 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 7 CentOS 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

Ja viimeinen asia on hyödyllinen Ubuntu- ja Debian-jakeluille. Tämä käyttöjärjestelmä voi kaatua ikuiseen käynnistykseen virheen vuoksi

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 Sopii lähes kaikkiin Ubuntu- ja Debian-jakeluihin.

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 

Mitä me olemme tehneet? Palautimme viestiväylän, joka puuttui Debianin/Ubuntun suorittamisesta, ja poistimme modules_dep:n, joka tuli OpenVZ:stä ja häiritsi monien ydinmoduulien lataamista.

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