Hoe u de OpenVZ 6-container zonder hoofdpijn naar de KVM-server kunt overbrengen

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 vaak wordt gedacht, zal OpenVZ onder de hostingproviders oververkocht raken, maar KVM niet - gelukkig voor laatstgenoemde is KVM nu niet slechter oververkocht dan zijn broer.

Wat gaan we overdragen?

Als proefpersonen voor de overdracht moesten we het hele bos aan besturingssystemen gebruiken die beschikbaar zijn op OpenVZ: CentOS (6- en 7-versies), Ubuntu (14, 16 en 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.

De migratie wordt uitgevoerd met behoud van het IP-adres van de overgedragen container; we gaan ervan uit dat het IP-adres dat de container had, op de VM wordt opgeslagen en zonder problemen 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! U moet een VM maken op het besturingssysteem dat momenteel op CTID draait. Als Ubuntu 14 bijvoorbeeld op de CTID is geïnstalleerd, moet Ubuntu 14 op de VM worden geïnstalleerd. Kleine versies zijn niet belangrijk en hun discrepantie is niet zo kritisch, maar de hoofdversies moeten hetzelfde zijn.

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 lijkt dit proces onschuldig:

# yum clean all
# yum update -y

En niet minder onschadelijk voor Ubuntu en 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/[email protected] /etc/systemd/system/getty.target.wants/[email protected]

Op servers 6 CentOS и 7 CentOS 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 7 CentOS 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

En het laatste is handig voor Ubuntu- en Debian-distributies. Dit besturingssysteem kan crashen bij een eeuwige opstart met een fout

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 Geschikt voor vrijwel alle Ubuntu- en Debian-distributies.

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 

Wat hebben we gedaan? We hebben messagebus hersteld, die ontbrak om Debian/Ubuntu uit te voeren, en modules_dep verwijderd, die van OpenVZ kwam en het laden van veel kernelmodules verstoorde.

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