ProHoster > Blog > uprava > Kako prenijeti OpenVZ 6 spremnik na KVM poslužitelj bez glavobolje

Kako prenijeti OpenVZ 6 spremnik na KVM poslužitelj bez glavobolje

Svatko tko je barem jednom u životu trebao prenijeti OpenVZ spremnik na poslužitelj s potpunom KVM virtualizacijom, naišao je na neke probleme:

  • Većina informacija jednostavno je zastarjela i bila je relevantna za operativne sustave koji su odavno prošli EOL ciklus
  • Za različite operativne sustave uvijek se daju različite informacije, a moguće greške tijekom migracije nikada se ne razmatraju
  • Ponekad se morate suočiti s konfiguracijama koje s vremena na vrijeme ne žele raditi nakon migracije

Kad prenosiš 1 server uvijek možeš nešto popraviti u hodu, a kad prenosiš cijeli klaster?

U ovom ću vam članku pokušati reći kako ispravno migrirati OpenVZ spremnik na KVM s minimalnim zastojem i brzim rješenjem za sve probleme.

Mali obrazovni program: što je OpenVZ, a što KVM?

Nećemo ulaziti duboko u terminologiju, već ćemo reći općenito:

OpenVZ — virtualizacija na razini operativnog sustava, možete ga čak postaviti na mikrovalnu pećnicu, budući da nema potrebe za CPU uputama i tehnologijama virtualizacije na glavnom računalu.

KVM - puna virtualizacija, koja koristi svu snagu CPU-a i sposobna je virtualizirati bilo što, na bilo koji način, sjeći uzduž i poprijeko.

Suprotno uvriježenom mišljenju da će među pružateljima usluga hostinga OpenVZ postati preprodan, ali KVM neće - srećom za potonje, KVM sada nije preprodan ništa gore od svog brata.

Što ćemo prenijeti?

Kao testne subjekte za prijenos morali smo koristiti čitavu šumu operativnih sustava koji su dostupni na OpenVZ-u: CentOS (verzije 6 i 7), Ubuntu (14, 16 i 18 LTS), Debian 7.

Pretpostavljalo se da većina OpenVZ spremnika već pokreće neku vrstu LAMP-a, a neki čak imaju vrlo specifičan softver. Najčešće su to bile konfiguracije s ISPmanagerom, VestaCP kontrolnom pločom (i najčešće neažurirane godinama). Njihovi zahtjevi za transfer također se moraju uzeti u obzir.

Migracija se provodi uz očuvanje IP adrese prenesenog spremnika; pretpostavit ćemo da je IP koji je kontejner imao spremljen na VM i da će raditi bez problema.

Prije prijenosa provjerimo imamo li sve pri ruci:

  • OpenVZ poslužitelj, potpuni root pristup glavnom računalu, mogućnost zaustavljanja/montaže/pokretanja/brisanja spremnika
  • KVM poslužitelj, puni root pristup glavnom računalu, sa svime što to podrazumijeva. Pretpostavlja se da je sve već konfigurirano i spremno za rad.

Počnimo s prijenosom

Prije nego započnemo prijenos, definirajmo pojmove koji će vam pomoći da izbjegnete zabunu:

KVM_ČVOR - KVM host stroj
VZ_ČVOR - OpenVZ host stroj
CTID - OpenVZ spremnik
VM - KVM virtualni poslužitelj

Priprema za migraciju i stvaranje virtualnih strojeva.

Korak 1

Budući da moramo negdje premjestiti spremnik, napravit ćemo VM sa sličnom konfiguracijom KVM_ČVOR.
Važno! Morate stvoriti VM na operativnom sustavu koji trenutno radi na CTID-u. Na primjer, ako je Ubuntu 14 instaliran na CTID, onda Ubuntu 14 mora biti instaliran na VM. Manje verzije nisu važne i njihova razlika nije toliko kritična, ali glavne verzije bi trebale biti iste.

Nakon izrade VM-a, ažurirat ćemo pakete na CTID-u i na VM-u (ne treba brkati s ažuriranjem OS-a - ne ažuriramo ga, ažuriramo samo pakete i, ako stigne, verziju OS-a unutar glavnog verzija).

Za CentOS ovaj proces izgleda bezopasno:

# yum clean all
# yum update -y

I ništa manje bezopasno za Ubuntu i Debian:

# apt-get update
# apt-get upgrade

Korak 2

Instalirajte na CTID, VZ_ČVOR и VM korisnost rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Ništa drugo ne ugrađujemo ni tamo ni tamo.

Korak 3

Zastajemo CTID na VZ_ČVOR Tim

vzctl stop CTID

Montaža slike CTID:

vzctl mount CTID

Idite u mapu /vz/root/CTID i izvršiti

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

Ispod korijena kreirajte datoteku /root/exclude.txt - sadržavat će popis iznimaka koji neće doći do novog poslužitelja

/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

Poveži se s KVM_ČVOR i pokrenuti naš VMtako da radi i bude dostupan preko mreže.

Sada je sve spremno za prijenos. Ići!

Korak 4

Još uvijek pod čarolijom, nastupamo

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

Naredba rsync će izvršiti prijenos, nadamo se da su ključevi jasni - prijenos se provodi uz očuvanje simboličkih poveznica, prava pristupa, vlasnika i grupa, a enkripcija je onemogućena radi veće brzine (možete koristiti neku bržu šifru, ali ovo nije toliko važno za ovaj zadatak), kao i da je kompresija onemogućena.

Nakon završetka rsync, izađite iz chroota (pritiskom na ctrl+d) i izvedite

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

Korak 5

Izvršimo nekoliko koraka koji će nam pomoći da pokrenemo VM nakon prijenosa iz OpenVZ-a.
Na poslužiteljima sa Systemd izvršimo naredbu koja će nam pomoći da se prijavimo na običnu konzolu, na primjer, preko zaslona VNC poslužitelja

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

Na serverima 6 CentOS и 7 CentOS Svakako instalirajte novi kernel:

yum install kernel-$(uname -r)

Poslužitelj se može učitati s njega, ali nakon prijenosa može prestati raditi ili biti izbrisan.

Na serveru 7 CentOS trebate primijeniti mali popravak za PolkitD, inače će se poslužitelj zauvijek srušiti:

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

Na svim poslužiteljima, ako je instaliran mod_fcgid za Apache, izvršit ćemo mali popravak s pravima, inače će se stranice koje koriste mod_fcgid srušiti s pogreškom 500:

chmod +s `which suexec` && apachectl restart

I zadnja stvar je korisna za Ubuntu i Debian distribucije. Ovaj OS se može srušiti u vječnom pokretanju s pogreškom

petlja prebrzo. prigušivanje izvršenja malo

neugodno, ali lako popravljivo, ovisno o verziji OS-a.

Na Debian 9 popravak izgleda ovako:

provodimo

dbus-uuidgen

ako dobijemo grešku

/usr/local/lib/libdbus-1.so.3: verzija `LIBDBUS_PRIVATE_1.10.8' nije pronađena

provjerite prisutnost LIBDBUS-a 

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

ako je sve u redu, mi to radimo

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 pomogne, pokušajte drugu opciju.

Drugo rješenje problema sa prigušivanje izvršenja malo Prikladno za gotovo sve Ubuntu i Debian distribucije.

Mi izvršavamo

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

I za Ubuntu 14, Debian 7 Dodatno izvodimo:

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 sabirnicu poruka, koja je nedostajala za pokretanje Debiana/Ubuntua, i uklonili modules_dep, koji je došao iz OpenVZ-a i ometao učitavanje mnogih modula kernela.

Korak 6

Restartamo VM, provjerimo u VNC-u kako napreduje učitavanje i, idealno, sve će se učitati bez problema. Iako je moguće da će se neki specifični problemi pojaviti nakon migracije, oni su izvan opsega ovog članka i bit će ispravljeni čim se pojave.

Nadam se da su ove informacije korisne! 🙂

Izvor: www.habr.com

Dodajte komentar