🥇Sådan migreres OpenVZ 6 container til KVM-server uden hovedpine

Enhver, der nogensinde har haft brug for at flytte en OpenVZ-container til en server med fuldgyldig KVM-virtualisering, er stødt på nogle problemer:

De fleste af oplysningerne er simpelthen forældede og var relevante for operativsystemer, der for længst har bestået EOL-cyklussen
Forskellige OS giver altid forskellige oplysninger og overvejer aldrig mulige migreringsfejl
Nogle gange er du nødt til at håndtere konfigurationer, der ikke vil fungere efter migrering.

Når du migrerer 1 server, kan du altid rette noget med det samme, men hvad med, når du migrerer en hel klynge?

I denne artikel vil jeg forsøge at fortælle dig, hvordan du korrekt migrerer en OpenVZ-container til KVM med minimal nedetid og en hurtig løsning på alle problemer.

En hurtig primer: hvad er OpenVZ, og hvad er KVM?

Lad os ikke gå ind i terminologi, men bare sige i generelle vendinger:

OpenVZ - virtualisering på operativsystemniveau, kan implementeres selv på en mikrobølgeovn, da der ikke er behov for CPU-instruktioner og virtualiseringsteknologier på værtsmaskinen.

KVM — fuldgyldig virtualisering, der bruger CPU'ens fulde kraft og er i stand til at virtualisere hvad som helst, på nogen måde, skære det på langs og på tværs.

I modsætning til hvad mange tror, i miljøet hostingudbydere OpenVZ er oversolgt, men det er KVM ikke. Heldigvis for sidstnævnte er KVM nu lige så godt oversolgt som sin bror.

Hvad skal vi overføre?

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

Det blev antaget, at de fleste OpenVZ containere allerede havde en slags LAMP kørende, og nogle havde endda noget meget specifik software. Oftest var disse konfigurationer med ISPmanager, VestaCP kontrolpanel (og oftest ikke opdateret i årevis). Deres overførselsanmodninger skal også tages i betragtning.

Migration udføres med bevaring IP-adresser For en bærbar container antager vi, at containerens IP-adresse bevares på den virtuelle maskine og vil fungere uden problemer.

Inden du overfører, lad os sørge for, at vi har alt ved hånden:

OpenVZ-server, fuld root-adgang til værtsmaskinen, mulighed for at stoppe/montere/starte/fjerne containere
KVM-server, fuld root-adgang til værtsmaskinen, med alt hvad det medfører. Det antages, at alt allerede er konfigureret og klar til at fungere.

Lad os starte overførslen

Før vi begynder overførslen, lad os definere termer, der hjælper med at undgå forvirring:

KVM_NODE — KVM-værtsmaskine
VZ_NODE - OpenVZ værtsmaskine
CTID — OpenVZ container
VM — Virtuel KVM-server

Forberedelse til migrering og oprettelse af virtuelle maskiner.

Trin 1

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

Efter oprettelse af VM'en vil vi opdatere pakkerne på CTID'en og på VM'en (ikke at forveksle med opdatering af OS - vi opdaterer det ikke, vi opdaterer kun pakkerne og om nødvendigt OS-versionen i hovedversionen).

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

# yum clean all
# yum update -y

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

# apt-get update
# apt-get upgrade

Trin 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 andet hverken her eller der.

Trin 3

Vi gør et stop CTID på VZ_NODE hold

vzctl stop CTID

Montering af billedet CTID:

vzctl mount CTID

Gå til mappen /vz/root/CTID og vi udfører det

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

Under chroot skal du oprette en fil /root/exclude.txt - den vil indeholde en liste over undtagelser, der ikke vil blive inkluderet på den nye server

/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

Lad os oprette forbindelse til KVM_NODE og lancere vores VMså det fungerer og er tilgængeligt over netværket.

Nu er alt klar til overførsel. Lad os gå!

Trin 4

Stadig under indflydelse optræder vi

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

Kommandoen rsync vil udføre overførslen, vi håber, at nøglerne er klare - overførslen udføres med bevarelse af symbolske links, adgangsrettigheder, ejere og grupper, og kryptering er deaktiveret for større hastighed (det var muligt at bruge noget hurtigere krypteringsnummer, men dette er ikke så vigtigt inden for rammerne af denne opgave), ligesom komprimering er deaktiveret.

Når rsync er færdig, skal du afslutte chroot (ved at trykke på ctrl+d) og udføre

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

Trin 5

Lad os udføre flere handlinger, der vil hjælpe os med at starte VM'en efter migrering fra OpenVZ.
På servere med systemd lad os køre en kommando, der hjælper os med at logge ind på en almindelig konsol, for eksempel via en VNC-serverskærm

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 sørg for at installere en frisk kerne:

yum install kernel-$(uname -r)

Serveren kan downloades fra den, men efter overførslen kan den stoppe med at fungere eller blive slettet.

På serveren CentOS 7 du skal anvende en lille rettelse til PolkitD, ellers vil serveren falde i en evig boot:

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 blev installeret til Apache, vil vi udføre en lille rettelse med rettigheder, ellers vil websteder, der bruger mod_fcgid, gå ned med fejl 500:

chmod +s `which suexec` && apachectl restart

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

sløjfer for hurtigt. droslende udførelse lidt

ubehageligt, men let løst, afhængigt af OS-versionen.

On Debian 9 rettelsen ser sådan ud:

vi gør

dbus-uuidgen

hvis vi får en fejl

/usr/local/lib/libdbus-1.so.3: version `LIBDBUS_PRIVATE_1.10.8' blev ikke fundet

tjek for 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 ok, udfører 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 hjælper, så prøv den anden mulighed.

Den anden mulighed for at løse problemet med droslende udførelse lidt подходит практически для всех Ubuntu и Debian дистрибутивов.

Vi udfører

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

Og for Ubuntu 14, Debian 7 Derudover udfø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 и мешал загрузки многих модулей ядра.

Trin 6

Vi genstarter VM'en, tjekker i VNC, hvordan indlæsningen foregår, og ideelt set vil alt indlæses uden problemer. Selvom der kan være nogle specifikke problemer efter migreringen, er de uden for denne artikels omfang og bliver rettet, efterhånden som de opstår.

Jeg håber, at disse oplysninger vil være nyttige! 🙂

Kilde: www.habr.com