🥇Kako preseliti vsebnik OpenVZ 6 na strežnik KVM brez glavobola

Vsakdo, ki je moral vsaj enkrat v življenju prenesti vsebnik OpenVZ na strežnik s popolno virtualizacijo KVM, je naletel na nekaj težav:

Večina informacij je preprosto zastarela in je bila pomembna za operacijske sisteme, ki so že dolgo prestali cikel EOL
Za različne operacijske sisteme so vedno podane različne informacije, možne napake med selitvijo pa nikoli niso upoštevane
Včasih se morate soočiti s konfiguracijami, ki po selitvi vsake toliko nočejo delovati

Ko preneseš 1 strežnik lahko vedno sproti kaj popraviš, ko pa preneseš cel grozd?

V tem članku vam bom poskušal povedati, kako pravilno preseliti vsebnik OpenVZ v KVM z minimalnimi izpadi in hitro rešiti vse težave.

Majhen izobraževalni program: kaj je OpenVZ in kaj je KVM?

Ne bomo se spuščali v terminologijo, ampak bomo povedali na splošno:

OpenVZ — virtualizacija na ravni operacijskega sistema, lahko jo namestite celo v mikrovalovni pečici, saj na gostiteljskem računalniku ni potrebe po navodilih CPU in tehnologijah za virtualizacijo.

KVM - popolna virtualizacija, ki izkorišča vso moč procesorja in je sposobna virtualizirati karkoli, na kakršen koli način, rezati po dolgem in počez.

V nasprotju s splošnim prepričanjem, v okolju ponudniki gostovanja OpenVZ je preprodan, KVM pa ne. Na srečo slednjega je KVM zdaj preprodan prav tako dobro kot njegov brat.

Kaj bomo prenesli?

Za prenos je bilo treba kot testne subjekte uporabiti celoten gozd operacijskih sistemov, ki so na voljo na OpenVZ: CentOS (različici 6 in 7), Ubuntu (14., 16. in 18. razred LTS), Debian 7.

Predpostavljalo se je, da večina vsebnikov OpenVZ že poganja nekakšen LAMP, nekateri pa imajo celo zelo specifično programsko opremo. Najpogosteje so bile to konfiguracije z ISPmanagerjem, nadzorno ploščo VestaCP (in največkrat neposodobljene več let). Upoštevati je treba tudi njihove zahteve za premestitev.

Migracija se izvaja z ohranjanjem IP naslovi Za prenosni vsebnik bomo predpostavili, da je IP-naslov vsebnika shranjen na navideznem računalniku in bo deloval brez težav.

Pred prenosom poskrbimo, da imamo vse pri roki:

Strežnik OpenVZ, popoln korenski dostop do gostiteljskega računalnika, možnost zaustavitve/vklopa/zagona/brisanja vsebnikov
Strežnik KVM, popoln korenski dostop do gostiteljskega računalnika z vsem, kar to pomeni. Predpostavlja se, da je vse že konfigurirano in pripravljeno za uporabo.

Začnimo s prenosom

Preden začnemo s prenosom, definirajmo izraze, ki vam bodo pomagali preprečiti zmedo:

KVM_NODE - KVM gostiteljski stroj
VZ_VOZLIŠČE - Gostiteljski stroj OpenVZ
CTID - Vsebnik OpenVZ
VM - KVM virtualni strežnik

Priprave na selitev in ustvarjanje virtualnih strojev.

Korak 1

Ker moramo vsebnik nekam premakniti, bomo ustvarili VM s podobno konfiguracijo kot KVM_NODE.
Pomembno! Ustvariti morate virtualni stroj v istem operacijskem sistemu, ki se trenutno izvaja na CTID-ju. Če se na primer CTID izvaja Ubuntu 14, potem ga morate namestiti tudi na virtualni stroj Ubuntu 14. Manjše različice niso pomembne in njihovo neskladje ni tako kritično, glavne različice pa morajo biti enake.

Ko ustvarimo VM, bomo posodobili pakete na CTID in na VM (ne zamenjujte s posodabljanjem OS - ne posodabljamo ga, posodobimo samo pakete in, če prispe, različico OS znotraj glavnega različica).

Za CentOS Ta postopek je videti neškodljiv:

# yum clean all
# yum update -y

In nič manj neškodljivo za Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Korak 2

Namestite na CTID, VZ_VOZLIŠČE и VM uporabnost rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Ne tam ne tam ne vgrajujemo ničesar drugega.

Korak 3

Naredimo postanek CTID o VZ_VOZLIŠČE ekipa

vzctl stop CTID

Montaža slike CTID:

vzctl mount CTID

Pojdite v mapo /vz/root/CTID in izvršiti

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

Pod korenom ustvarite datoteko /root/exclude.txt - vsebovala bo seznam izjem, ki ne bodo prišle do novega strežnika

/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 z KVM_NODE in zaženite našo VMtako da deluje in je dostopen prek omrežja.

Zdaj je vse pripravljeno za prenos. Pojdi!

Korak 4

Še vedno pod urokom nastopamo

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

Ukaz rsync bo izvedel prenos, upamo, da so ključi jasni - prenos poteka z ohranitvijo simbolnih povezav, pravic dostopa, lastnikov in skupin, šifriranje pa je onemogočeno zaradi večje hitrosti (lahko uporabite kakšno hitrejšo šifro, vendar to ni tako pomembno za to nalogo), prav tako je stiskanje onemogočeno.

Ko končate rsync, zapustite chroot (s pritiskom na ctrl+d) in izvedite

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

Korak 5

Izvedimo več korakov, ki nam bodo pomagali zagnati VM po prenosu iz OpenVZ.
Na strežnikih z Systemd izvedimo ukaz, ki nam bo pomagal pri prijavi v običajno konzolo, na primer prek zaslona strežnika VNC

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

Na strežnikih CentOS 6 и CentOS 7 Ne pozabite namestiti svežega jedra:

yum install kernel-$(uname -r)

Strežnik je mogoče naložiti z njega, vendar po prenosu lahko preneha delovati ali se izbriše.

Na strežniku CentOS 7 uporabiti morate majhen popravek za PolkitD, sicer se bo strežnik za vedno zrušil:

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 vseh strežnikih, če je bil nameščen mod_fcgid za Apache, bomo izvedli majhen popravek s pravicami, sicer se bodo spletna mesta, ki uporabljajo mod_fcgid, zrušila z napako 500:

chmod +s `which suexec` && apachectl restart

In nenazadnje bo koristno za Ubuntu, Debian distribucije. Ta operacijski sistem se lahko sesuje v trajni zagon z napako

prehitro zanke. malo upočasnitev izvedbe

neprijetno, a enostavno popravljeno, odvisno od različice OS.

Na Debian 9 popravek izgleda takole:

izvajamo

dbus-uuidgen

če dobimo napako

/usr/local/lib/libdbus-1.so.3: različice `LIBDBUS_PRIVATE_1.10.8` ni bilo mogoče najti

preverite prisotnost 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

če je vse v redu, to naredimo

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

Če ne pomaga, poskusite drugo možnost.

Druga rešitev problema z malo upočasnitev izvedbe primerno za skoraj vsakogar Ubuntu и Debian porazdelitve.

Izvajamo

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

In za Ubuntu 14, Debian 7 Dodatno izvajamo:

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

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

Kaj smo storili? Obnovili smo sporočilni vodnik, ki je manjkal pri zagonu. Debian/Ubuntu in odstranil modules_dep, ki je prihajal iz OpenVZ in je preprečeval nalaganje številnih modulov jedra.

Korak 6

Ponovno zaženemo VM, preverimo v VNC, kako napreduje nalaganje in v idealnem primeru se bo vse naložilo brez težav. Čeprav je možno, da se bodo po selitvi pojavile nekatere posebne težave, niso zajete v tem članku in bodo popravljene, ko se bodo pojavile.

Upam, da so te informacije koristne! 🙂

Vir: www.habr.com