🥇Cum să migrezi containerul OpenVZ 6 pe serverul KVM fără dureri de cap

Oricine a avut nevoie să transfere un container OpenVZ pe un server cu virtualizare KVM completă cel puțin o dată în viață a întâmpinat unele probleme:

Majoritatea informațiilor sunt pur și simplu depășite și erau relevante pentru sistemele de operare care trecuseră de mult ciclul EOL
Sunt furnizate întotdeauna informații diferite pentru sisteme de operare diferite, iar posibilele erori în timpul migrării nu sunt niciodată luate în considerare
Uneori trebuie să te ocupi de configurații care din când în când nu vor să funcționeze după migrare

Când transferați 1 server, puteți oricând să remediați ceva din mers, dar când transferați un întreg cluster?

În acest articol, voi încerca să vă spun cum să migrați corect un container OpenVZ la KVM cu timp de nefuncționare minim și o soluție rapidă la toate problemele.

Un mic program educațional: ce este OpenVZ și ce este KVM?

Nu vom aprofunda terminologia, ci vom spune în termeni generali:

OpenVZ — virtualizare la nivel de sistem de operare, o puteți implementa 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 cu drepturi depline, folosind toată puterea procesorului și capabilă să virtualizeze orice, în orice mod, tăindu-l pe lungime și transversal.

Contrar opiniei populare, în mediu furnizori de găzduire OpenVZ este supravândut, dar KVM nu. Din fericire pentru acesta din urmă, KVM este acum supravândut la fel de bine ca și fratele său.

Ce vom duce mai departe?

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

Se presupunea că majoritatea containerelor OpenVZ rulau deja un fel de LAMP, iar unele chiar aveau un software foarte specific. Cel mai adesea, acestea au fost configurații cu ISPmanager, panoul de control VestaCP (și cel mai adesea, neactualizate de ani de zile). Trebuie luate în considerare și cererile lor de transfer.

Migrarea se realizează cu conservare adrese IP Pentru un container portabil, vom presupune că adresa IP a containerului este păstrată pe mașina virtuală și va funcționa fără probleme.

Înainte de transfer, să ne asigurăm că avem totul la îndemână:

Server OpenVZ, acces complet root la mașina gazdă, capacitatea de a opri/monta/porni/șterge containerele
Server KVM, acces complet root la mașina gazdă, cu tot ceea ce implică. Se presupune că totul este deja configurat și gata de funcționare.

Să începem transferul

Înainte de a începe transferul, să definim termenii care vă vor ajuta să evitați confuzia:

KVM_NODE - Mașină gazdă KVM
VZ_NODE - Mașină gazdă OpenVZ
CTID - Container OpenVZ
VM - Server virtual KVM

Pregătirea pentru migrare și crearea de mașini virtuale.

Pasul 1

Deoarece trebuie să mutăm containerul undeva, vom crea VM cu o configurație similară cu KVM_NODE.
Important! Создавать VM нужно именно на той операционной системе, которая сейчас крутится на CTID. Например, если на CTID установлена Ubuntu 14, то и на VM нужно ставить Ubuntu 14. Минорные версии не важны и их несовпадение не столь критично, а вот мажорные — должны быть одинаковыми.

După crearea VM-ului, vom actualiza pachetele pe CTID și pe VM (a nu se confunda cu actualizarea OS-ului - nu îl actualizăm, actualizăm doar pachetele și, dacă ajunge, versiunea OS din cadrul principalului versiune).

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

# yum clean all
# yum update -y

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

# apt-get update
# apt-get upgrade

Pasul 2

Instalați pe CTID, VZ_NODE и VM utilitate rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

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

Pasul 3

Facem o oprire CTID pe VZ_NODE echipă

vzctl stop CTID

Montarea imaginii CTID:

vzctl mount CTID

Accesați folderul /vz/root/CTID si executa

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

Sub rădăcină, creați un fișier /root/exclude.txt - acesta va conține o listă de excepții care nu vor ajunge la 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

Conectează la KVM_NODE și lansează-ne VMastfel încât să funcționeze și să fie accesibil prin rețea.

Acum totul este gata de transfer. Merge!

Pasul 4

Încă sub vrajă, performăm

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

Comanda rsync va efectua transferul, sperăm că cheile sunt clare - transferul se efectuează cu păstrarea legăturilor simbolice, a drepturilor de acces, a proprietarilor și a grupurilor, iar criptarea este dezactivată pentru o viteză mai mare (ați putea folosi un cifr mai rapid, dar acest lucru nu este atât de important pentru această sarcină), precum și compresia este dezactivată.

După finalizarea rsync, ieșiți din chroot (apăsând ctrl+d) și executați

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

Pasul 5

Să efectuăm câțiva pași care ne vor ajuta să lansăm VM-ul după transferul din OpenVZ.
Pe serverele cu systemd haideți să executăm o comandă care ne va ajuta să ne conectăm la o consolă obișnuită, de exemplu, printr-un ecran de server VNC

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

Pe servere CentOS 6 и CentOS 7 Asigurați-vă că instalați un nucleu nou:

yum install kernel-$(uname -r)

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

Pe server CentOS 7 trebuie să aplicați o mică remediere pentru PolkitD, altfel serverul se va prăbuși pentru totdeauna:

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

Pe toate serverele, dacă mod_fcgid pentru Apache a fost instalat, vom efectua o mică remediere cu drepturi, altfel site-urile care folosesc mod_fcgid se vor bloca cu eroarea 500:

chmod +s `which suexec` && apachectl restart

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

buclă prea repede. stropitând puțin execuția

neplăcut, dar ușor de reparat, în funcție de versiunea sistemului de operare.

Pe Debian 9 reparația arată așa:

executam

dbus-uuidgen

dacă primim o eroare

/usr/local/lib/libdbus-1.so.3: versiunea `LIBDBUS_PRIVATE_1.10.8′ nu a fost găsită

verificați prezenț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 <-- нужен этот
libdbus-1.so.3.14.16

dacă totul este în ordine, o facem

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ă, încercați a doua opțiune.

A doua soluție la problema cu stropitând puțin execuția подходит практически для всех Ubuntu и Debian дистрибутивов.

Realizăm

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

Și pentru Ubuntu 14, Debian 7 În plus, efectuăm:

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

Pasul 6

Repornim VM-ul, verificăm în VNC cum progresează încărcarea și, în mod ideal, totul se va încărca fără probleme. Deși este posibil ca unele probleme specifice să apară după migrare, acestea depășesc domeniul de aplicare al acestui articol și vor fi corectate pe măsură ce apar.

Sper că aceste informații sunt utile! 🙂

Sursa: www.habr.com