Hoe kinne jo OpenVZ 6-container oerdrage nei KVM-tsjinner sûnder hoofdpijn

Elkenien dy't op syn minst ien kear yn har libben in OpenVZ-kontener oerdrage moat nei in server mei folsleine KVM-virtualisaasje, hat wat problemen tsjinkaam:

  • De measte fan 'e ynformaasje is gewoan ferâldere en wie relevant foar OS's dy't de EOL-syklus al lang foarby wiene
  • Ferskillende ynformaasje wurdt altyd levere foar ferskate bestjoeringssystemen, en mooglike flaters by migraasje wurde nea beskôge
  • Soms hawwe jo te krijen mei konfiguraasjes dy't sa no en dan net wurkje wolle nei migraasje

As jo ​​oerdrage 1 tsjinner, kinne jo altyd reparearje wat op 'e fly, mar as jo oerdrage in hiele kluster?

Yn dit artikel sil ik besykje jo te fertellen hoe't jo in OpenVZ-kontener korrekt kinne migrearje nei KVM mei minimale downtime en in rappe oplossing foar alle problemen.

In lyts edukatyf programma: wat is OpenVZ en wat is KVM?

Wy geane net djip yn terminology, mar sille yn algemiene termen sizze:

OpenVZ - virtualisaasje op bestjoeringssysteemnivo, jo kinne it sels ynsette op in magnetron, om't d'r gjin CPU-ynstruksjes en virtualisaasjetechnologyen nedich binne op 'e hostmasine.

KVM - Folsleine virtualisaasje, mei alle krêft fan 'e CPU en yn steat om alles te virtualisearjen, op elke manier, it yn' e lingte en dwers te snijen.

Yn tsjinstelling ta populêr leauwen dat ûnder hostingproviders OpenVZ oerferkocht sil wurde, mar KVM sil net - gelokkich foar de lêste is KVM no net slimmer oerferkocht dan syn broer.

Wat sille wy oerdrage?

As testûnderwerpen foar de oerdracht moasten wy it hiele bosk fan bestjoeringssystemen brûke dy't beskikber binne op OpenVZ: CentOS (6 en 7 ferzjes), Ubuntu (14, 16 en 18 LTS), Debian 7.

It waard oannommen dat de measte fan 'e OpenVZ-konteners al in soarte fan LAMP rûnen, en guon hienen sels wat heul spesifike software. Meastentiids wiene dit konfiguraasjes mei de ISPmanager, VestaCP-kontrôlepaniel (en meastal jierren net bywurke). Harren oerdracht oanfragen moatte ek rekken holden wurde.

Migraasje wurdt útfierd mei it behâld fan it IP-adres fan 'e oerdroegen kontener; wy sille oannimme dat it IP dat de kontener hie opslein is op 'e VM en sûnder problemen sil wurkje.

Foardat jo oerdrage, litte wy derfoar soargje dat wy alles by de hân hawwe:

  • OpenVZ-tsjinner, folsleine root-tagong ta de hostmasine, mooglikheid om konteners te stopjen / mount / start / wiskje
  • KVM-tsjinner, folsleine root tagong ta de hostmasine, mei alles wat it ymplisearret. Der wurdt fan útgien dat alles al is konfigurearre en klear om te gean.

Litte wy begjinne mei oerdracht

Foardat wy de oerdracht begjinne, litte wy termen definiearje dy't jo sille helpe om betizing te foarkommen:

KVM_NODE - KVM host masine
VZ_NODE - OpenVZ host masine
CTID - OpenVZ kontener
VM - KVM firtuele tsjinner

Tariede op migraasje en it meitsjen fan firtuele masines.

stap 1

Sûnt wy moatte ferpleatse de kontener earne, wy sille meitsje VM mei in fergelykbere konfiguraasje oan KVM_NODE.
Wichtich! Jo moatte in VM oanmeitsje op it bestjoeringssysteem dat op it stuit rint op CTID. Bygelyks, as Ubuntu 14 is ynstalleare op 'e CTID, dan moat Ubuntu 14 ynstalleare wurde op' e VM. Minor ferzjes binne net wichtich en har diskrepânsje is net sa kritysk, mar grutte ferzjes moatte itselde wêze.

Nei it oanmeitsjen fan de VM sille wy de pakketten bywurkje op 'e CTID en op' e VM (net te betiizjen mei it bywurkjen fan it OS - wy aktualisearje it net, wy aktualisearje allinich de pakketten en, as it komt, de OS-ferzje yn 'e haad ferzje).

Foar CentOS sjocht dit proses harmless:

# yum clean all
# yum update -y

En net minder harmless foar Ubuntu en Debian:

# apt-get update
# apt-get upgrade

stap 2

Ynstallearje op CTID, VZ_NODE и VM nut rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Wy ynstallearje neat oars noch dêr of dêr.

stap 3

Wy meitsje in halte CTID op VZ_NODE ploech

vzctl stop CTID

Montearje de ôfbylding CTID:

vzctl mount CTID

Gean nei de map /vz/root/CTID en útfiere

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

Meitsje ûnder de root in triem /root/exclude.txt - it sil in list mei útsûnderings befetsje dy't net nei de nije tsjinner komme

/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

Wy ferbine mei KVM_NODE en lansearje ús VMsadat it wurket en is tagonklik oer it netwurk.

No is alles klear foar oerdracht. Go!

stap 4

Noch yn 'e tsjoen, wy prestearje

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

It kommando rsync sil de oerdracht útfiere, wy hoopje dat de kaaien dúdlik binne - de oerdracht wurdt útfierd mei it behâld fan symlinks, tagongsrjochten, eigners en groepen, en fersifering is útskeakele foar gruttere snelheid (jo kinne wat flugger sifer brûke, mar dit is net sa wichtich foar dizze taak) , lykas kompresje is útskeakele.

Nei it foltôgjen fan rsync, gean út chroot (troch te drukken op ctrl + d) en útfiere

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

stap 5

Litte wy ferskate stappen útfiere dy't ús sille helpe de VM te starten nei it oerdragen fan OpenVZ.
Op tsjinners mei Systemd litte wy in kommando útfiere dat ús sil helpe oanmelde by in gewoane konsole, bygelyks fia in VNC-tsjinner skerm

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

Op tsjinners CentOS 6 и CentOS 7 Wês wis dat jo in frisse kernel ynstallearje:

yum install kernel-$(uname -r)

De tsjinner kin derút laden wurde, mar nei de oerdracht kin it ophâlde mei wurkjen of wiske wurde.

Op tsjinner CentOS 7 jo moatte in lytse fix foar PolkitD tapasse, oars sil de tsjinner foar altyd crashe:

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

Op alle servers, as mod_fcgid foar Apache ynstalleare is, sille wy in lytse fix mei rjochten útfiere, oars sille siden dy't mod_fcgid brûke sille crashe mei flater 500:

chmod +s `which suexec` && apachectl restart

En it lêste ding is nuttich foar Ubuntu- en Debian-distribúsjes. Dit OS kin crashe yn in ivige boot mei in flater

te hurd loopen. throttling útfiering in bytsje

onaangenaam, mar maklik fêst, ôfhinklik fan de OS ferzje.

op Debian 9 de fix sjocht der sa út:

wy útfiere

dbus-uuidgen

as wy in flater krije

/usr/local/lib/libdbus-1.so.3: ferzje `LIBDBUS_PRIVATE_1.10.8′ net fûn

kontrolearje de oanwêzigens fan 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

as alles yn oarder is, dogge wy it

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

As it net helpt, besykje de twadde opsje.

De twadde oplossing foar it probleem mei throttling útfiering in bytsje Geskikt foar hast alle Ubuntu- en Debian-distribúsjes.

Wy fiere út

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

En foar Ubuntu 14, Debian 7 Dêrneist fiere wy:

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

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

Wat hawwe wy dien? Wy restaurearre berjochtbus, dy't ûntbrekt om Debian/Ubuntu út te fieren, en modules_dep fuortsmiten, dy't kaam fan OpenVZ en bemuoide mei it laden fan in protte kearnmodules.

stap 6

Wy starte de VM opnij, kontrolearje yn VNC hoe't it laden foarútgiet en, ideaal, alles sil sûnder problemen laden. Hoewol it mooglik is dat guon spesifike problemen nei de migraasje ferskine, binne se bûten it berik fan dit artikel en wurde korrizjearre as se ûntsteane.

Ik hoopje dat dizze ynformaasje nuttich is! 🙂

Boarne: www.habr.com

Add a comment