🥇Hoe u een OpenVZ 6-container zonder hoofdpijn naar een KVM-server migreert

Iedereen die minstens één keer in zijn leven een OpenVZ-container naar een server met volledige KVM-virtualisatie heeft moeten overbrengen, is een aantal problemen tegengekomen:

De meeste informatie is eenvoudigweg verouderd en relevant voor besturingssystemen die de EOL-cyclus al lang voorbij waren
Er wordt altijd verschillende informatie verstrekt voor verschillende besturingssystemen en er wordt nooit rekening gehouden met mogelijke fouten tijdens de migratie
Soms heb je te maken met configuraties die na de migratie zo nu en dan niet meer willen werken

Wanneer u 1 server overdraagt, kunt u altijd meteen iets repareren, maar wanneer u een heel cluster overdraagt?

In dit artikel zal ik proberen u te vertellen hoe u een OpenVZ-container correct naar KVM kunt migreren met minimale downtime en een snelle oplossing voor alle problemen.

Een klein educatief programma: wat is OpenVZ en wat is KVM?

We zullen niet diep ingaan op de terminologie, maar in algemene termen zeggen:

OpenVZ — virtualisatie op besturingssysteemniveau, u kunt het zelfs op een magnetron implementeren, aangezien er geen CPU-instructies en virtualisatietechnologieën op de hostmachine nodig zijn.

KVM - volwaardige virtualisatie, waarbij alle kracht van de CPU wordt gebruikt en die alles, op welke manier dan ook, kan virtualiseren, door het in de lengte en dwars door te snijden.

In tegenstelling tot wat algemeen wordt aangenomen, is er in het milieu hostingproviders OpenVZ is overgewaardeerd, maar KVM niet. Gelukkig voor laatstgenoemde is KVM nu net zo overgewaardeerd als zijn broertje.

Wat gaan we overdragen?

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

Er werd aangenomen dat de meeste OpenVZ-containers al een soort LAMP draaiden, en sommige hadden zelfs zeer specifieke software. Meestal waren dit configuraties met de ISPmanager, het VestaCP-controlepaneel (en meestal al jaren niet meer bijgewerkt). Er moet ook rekening worden gehouden met hun overdrachtsverzoeken.

Migratie wordt uitgevoerd met behoud van rechten. IP-adressen Voor een draagbare container gaan we ervan uit dat het IP-adres van de container behouden blijft op de virtuele machine en dat alles probleemloos zal werken.

Voordat we overstappen, zorgen we ervoor dat we alles bij de hand hebben:

OpenVZ-server, volledige root-toegang tot de hostmachine, mogelijkheid om containers te stoppen/mounten/starten/verwijderen
KVM-server, volledige root-toegang tot de hostmachine, met alles wat dit met zich meebrengt. Er wordt aangenomen dat alles al is geconfigureerd en klaar is voor gebruik.

Laten we beginnen met overdragen

Laten we, voordat we met de overdracht beginnen, termen definiëren die u helpen verwarring te voorkomen:

KVM_NODE - KVM-hostmachine
VZ_NODE - OpenVZ-hostmachine
CTID - OpenVZ-container
VM - KVM virtuele server

Voorbereiden van migratie en creëren van virtuele machines.

Stap 1

Omdat we de container ergens heen moeten verplaatsen, zullen we creëren VM met een vergelijkbare configuratie als KVM_NODE.
Belangrijk! Создавать VM нужно именно на той операционной системе, которая сейчас крутится на CTID. Например, если на CTID установлена Ubuntu 14, то и на VM нужно ставить Ubuntu 14. Минорные версии не важны и их несовпадение не столь критично, а вот мажорные — должны быть одинаковыми.

Nadat we de VM hebben gemaakt, zullen we de pakketten op de CTID en op de VM bijwerken (niet te verwarren met het updaten van het besturingssysteem - we updaten het niet, we updaten alleen de pakketten en, als het aankomt, de versie van het besturingssysteem binnen de hoofdmap versie).

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

# yum clean all
# yum update -y

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

# apt-get update
# apt-get upgrade

Stap 2

Installeer op CTID, VZ_NODE и VM nut rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

We installeren daar noch daar iets anders.

Stap 3

Wij maken een stop CTID op VZ_NODE team

vzctl stop CTID

Het beeld monteren CTID:

vzctl mount CTID

Ga naar de map /vz/root/CTID en uitvoeren

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

Maak onder de root een bestand /root/exclude.txt - dit bevat een lijst met uitzonderingen die de nieuwe server niet bereiken

/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

Verbinden aan KVM_NODE en lanceer onze VMzodat het werkt en toegankelijk is via het netwerk.

Nu is alles klaar voor overdracht. Gaan!

Stap 4

Nog steeds in de ban, treden wij op

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

Het rsync-commando zal de overdracht uitvoeren, we hopen dat de sleutels duidelijk zijn - de overdracht wordt uitgevoerd met behoud van symlinks, toegangsrechten, eigenaren en groepen, en de codering is uitgeschakeld voor grotere snelheid (je zou een snellere code kunnen gebruiken, maar dit is niet zo belangrijk voor deze taak) en de compressie is uitgeschakeld.

Nadat u rsync hebt voltooid, verlaat u chroot (door op ctrl+d te drukken) en voert u uit

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

Stap 5

Laten we verschillende stappen uitvoeren die ons zullen helpen de VM te starten na de overdracht van OpenVZ.
Op servers met systemd laten we een opdracht uitvoeren waarmee we kunnen inloggen op een gewone console, bijvoorbeeld via een VNC-serverscherm

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

Op servers CentOS 6 и CentOS 7 Zorg ervoor dat u een nieuwe kernel installeert:

yum install kernel-$(uname -r)

De server kan ervan worden geladen, maar na de overdracht kan deze niet meer werken of worden verwijderd.

Op server CentOS 7 je moet een kleine oplossing voor PolkitD toepassen, anders zal de server voor altijd crashen:

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

Als mod_fcgid voor Apache is geïnstalleerd, zullen we op alle servers een kleine oplossing met rechten uitvoeren, anders zullen sites die mod_fcgid gebruiken crashen met fout 500:

chmod +s `which suexec` && apachectl restart

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

te snel ronddraaien. uitvoering een beetje vertragen

onaangenaam, maar eenvoudig op te lossen, afhankelijk van de versie van het besturingssysteem.

Op Debian 9 de oplossing ziet er als volgt uit:

wij voeren uit

dbus-uuidgen

als we een foutmelding krijgen

/usr/local/lib/libdbus-1.so.3: versie `LIBDBUS_PRIVATE_1.10.8′ niet gevonden

controleer de aanwezigheid van 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

als alles in orde is, doen we het

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

Als het niet helpt, probeer dan de tweede optie.

De tweede oplossing voor het probleem met uitvoering een beetje vertragen подходит практически для всех Ubuntu и Debian дистрибутивов.

Wij voeren uit

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

En voor Ubuntu 14, Debian 7 Daarnaast voeren wij uit:

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 и мешал загрузки многих модулей ядра.

Stap 6

We herstarten de VM, checken in VNC hoe het laden vordert en idealiter laadt alles zonder problemen. Hoewel het mogelijk is dat er na de migratie enkele specifieke problemen zullen optreden, vallen deze buiten het bestek van dit artikel en zullen ze worden gecorrigeerd zodra ze zich voordoen.

Ik hoop dat deze informatie nuttig is! 🙂

Bron: www.habr.com