🥇Hvordan migrere en OpenVZ 6-container til en KVM-server uten problemer

Alle som noen gang har hatt behov for å migrere en OpenVZ-container til en server med full KVM-virtualisering har støtt på en rekke problemer:

Det meste av informasjonen er rett og slett utdatert og var relevant for operativsystemer som allerede har fullført EOL-syklusen for lenge siden.
Ulike operativsystemer gir alltid forskjellig informasjon, og mulige feil under migreringen blir aldri vurdert.
Noen ganger må du hanskes med konfigurasjoner som ikke fungerer etter migrering.

Når du migrerer én server, kan du alltids fikse noe mens du er i gang, men hva med når du migrerer en hel klynge?

I denne artikkelen skal jeg forklare hvordan du migrerer en OpenVZ-container til KVM på riktig måte med minimal nedetid og en rask løsning på alle problemer.

En rask innføring: Hva er OpenVZ og hva er KVM?

La oss ikke gå inn på detaljene i terminologien, men heller gi en generell oversikt:

OpenVZ – virtualisering på operativsystemnivå kan distribueres selv på en mikrobølgeovn, siden det ikke er behov for CPU-instruksjoner og virtualiseringsteknologier på vertsmaskinen.

KVM — fullverdig virtualisering, som bruker CPU-ens fulle kraft og er i stand til å virtualisere hva som helst, akkurat som du vil, ved å kutte det på langs og på tvers.

I motsetning til hva mange tror, i miljøet hostingleverandører OpenVZ er oversolgt, men det er ikke KVM. Heldigvis for sistnevnte er KVM nå like oversolgt som broren sin.

Hva skal vi overføre?

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

Det ble antatt at de fleste OpenVZ-containere allerede kjørte en slags LAMP, og noen hadde til og med veldig spesifikk programvare. Oftest var dette konfigurasjoner med ISPmanager eller VestaCP-kontrollpanelet (og ofte hadde de ikke blitt oppdatert på flere år). Deres migreringskrav måtte også tas i betraktning.

Migrering utføres med bevaring IP-adresser For en bærbar container antar vi at IP-adressen til containeren er bevart på den virtuelle maskinen og vil fungere uten problemer.

Før vi 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/fjerne containere
En KVM-server med full root-tilgang til vertsmaskinen, med alt hva det innebærer. Dette forutsetter at alt allerede er konfigurert og klart til bruk.

La oss starte overføringen

Før vi starter overføringen, la oss definere noen begreper for å unngå forvirring:

KVM_NODE — KVM-vertsmaskin
VZ_NODE - OpenVZ-vertsmaskin
CTID — OpenVZ-container
VM — virtuell KVM-server

Forberedelse for migrering og oppretting av virtuelle maskiner.

Trinn 1

Siden vi må flytte containeren et sted, vil vi lage VM med en lignende konfigurasjon på KVM_NODE.
Viktig! Создавать VM нужно именно на той операционной системе, которая сейчас крутится на CTID. Например, если на CTID установлена Ubuntu 14, то и на VM нужно ставить Ubuntu 14. Минорные версии не важны и их несовпадение не столь критично, а вот мажорные — должны быть одинаковыми.

Etter at vi har opprettet den virtuelle maskinen, oppdaterer vi pakkene på CTID-en og på den virtuelle maskinen (ikke å forveksle med å oppdatere operativsystemet – vi oppdaterer ikke operativsystemet, vi oppdaterer bare pakkene og, om nødvendig, operativsystemversjonen i hovedversjonen).

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

# yum clean all
# yum update -y

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

# apt-get update
# apt-get upgrade

Trinn 2

Vi installerer 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 opp CTID på VZ_NODE team

vzctl stop CTID

Montering av bildet CTID:

vzctl mount CTID

Gå til /vz/root/-mappenCTID og vi gjennomfører det

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

Under chroot, opprett filen /root/exclude.txt – den vil inneholde en liste over unntak som ikke vil bli inkludert på 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

La oss koble oss til KVM_NODE og lansere vår VMslik at den fungerer og er tilgjengelig over nettverket.

Nå er alt klart for overføringen. La oss sette i gang!

Trinn 4

Fortsatt påvirket, opptrer vi

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 nøklene er klare: overføringen utføres med bevaring av symlenker, tilgangsrettigheter, eiere og grupper, og kryptering er deaktivert for høyere hastighet (en raskere kryptering kunne ha blitt brukt, men dette er ikke så viktig for denne oppgaven), samt komprimering.

Etter at rsync er fullført, avslutt chroot (ved å trykke ctrl+d) og utfør

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

Trinn 5

La oss utføre flere handlinger som vil hjelpe oss med å starte den virtuelle maskinen etter migrering fra OpenVZ.
På servere med systemd La oss kjøre en kommando som hjelper oss å logge inn på en vanlig konsoll, for eksempel via en VNC-serverskjerm.

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

På servere CentOS 6 и CentOS 7 Vi kommer definitivt til å installere en ny kjerne:

yum install kernel-$(uname -r)

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

På server CentOS 7 Du må legge inn en liten løsning 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; }

Hvis mod_fcgid ble installert for Apache på alle servere, vil vi utføre en liten rettighetsrettelse. Ellers vil nettsteder som bruker mod_fcgid krasje med en 500-feil:

chmod +s `which suexec` && apachectl restart

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

Løkker for fort. reduserer utførelsen litt

Det er ubehagelig, men det er lett å fikse, avhengig av operativsystemversjonen.

På Debian 9 rettelsen ser slik ut:

vi opptrer

dbus-uuidgen

hvis vi får en feil

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

Kontrollerer 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, gjennomfører vi

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.

Det andre alternativet for å løse problemet med litt struping av utførelsen подходит практически для всех Ubuntu и Debian дистрибутивов.

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

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

Trinn 6

Start den virtuelle maskinen på nytt, sjekk oppstartsprosessen i VNC, og ideelt sett vil alt starte opp uten problemer. Selv om det kan oppstå noen spesifikke problemer etter migreringen, er de utenfor rammen av denne artikkelen og vil bli adressert etter hvert som de oppstår.

Jeg håper denne informasjonen er nyttig! 🙂

Kilde: www.habr.com