🥇Cum să migrați un container OpenVZ 6 pe un server KVM fără dureri de cap

Oricine a avut nevoie măcar o dată în viață să migreze un container OpenVZ pe un server cu virtualizare completă KVM s-a confruntat cu unele probleme:

Majoritatea informațiilor sunt pur și simplu învechite și relevante pentru ciclii EOL ai sistemelor de operare care au trecut de mult.
Pentru diferite sisteme de operare sunt disponibile informații variate, iar posibilele erori în timpul migrației nu sunt niciodată analizate.
Uneori trebuie să te confrunți cu configurații care nu funcționează după migrație.

Când migrezi un singur server, mereu poți corecta ceva pe parcurs, dar ce faci când migrezi un întreg cluster?

În acest articol voi încerca să explic cum să migrezi corect un container OpenVZ pe KVM cu un timp minim de nefuncționare și o soluționare rapidă a tuturor problemelor.

Un mic curs introductiv: ce este OpenVZ și ce este KVM?

Nu ne vom aprofunda în terminologie, ci ne vom exprima în termeni generali:

OpenVZ — virtualizare la nivel de sistem de operare, poate fi implementată chiar și pe un cuptor cu microunde, deoarece nu este nevoie de instrucțiuni CPU și tehnologii de virtualizare pe mașina gazdă.

KVM — virtualizare completă, care folosește toată puterea CPU-ului și este capabilă să virtualizeze orice, în orice mod, tăind cum dorește.

Contrar opiniei populare că în mediu furnizori de găzduire OpenVZ este supus la overselling, iar KVM nu este — din fericire pentru cei din urmă, KVM-ul poate fi supus la overselling la fel de bine ca și omologul său.

Ce vom migra?

Ca subiecți pentru migrare, a fost necesar să utilizăm întreaga gamă de sisteme de operare disponibile pe OpenVZ: CentOS (versiunile 6 și 7), Ubuntu (14, 16 și 18 LTS), Debian 7.

Se presupunea că în majoritatea containerelor OpenVZ rulează un LAMP de bază, iar unele au un software foarte specific. De cele mai multe ori, acestea au fost configurații cu panouri de control ISPmanager, VestaCP (și cel mai frecvent, neactualizate de ani de zile). Este necesar să ținem cont de cerințele lor pentru migrare.

Migrarea se realizează cu păstrarea adrese IP containerului transferabil, vom considera că IP-ul care a fost în container rămâne pe VM și va funcționa fără probleme.

Înainte de migrare, să ne asigurăm că avem totul pregătit:

Server OpenVZ, acces root complet la mașina gazdă, capacitatea de a opri/monta/porni/elimina containerele.
Server KVM, acces root complet la mașina gazdă, cu toate cele ce decurg. Se presupune că totul este deja configurat și gata de utilizare.

Începem migrarea

Înainte de a începe migrarea, să stabilim termenii care ne vor ajuta să nu ne pierdem:

KVM_NODE — mașina gazdă KVM
VZ_NODE — mașina gazdă OpenVZ
CTID — container OpenVZ
VM — server virtual KVM

Pregătire pentru migrare și creare de mașini virtuale.

Pasul 1

Deoarece trebuie să migram containerul, să creăm VM cu o configurație similară pe KVM_NODE.
Important! Trebuie să creăm VM pe sistemul de operare care rulează acum pe CTID. De exemplu, dacă pe CTID este instalat Ubuntu 14, atunci și pe VM trebuie să instalăm Ubuntu 14. Versiunile minore nu sunt importante și necorespunderea lor nu este atât de critică, dar versiunile majore trebuie să fie identice.

După crearea VM, vom efectua actualizarea pachetelor pe CTID și pe VM (nu confundați cu actualizarea OS — nu actualizăm OS-ul, actualizăm doar pachetele și, dacă este necesar, versiunea OS în cadrul versiunii principale).

Pentru CentOS acest proces arată inofensiv:

# yum clean all
# yum update -y

Și la fel de inofensiv pentru Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Pasul 2

Instalăm pe CTID, VZ_NODE și VM utilitar rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Nu instalăm nimic altceva nici acolo, nici aici.

Pasul 3

Oprindem CTID pe VZ_NODE comanda

vzctl stop CTID

Montăm imaginea CTID:

vzctl mount CTID

Ne mutăm în folderul /vz/root/CTID și executăm

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

Sub chroot, creăm fișierul /root/exclude.txt — acesta va conține lista excluderilor care nu vor fi migrate pe noul 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

Ne conectăm la KVM_NODE și pornim VM, astfel încât să funcționeze și să fie accesibil prin rețea.

Acum totul este gata pentru migrare. Să începem!

Pasul 4

Rămânând încă sub chroot, executăm

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

Comanda rsync va executa migrarea; sperăm că cheile sunt clare — migrarea se face păstrând linkurile simbolice, permisiunile, proprietarii și grupurile, iar criptarea este dezactivată pentru o viteză mai mare (se putea folosi un cipher mai rapid, dar nu este atât de important în cadrul acestei sarcini), de asemenea, este dezactivată compresia.

După ce rsync a terminat, ieșim din chroot (prin apăsarea ctrl+d) și executăm

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

Pasul 5

Vom efectua câteva acțiuni care ne vor ajuta să pornim VM-ul după migrarea de la OpenVZ.
Pe serverele cu Systemd vom executa comanda care ne va ajuta să ne conectăm în consola normală, de exemplu, prin ecranul VNC al serverului

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

Pe serverele CentOS 6 și CentOS 7 vom instala neapărat un kernel proaspăt:

yum install kernel-$(uname -r)

Serverul poate fi încărcat de pe acesta, dar după transfer, acesta poate înceta să funcționeze sau poate fi șters.

Pe server CentOS 7 este necesar să aplicăm o mică corecție pentru PolkitD, altfel serverul va cădea într-o buclă infinită de boot:

getent group polkitd >/dev/null && echo -e "e[1;32mGrupul polkitd există dejae[0m" || { groupadd -r polkitd && echo -e "e[1;33mGrupul polkitd lipsă a fost adăugat e[0m" || echo -e "e[1;31mAdăugarea grupului polkitd a eșuat e[0m"; }

getent passwd polkitd >/dev/null 
&& echo -e "e[1;32mUtilizatorul polkitd există dejae[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "Utilizator pentru polkitd" polkitd && echo -e "e[1;33mUtilizatorul polkitd lipsă a fost adăugat e[0m" || echo -e "e[1;31mAdăugarea utilizatorului polkitd a eșuat e[0m"; }

rpm -Va polkit* && echo -e "e[1;32mVerificarea rpm pentru polkit* a trecut e[0m" || { echo -e "e[1;33mResetarea proprietății utilizatorului/grupului rpm polkit* și a permiselor e[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

Pe toate serverele, dacă a fost instalat mod_fcgid pentru Apache, vom aplica o mică corecție cu permisiunile, altfel site-urile care utilizează mod_fcgid vor cădea cu o eroare 500:

chmod +s `which suexec` && apachectl restart

Și în final, va fi util pentru distribuțiile Ubuntu și Debian. Această OS poate cădea într-o buclă infinită cu eroarea

looping too fast. throttling execution a little

neplăcut, dar se rezolvă ușor, în funcție de versiunea OS-ului.

Pe Debian 9 corecția arată astfel:

executăm

dbus-uuidgen

dacă primim o eroare

/usr/local/lib/libdbus-1.so.3: version `LIBDBUS_PRIVATE_1.10.8′ not found

verificăm existența 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 <== acesta este necesar
libdbus-1.so.3.14.16

dacă totul este în regulă, executăm

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

Dacă nu ajută — încercăm a doua variantă.

A doua variantă pentru soluționarea problemei cu throttling execution a little se potrivește practic pentru toate distribuțiile Ubuntu și Debian.

Executăm

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

Iar pentru Ubuntu 14, Debian 7 executăm suplimentar:

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

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

Ce am făcut? Am restaurat messagebus, care lipsea pentru a porni Debian/Ubuntu și am eliminat modules_dep, care provenea de la OpenVZ și împiedica încărcarea multor module ale nucleului.

Pasul 6

Rebootăm VM-ul, verificăm în VNC cum decurge încărcarea și în ideal — totul se va încărca fără probleme. Deși, este posibil să apară unele probleme specifice după migrare — dar acestea depășesc cadrul acestui articol și se rezolvă pe măsură ce apar.

Sper că aceste informații vor fi utile! 🙂

Sursa: habr.com