Hogyan vigyük át az OpenVZ 6 tárolót a KVM szerverre fejfájás nélkül

Akinek életében legalább egyszer át kellett vinnie OpenVZ-tárolót egy teljes KVM-virtualizációval rendelkező szerverre, néhány problémával találkozott:

• A legtöbb információ egyszerűen elavult, és azokra az operációs rendszerekre vonatkozott, amelyek már régóta túl vannak az EOL cikluson
• A különböző operációs rendszerekhez mindig különböző információk állnak rendelkezésre, és a migráció során felmerülő esetleges hibákat soha nem veszik figyelembe
• Néha olyan konfigurációkkal kell megküzdenie, amelyek időnként nem akarnak működni az áttelepítés után

1 szerver átvitelekor mindig lehet valamit menet közben javítani, de ha egy egész klasztert viszünk át?

Ebben a cikkben megpróbálom elmondani, hogyan lehet helyesen migrálni egy OpenVZ-tárolót KVM-re minimális leállással és minden probléma gyors megoldásával.

Egy kis oktatási program: mi az OpenVZ és mi az a KVM?

Nem megyünk mélyre a terminológiába, hanem általánosságban mondjuk:

OpenVZ — virtualizáció operációs rendszer szinten, akár mikrohullámú sütőben is telepíthető, hiszen nincs szükség CPU utasításokra és virtualizációs technológiákra a gazdagépen.

KVM - teljes értékű virtualizáció, a CPU minden erejét kihasználva és bármit, bármilyen módon képes virtualizálni, hosszában és keresztben vágva.

Ellentétben a közhiedelemmel, hogy a tárhelyszolgáltatók körében az OpenVZ túladott lesz, a KVM viszont nem – utóbbiak szerencséjére a KVM mostanra semmivel sem rosszabb, mint testvére.

Mit viszünk át?

Az átvitel tesztalanyaiként az OpenVZ-n elérhető operációs rendszerek teljes erdejét kellett használnunk: CentOS (6 és 7 verzió), Ubuntu (14, 16 és 18 LTS), Debian 7.

Feltételezték, hogy az OpenVZ konténerek többsége már futott valamilyen LAMP-ot, és néhányan egészen speciális szoftverek is voltak. Leggyakrabban ezek a konfigurációk az ISPmanagerrel, a VestaCP vezérlőpulttal voltak (és leggyakrabban évek óta nem frissültek). Az áthelyezési kérelmeiket is figyelembe kell venni.

Az áttelepítés az átvitt tároló IP-címének megőrzésével történik; feltételezzük, hogy a tároló IP-címe el van mentve a virtuális gépen, és probléma nélkül fog működni.

Az átvitel előtt győződjön meg arról, hogy minden kéznél van:

• OpenVZ szerver, teljes root hozzáférés a gazdagéphez, konténerek leállítása/csatolása/indítása/törlése
• KVM-szerver, teljes root hozzáférés a gazdagéphez, mindazzal, amit jelent. Feltételezhető, hogy minden már konfigurálva van és használatra kész.

Kezdjük az átvitelt

Az átvitel megkezdése előtt határozzuk meg azokat a kifejezéseket, amelyek segítenek elkerülni a félreértéseket:

KVM_NODE - KVM gazdagép
VZ_NODE - OpenVZ gazdagép
CTID - OpenVZ konténer
VM - KVM virtuális szerver

Felkészülés a migrációra és virtuális gépek létrehozása.

Lépés 1

Mivel valahova át kell helyeznünk a tárolót, létrehozzuk VM hasonló konfigurációval KVM_NODE.
Fontos! Létre kell hoznia egy virtuális gépet azon az operációs rendszeren, amely jelenleg CTID-n fut. Például, ha az Ubuntu 14 telepítve van a CTID-re, akkor az Ubuntu 14-et kell telepíteni a virtuális gépre. A kisebb verziók nem fontosak, és az eltérésük sem olyan kritikus, de a fő verzióknak azonosnak kell lenniük.

A virtuális gép létrehozása után frissítjük a csomagokat a CTID-n és a virtuális gépen (nem tévesztendő össze az operációs rendszer frissítésével - nem frissítjük, csak a csomagokat frissítjük, és ha megérkezik, akkor az operációs rendszer verzióját a főben változat).

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

# yum clean all
# yum update -y

És nem kevésbé ártalmatlan az Ubuntu és a Debian számára:

# apt-get update
# apt-get upgrade

Lépés 2

Telepítse tovább CTID, VZ_NODE и VM hasznosság rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Nem telepítünk mást sem oda, sem oda.

Lépés 3

Megállunk CTID on VZ_NODE csapat

vzctl stop CTID

A kép rögzítése CTID:

vzctl mount CTID

Lépjen a /vz/root/ mappábaCTID és végrehajtani

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

A gyökér alatt hozzon létre egy /root/exclude.txt fájlt – ez tartalmazza azon kivételek listáját, amelyek nem jutnak el 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 KVM_NODE és elindítjuk a mi VMhogy működjön és elérhető legyen a hálózaton keresztül.

Most minden készen áll az átvitelre. Megy!

Lépés 4

Még mindig a varázslat alatt, fellépünk

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

Az rsync parancs végrehajtja az átvitelt, reméljük, hogy a kulcsok tiszták - az átvitel a szimbolikus hivatkozások, hozzáférési jogok, tulajdonosok és csoportok megőrzésével történik, és a titkosítás le van tiltva a nagyobb sebesség érdekében (használhat gyorsabb titkosítást, de ez nem annyira fontos ennél a feladatnál), valamint a tömörítés le van tiltva.

Az rsync befejezése után lépjen ki a chrootból (a ctrl+d megnyomásával), és futtassa

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

Lépés 5

Végezzünk el néhány lépést, amelyek segítenek elindítani a virtuális gépet az OpenVZ-ről való átvitel után.
A szervereken systemd hajtsunk végre egy parancsot, amely segít bejelentkezni egy normál konzolba, például egy VNC szerver képernyőn keresztül

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

A szervereken 6 CentOS и 7 CentOS Ügyeljen arra, hogy friss kernelt telepítsen:

yum install kernel-$(uname -r)

A szerver betölthető róla, de az átvitel után előfordulhat, hogy leáll vagy törlődik.

A szerveren 7 CentOS egy kis javítást kell alkalmaznia a PolkitD-hez, különben a szerver örökre összeomlik:

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

Ha minden kiszolgálón telepítve volt a mod_fcgid for Apache, akkor egy kis javítást hajtunk végre a jogokkal, ellenkező esetben a mod_fcgid-t használó webhelyek összeomlanak 500-as hibával:

chmod +s `which suexec` && apachectl restart

És az utolsó dolog hasznos az Ubuntu és Debian disztribúciókhoz. Ez az operációs rendszer egy örökkévaló rendszerindításba ütközhet hibával

túl gyorsan hurkolni. egy kicsit fojtva a végrehajtást

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

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

végzünk

dbus-uuidgen

ha hibát kapunk

/usr/local/lib/libdbus-1.so.3: a `LIBDBUS_PRIVATE_1.10.8′ verzió nem található

ellenőrizze a LIBDBUS jelenlé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 <-- нужен этот
libdbus-1.so.3.14.16

ha minden rendben van, megcsináljuk

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álkozzon a második lehetőséggel.

A második megoldás a problémára egy kicsit fojtva a végrehajtást Szinte minden Ubuntu és Debian disztribúcióhoz alkalmas.

Végezzük

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

És a Ubuntu 14, Debian 7 Ezen kívül teljesítjük:

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

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

Mit tettünk? Visszaállítottuk a messagebus-t, amely hiányzott a Debian/Ubuntu futtatásához, és eltávolítottuk a modules_dep-et, amely az OpenVZ-ből származott, és sok kernelmodul betöltését zavarta.

Lépés 6

Újraindítjuk a virtuális gépet, ellenőrizzük VNC-ben, hogyan halad a betöltés, és ideális esetben minden probléma nélkül betöltődik. Bár lehetséges, hogy bizonyos problémák jelentkeznek az áttelepítés után, ezek túlmutatnak jelen cikk hatókörén, és amint felmerülnek, javítjuk őket.

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

Forrás: will.com