Kako prenijeti OpenVZ 6 kontejner na KVM server bez boli u glavi

Svaka osoba koja je barem jednom u životu trebala prenijeti OpenVZ kontejner na server s punom virtualizacijom KVM suočila se s određenim problemima:

  • Većina informacija je jednostavno zastarjela i bila je aktualna za operacijske sustave koji su davno prošli EOL ciklus.
  • Različite operacijske sustave nude različite informacije i nikada se ne razmatraju moguće greške prilikom migracije.
  • Ponekad se morate nositi s konfiguracijama koje iznenada prestanu raditi nakon migracije.

Kada premještate jedan server, uvijek možete nešto popraviti u hodu, a što ako migrirate čitav klaster?

U ovom ću članku pokušati objasniti kako ispravno migrirati OpenVZ kontejner na KVM s minimalnim vremenom zastoja i brzim rješavanjem svih problema.

Mali uvod: što su OpenVZ i KVM?

Nećemo se previše zamarati terminologijom, već ćemo reći u općim crtama:

OpenVZ — virtualizacija na razini operativnog sustava, može se rasporediti čak i na mikrovalnoj pećnici, jer nema potrebe za instrukcijama CPU-a i tehnologijama virtualizacije na domaćinskoj mašini.

KVM — puna virtualizacija koja koristi svu snagu CPU-a i može virtualizirati što god želite, kako god želite, rezati po dužini i širini.

Suprotno uvriježenom mišljenju da se u okruženju hosting provider-a OpenVZ prelijeva, a KVM ne — na sreću za potonje, KVM se danas prelijeva ništa lošije od svog rođaka.

Što ćemo prenositi?

Kao eksperiment za prenos koristit ćemo cijelu šumu operativnih sustava koji su dostupni na OpenVZ: CentOS (verzije 6 i 7), Ubuntu (14, 16 i 18 LTS), Debian 7.

Pretpostavljalo se da se na većini OpenVZ kontejnera već pokreće neki LAMP, a neki imaju čak i vrlo specifičan softver. Najčešće su to bile konfiguracije s upravljačkom pločom ISPmanager, VestaCP (i obično ne ažurirane godinama). Također je potrebno uzeti u obzir njihove zahtjeve za prijenos.

Migracija se vrši uz zadržavanje IP adrese prenosivog kontejnera, pretpostavit ćemo da IP koji je bio kod kontejnera ostaje na VM-u i da će raditi bez problema.

Prije prijenosa osigurajte da imate sve na raspolaganju:

  • OpenVZ server, potpuni root pristup domaćinskoj mašini, mogućnost zaustavljanja/montiranja/pokretanja/brisanja kontejnera.
  • KVM server, potpuni root pristup domaćinskoj mašini, sa svim posljedicama. Pretpostavlja se da je sve već postavljeno i spremno za rad.

Počinjemo s prijenosom

Prije nego što započnemo prijenos, definirajmo pojmove koji će nas usmjeriti:

KVM_NODE — KVM host-mašina
VZ_NODE — OpenVZ host-mašina
CTID — OpenVZ kontejner
VM — KVM virtualni server

Priprema za prijenos i stvaranje virtualnih mašina.

Korak 1

Budući da trebamo negdje premjestiti kontejner, stvorimo VM slične konfiguracije na KVM_NODE.
Važno! VM treba stvoriti na operativnom sustavu koji trenutno radi na CTID-u. Na primjer, ako je na CTID-u instalirana Ubuntu 14, i na VM treba instalirati Ubuntu 14. Manje verzije nisu toliko važne i njihovo nepodudaranje nije kritično, ali glavne — moraju biti jednake.

Nakon stvaranja VM, izvršit ćemo ažuriranje paketa na CTID i na VM (ne miješati s ažuriranjem OS-a — ne ažuriramo ga, samo ažuriramo pakete i, ako dođe, verziju OS-a unutar glavne verzije).

Za CentOS ovaj proces izgleda bezopasno:

# yum clean all
# yum update -y

I ne manje bezopasno za Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Korak 2

Instaliramo na CTID, VZ_NODE i VM alatku rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Ne instaliramo ništa drugo ni tamo ni ovdje.

Korak 3

Obustavljamo CTID na VZ_NODE komandom

vzctl stop CTID

Montiramo sliku CTID:

vzctl mount CTID

Prelazimo u folder /vz/root/CTID i izvršavamo

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

Unutar chroot okruženja kreiramo datoteku /root/exclude.txt — ona će sadržavati popis iznimki koje neće biti prenesene na novi 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

Povezujemo se na KVM_NODE i pokrećemo naš VM, kako bi radio i bio dostupan putem mreže.

Sada je sve spremno za prijenos. Kako idemo!

Korak 4

Još uvijek unutar chroot okruženja, izvršavamo

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

rsync naredba će izvršiti prijenos, nadamo se da su ključevi jasni — prijenos se vrši uz očuvanje simboličkih linkova, prava pristupa, vlasnika i grupa, a enkripcija je isključena radi veće brzine (moglo se koristiti neki brži cipher, ali to nije presudno u okviru ovog zadatka), također je isključeno i kompresiju.

Nakon završetka rsync-a, izlazimo iz chroot-a (pritiskom na ctrl+d) i izvršavamo

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

Korak 5

Izvršavamo nekoliko radnji koje će nam pomoći u pokretanju VM nakon prijenosa s OpenVZ-a.
Na serverima s Systemd izvršavat ćemo naredbu koja će nam pomoći da se prijavimo na uobičajenu konzolu, na primjer, putem VNC-a na serveru

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

Na serverima CentOS 6 i CentOS 7 obavezno ćemo instalirati svježu jezgru:

yum install kernel-$(uname -r)

Server se može pokrenuti s nje, ali nakon prijenosa može prestati raditi ili će biti uklonjen.

Na serveru CentOS 7 potrebno je primijeniti mali popravak za PolkitD, inače će server upasti u beskrajno pokretanje:

getent group polkitd >/dev/null && echo -e "e[1;32mpolkitd grupa već postoji e[0m" || { groupadd -r polkitd && echo -e "e[1;33mDodana nedostajuća polkitd grupa e[0m" || echo -e "e[1;31mDodavanje polkitd grupe NEUSPJELO e[0m"; }

getent passwd polkitd >/dev/null 
&& echo -e "e[1;32mpolkitd korisnik već postoji e[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "Korisnik za polkitd" polkitd && echo -e "e[1;33mDodan nedostajući polkitd korisnik e[0m" || echo -e "e[1;31mDodavanje polkitd korisnika NEUSPJELO e[0m"; }

rpm -Va polkit* && echo -e "e[1;32mpolkit* rpm provjera prošla e[0m" || { echo -e "e[1;33mResetiranje polkit* rpm korisničkih/grupnih prava e[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

Na svim serverima, ako je instaliran mod_fcgid za Apache, izvršit ćemo mali popravak s pravima, inače će web stranice koje koriste mod_fcgid padati s greškom 500:

chmod +s `which suexec` && apachectl restart

I na kraju, ovo će biti korisno za Ubuntu, Debian distribucije. Ovaj OS može upasti u beskrajno pokretanje s greškom

looping too fast. throttling execution a little

neugodno, ali lako se popravlja, ovisno o verziji OS-a.

Na Debian 9 popravak izgleda ovako:

izvršavamo

dbus-uuidgen

ako dobijemo grešku

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

provjeravamo postoji li 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 <== treba ovaj
libdbus-1.so.3.14.16

ako je sve u redu, izvršavamo

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

Ako ne pomaže — pokušavamo drugu opciju.

Druga opcija rješavanja problema s throttling execution a little prikladna je praktički za sve Ubuntu i Debian distribucije.

Izvršavamo

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

A za Ubuntu 14, Debian 7 dodatno izvršavamo:

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

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

Što smo učinili? Vratili smo messagebus, koji je nedostajao za pokretanje Debian/Ubuntu i uklonili modules_dep, koji je došao iz OpenVZ-a i ometao učitavanje mnogih modula jezgre.

Korak 6

Ponovno pokrećemo VM, provjeravamo u VNC kako ide učitavanje i idealno — sve će se učitati bez problema. Iako, možda će se pojaviti neki specifični problemi nakon migracije — ali oni izlaze van okvira ovog članka i ispravljaju se po potrebi.

Nadam se da će ove informacije biti korisne! 🙂

Izvor: habr.com

Kupite pouzdan hosting za web stranice s DDoS zaštitom, VPS VDS servere 🔥 Kupite pouzdan hosting za web stranice s DDoS zaštitom, VPS VDS servere | ProHoster