🥇 Hogyan lehet fájdalommentesen átvinni az OpenVZ 6 konténert KVM szerverre

Mindegy, ki hányszor találkozott már élete során az OpenVZ konténer KVM alapú szerverre történő áthelyezésének szükségességével, néhány problémával biztosan szembesült.

A legtöbb információ alapvetően elavult, és már régóta lejárt EOL ciklusú operációs rendszerekre vonatkozik.
Különböző operációs rendszerekhez mindig más információ áll rendelkezésre, és soha nem veszik figyelembe a migrációs hibák lehetőségét.
Néha olyan konfigurációkkal kell foglalkozni, amelyek folyamatosan problémát okoznak a migráció után.

Amikor egy szervert helyezünk át, mindig van lehetőség a problémák javítására menet közben, de mi a helyzet egy egész klaszter áthelyezésekor?

Ebben a cikkben megpróbálom elmondani, hogyan lehet helyesen migrálni az OpenVZ konténert KVM-re minimális leállási idővel és a problémák gyors megoldásával.

Egy kis áttekintés: mi az az OpenVZ és mi az a KVM?

Nem kívánunk mélyebben belemenni a terminológiába, hanem általánosságban elmondjuk:

OpenVZ — operációs rendszerek szintjén történő virtualizálás, még mikrosütőn is futtatható, mivel nem szükséges CPU utasításokkal és virtualizációs technológiákkal rendelkezni a hosztgépen.

KVM — teljes virtualizáció, amely kihasználja a CPU minden teljesítményét és bármilyen formában képes virtualizálni, ahogyan csak akarja, hosszában és keresztben.

A köztudatban elterjedt véleménnyel ellentétben, hogy a host szolgáltatók az OpenVZ-t túlteljesítik, míg a KVM-et nem – a KVM számára szerencsére ma már nem jobb a túlteljesítés, mint az előbbi esetében.

Mit fogunk áthelyezni?

A migrációhoz az OpenVZ alatt elérhető összes operációs rendszer rengetegét kellett igénybe venni: CentOS (6 és 7 verzió), Ubuntu (14, 16 és 18 LTS), Debian 7.

Feltételeztük, hogy a legtöbb OpenVZ konténeren már működik valamilyen LAMP, és néhány nagyon specifikus szoftver is telepítve van. Leggyakrabban ezek ISPmanager, VestaCP vezérlőpanelekkel rendelkező konfigurációk voltak (és a leggyakrabban évek óta frissítetlenek). Figyelembe kell venni a migrációval kapcsolatos igényeiket is.

A migráció a IP address migrálható konténer megőrzésével történik, feltételezzük, hogy a konténer IP-címe megmarad a VM-en és problémák nélkül működik.

A migráció előtt győződjünk meg arról, hogy minden a rendelkezésünkre áll:

OpenVZ szerver, teljes root hozzáférés a hosztgéphez, a konténerek leállításának/montírozásának/indításának/törlésének lehetősége.
KVM szerver, teljes root hozzáférés a hoszt géphez, az összes következménnyel együtt. Feltételezzük, hogy minden már be van állítva és működésre kész.

Kezdjük a migrálást

Mielőtt elkezdenénk a migrálást, határozzuk meg azokat a kifejezéseket, amelyek segítenek elkerülni a félreértéseket:

KVM_NODE — KVM hoszt gép
VZ_NODE — OpenVZ hoszt gép
CTID — OpenVZ konténer
VM — KVM virtuális szerver

Készülődés a migrálásra és virtuális gépek létrehozása.

1. lépés

Mivel a konténert valahova át kell vinni, létrehozunk VM hasonló konfigurációval a KVM_NODE.
Fontos! A VM-et pontosan azon az operációs rendszeren kell létrehozni, amely jelenleg a CTID-n fut. Például, ha a CTID-n Ubuntu 14 van, akkor a VM-re is Ubuntu 14-et kell telepíteni. A kisebb verziók nem fontosak, és az eltérésük nem annyira kritikus, de a fő verzióknak egyformának kell lenniük.

A VM létrehozása után frissítjük a csomagokat a CTID-n és a VM-en (ne keverjük össze a rendszer frissítésével — csak a csomagokat frissítjük, és ha jön új verzió, azt a fő verzión belül).

CentOS esetében ez a folyamat ártalmatlannak tűnik:

# yum clean all
# yum update -y

És nem kevésbé ártalmatlan Ubuntu, Debian esetén:

# apt-get update
# apt-get upgrade

2. lépés

Telepítjük a CTID, VZ_NODE és VM segédprogramot rsync:

CentOS-on:

# yum install rsync -y

Debian, Ubuntu-on:

# apt-get install rsync -y

Több semmilyen mást nem telepítünk se ott, se itt.

3. lépés

Leállítjuk a CTID Gyorsan emlékezzünk vissza, hogyan működik a moduláris aritmetika. Az óra már egy ismert koncepció. Az órák használata VZ_NODE parancsot

vzctl stop CTID

Csatoljuk a képet CTID:

vzctl mount CTID

Átmegyünk a mappába /vz/root/CTID és végrehajtjuk

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

Chroot alatt létrehozzuk a /root/exclude.txt fájlt — ez tartalmazni fogja azokat a kivételeket, amelyek nem kerülnek át az új szerverre.

/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

Csatlakozunk a KVM_NODE és elindítjuk a VM, hogy működjön és elérhető legyen a hálózaton.

Most minden készen áll a migrálásra. Induljunk!

4. lépés

Még mindig a chroot alatt, végrehajtjuk

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

Az rsync parancs elvégzi a migrálást, reméljük, hogy a kulcsok érthetők — a migrálás szimbolikus linkek, jogosultságok, tulajdonosok és csoportok megőrzésével történik, valamint titkosítás kikapcsolásával a nagyobb sebesség érdekében (használhattunk volna valamilyen gyorsabb titkosítást, de ez nem kritikus jelen feladat keretein belül); a tömörítés is ki van kapcsolva.

A rsync végrehajtása után kilépünk a chrootból (ctrl+d megnyomásával) és végrehajtjuk

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

5. lépés

Több olyan lépést hajtunk végre, amelyek segítenek nekünk a VM indításában a migrálás után az OpenVZ-ről.
Rendszereken Systemd Futtassunk el egy parancsot, amely segít a belépésben a szokásos konzolon, például a VNC-n keresztül a szerver képernyőjére.

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

A szervereken CentOS 6 és verzióban feltétlenül telepítsünk friss kernelt:

yum install kernel-$(uname -r)

A szerver indítható róla, de az átadás után lehet, hogy nem működik, vagy eltávolítják.

A szerveren verzióban be kell vezetnünk egy kisebb javítást a PolkitD-hez, különben a szerver végtelen ciklusba kerül:

getent group polkitd >/dev/null && echo -e "e[1;32mpolkitd csoport már létezik[e[0m" || { groupadd -r polkitd && echo -e "e[1;33mHozzáadva a hiányzó polkitd csoport[e[0m" || echo -e "e[1;31mA polkitd csoport hozzáadása MEGHIBÁSODOTT[e[0m"; }

getent passwd polkitd >/dev/null 
&& echo -e "e[1;32mpolkitd felhasználó már létezik[e[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "Felhasználó a polkitd-hez" polkitd && echo -e "e[1;33mHozzáadva a hiányzó polkitd felhasználó[e[0m" || echo -e "e[1;31mA polkitd felhasználó hozzáadása MEGHIBÁSODOTT[e[0m"; }

rpm -Va polkit* && echo -e "e[1;32mpolkit* rpm ellenőrzés sikeres[e[0m" || { echo -e "e[1;33mA polkit* rpm felhasználói/csoportjogok és engedélyek visszaállítása[e[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

Minden szerveren, ha a mod_fcgid telepítve volt az Apache számára, végezzünk el egy kisebb javítást a jogosultságokkal, különben a mod_fcgid-t használó oldalak 500-as hibával fognak leállni:

chmod +s `which suexec` && apachectl restart

És végül, hasznos lesz az Ubuntu és Debian disztribúciók számára. Ez az operációs rendszer végtelen ciklusba kerülhet hibával:

looping too fast. throttling execution a little

nem kellemes, de könnyen javítható, az operációs rendszer verziójától függően.

Ezen Debian 9 a javítás így néz ki:

végrehajtjuk

dbus-uuidgen

ha hibát kapunk

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

ellenőrizzük a LIBDBUS meglétét

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 <--- erre van szükség
libdbus-1.so.3.14.16

ha minden rendben van, végrehajtjuk

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

Ha nem segít – próbáljunk meg egy második lehetőséget.

A második lehetőség a probléma megoldására throttling execution a little majdnem minden Ubuntu és Debian disztribúcióhoz alkalmazható.

Végezzük el

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

A Ubuntu 14, Debian 7 továbbiakban futtassuk:

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

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

Mit csináltunk? Visszaállítottuk a messagebus-t, amely hiányzott a Debian/Ubuntu működéséhez, és eltávolítottuk a modules_dep-t, amely az OpenVZ-ből származott és akadályozta sok kernel modul betöltését.

6. lépés

Újraindítjuk a VM-et, ellenőrizzük a VNC-n, hogy halad a bootolás, és ideálisan – minden problémamentesen elindul. Bár lehet, hogy néhány speciális probléma lép fel a migráció után – de ezek már meghaladják ennek a cikknek a kereteit, és a megjelenésük során javíthatók.

Remélem, hogy ez az információ hasznos lesz! 🙂

Forrás: habr.com