ProHoster > Log > administrasjon > Hvordan overføre OpenVZ 6-beholder til KVM-server uten hodepine

Hvordan overføre OpenVZ 6-beholder til KVM-server uten hodepine

Alle som har hatt behov for å overføre en OpenVZ-beholder til en server med full KVM-virtualisering minst én gang i livet, har støtt på noen problemer:

  • Det meste av informasjonen er rett og slett utdatert og var relevant for operativsystemer som lenge hadde passert EOL-syklusen
  • Ulik informasjon er alltid gitt for ulike operativsystemer, og mulige feil under migrering blir aldri vurdert
  • Noen ganger må du forholde deg til konfigurasjoner som nå og da ikke vil fungere etter migrering

Når du overfører 1 server, kan du alltid fikse noe på flukt, men når du overfører en hel klynge?

I denne artikkelen vil jeg prøve å fortelle deg hvordan du skal migrere en OpenVZ-beholder til KVM med minimal nedetid og en rask løsning på alle problemer.

Et lite pedagogisk program: hva er OpenVZ og hva er KVM?

Vi vil ikke gå dypt inn i terminologien, men vil si generelt:

OpenVZ — virtualisering på operativsystemnivå, du kan til og med distribuere den på en mikrobølgeovn, siden det ikke er behov for CPU-instruksjoner og virtualiseringsteknologier på vertsmaskinen.

KVM - Fullverdig virtualisering, som bruker all kraften til CPU'en og er i stand til å virtualisere hva som helst, på hvilken som helst måte, kutte den på langs og på tvers.

I motsetning til det mange tror at blant hostingleverandører vil OpenVZ bli oversolgt, men KVM vil ikke – heldigvis for sistnevnte, er KVM nå ikke verre enn sin bror.

Hva skal vi bære over?

Som testpersoner for overføringen måtte vi bruke hele skogen av operativsystemer som er tilgjengelig på OpenVZ: CentOS (6 og 7 versjoner), Ubuntu (14, 16 og 18 LTS), Debian 7.

Det ble antatt at de fleste av OpenVZ-beholderne allerede kjørte en slags LAMPE, og noen hadde til og med veldig spesifikk programvare. Oftest var dette konfigurasjoner med ISPmanager, VestaCP kontrollpanel (og oftest ikke oppdatert på flere år). Deres overføringsforespørsler må også tas i betraktning.

Migrering utføres mens IP-adressen til den overførte beholderen bevares; vi vil anta at IP-en som beholderen hadde er lagret på VM og vil fungere uten problemer.

Før du overfører, la oss sørge for at vi har alt for hånden:

  • OpenVZ-server, full root-tilgang til vertsmaskinen, mulighet til å stoppe/montere/starte/slette containere
  • KVM-server, full root-tilgang til vertsmaskinen, med alt det innebærer. Det antas at alt allerede er konfigurert og klart til bruk.

La oss begynne å overføre

Før vi begynner overføringen, la oss definere begreper som vil hjelpe deg å unngå forvirring:

KVM_NODE - KVM vertsmaskin
VZ_NODE - OpenVZ vertsmaskin
CTID - OpenVZ container
VM - Virtuell KVM-server

Forbereder migrering og oppretter virtuelle maskiner.

Trinn 1

Siden vi må flytte beholderen et sted, oppretter vi VM med en lignende konfigurasjon som KVM_NODE.
Viktig! Du må opprette en VM på operativsystemet som for øyeblikket kjører på CTID. For eksempel, hvis Ubuntu 14 er installert på CTID, må Ubuntu 14 installeres på VM. Mindre versjoner er ikke viktige og avviket deres er ikke så kritisk, men hovedversjonene bør være de samme.

Etter å ha opprettet VM, vil vi oppdatere pakkene på CTID og VM (ikke å forveksle med oppdatering av OS - vi oppdaterer det ikke, vi oppdaterer bare pakkene og, hvis det kommer, OS-versjonen i hovedmenyen versjon).

For CentOS ser denne prosessen harmløs ut:

# yum clean all
# yum update -y

Og ikke mindre ufarlig for Ubuntu og Debian:

# apt-get update
# apt-get upgrade

Trinn 2

Installer på CTID, VZ_NODE и VM nytte rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Vi installerer ikke noe annet verken der eller der.

Trinn 3

Vi stopper CTID på VZ_NODE team

vzctl stop CTID

Montering av bildet CTID:

vzctl mount CTID

Gå til mappen /vz/root/CTID og utføre

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

Under roten oppretter du en fil /root/exclude.txt - den vil inneholde en liste over unntak som ikke kommer til den nye serveren

/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

Vi kobler til KVM_NODE og lanser vår VMslik at den fungerer og er tilgjengelig over nettverket.

Nå er alt klart for overføring. Gå!

Trinn 4

Fortsatt under troll, vi presterer

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

rsync-kommandoen vil utføre overføringen, vi håper at nøklene er klare - overføringen utføres med bevaring av symbolkoblinger, tilgangsrettigheter, eiere og grupper, og kryptering er deaktivert for høyere hastighet (du kan bruke noe raskere chiffer, men dette er ikke så viktig for denne oppgaven), så vel som komprimering er deaktivert.

Etter å ha fullført rsync, gå ut av chroot (ved å trykke ctrl+d) og kjør

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

Trinn 5

La oss utføre flere trinn som vil hjelpe oss å starte VM etter overføring fra OpenVZ.
På servere med systemd la oss utføre en kommando som vil hjelpe oss å logge på en vanlig konsoll, for eksempel gjennom en VNC-serverskjerm

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

På servere 6 CentOS и 7 CentOS Sørg for å installere en ny kjerne:

yum install kernel-$(uname -r)

Serveren kan lastes fra den, men etter overføringen kan den slutte å fungere eller bli slettet.

På server 7 CentOS du må bruke en liten rettelse for PolkitD, ellers vil serveren krasje for alltid:

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

På alle servere, hvis mod_fcgid for Apache ble installert, vil vi utføre en liten reparasjon med rettigheter, ellers vil nettsteder som bruker mod_fcgid krasje med feil 500:

chmod +s `which suexec` && apachectl restart

Og det siste er nyttig for Ubuntu- og Debian-distribusjoner. Dette operativsystemet kan krasje inn i en evig oppstart med en feil

looper for fort. strupende utførelse litt

ubehagelig, men lett fikset, avhengig av OS-versjonen.

På Debian 9 reparasjonen ser slik ut:

vi gjennomfører

dbus-uuidgen

hvis vi får en feil

/usr/local/lib/libdbus-1.so.3: versjon `LIBDBUS_PRIVATE_1.10.8' ble ikke funnet

sjekk tilstedeværelsen av LIBDBUS 

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

hvis alt er i orden, gjør vi det

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

Hvis det ikke hjelper, prøv det andre alternativet.

Den andre løsningen på problemet med strupende utførelse litt Passer for nesten alle Ubuntu- og Debian-distribusjoner.

Vi gjennomfører

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

Og for Ubuntu 14, Debian 7 I tillegg utfører vi:

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

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

Hva har vi gjort? Vi gjenopprettet messagebus, som manglet for å kjøre Debian/Ubuntu, og fjernet modules_dep, som kom fra OpenVZ og forstyrret lasting av mange kjernemoduler.

Trinn 6

Vi starter VM på nytt, sjekker i VNC hvordan lastingen utvikler seg, og ideelt sett vil alt lastes uten problemer. Selv om det er mulig at noen spesifikke problemer vil dukke opp etter migreringen, er de utenfor rammen av denne artikkelen og vil bli rettet etter hvert som de oppstår.

Jeg håper denne informasjonen er nyttig! 🙂

Kilde: www.habr.com

Legg til en kommentar